Page size checker

What this page size checker measures

This tool measures one file: the HTML document a URL returns. It reports its size as sent over the network and after decompression, then breaks that size down into what the HTML is made of.

It does not count the files the page loads after the HTML: images, external JavaScript and CSS files, fonts, video and third-party tags. So the number here is not the full page weight you see in a browser's Network panel. It is the part that every visitor and every crawler downloads first, on every page view.

Page size and HTML size

Page size, or page weight, usually means everything a browser downloads to show a page. The HTML document is the first part of it and often the smallest over the network. It still matters more than its size suggests, for three reasons.

• The browser can't request anything else until it starts reading the HTML.

• Everything inside the HTML is downloaded again on every page view. External CSS and JS files can be cached; inline code can't.

• Search engine crawlers fetch the HTML separately and apply their own size limit to it.

How the checker works

Enter a URL. The checker sends one plain HTTP request for that page, the way a crawler does, and accepts gzip, deflate and Brotli. It records the bytes the server actually sent and the size of the HTML after decompression. Nothing is recompressed on our side. It then parses the document and assigns every byte to one category, so the parts add up to the uncompressed total.

Two things follow from that, and both make the result a lower bound:

• No JavaScript runs. Content that scripts add after loading, lazy-loaded sections and the DOM after hydration are not counted. What you see is the HTML the server returns.

• Desktop only. The request uses a desktop Chrome user agent marked as HapryconBot. If your server sends different HTML to phones (dynamic serving), the mobile version is not checked.

How to read the results

HTML to download

The size of the HTML body exactly as your server sent it, after gzip or Brotli, without HTTP headers. This is what travels over the network and what a visitor waits for. If the server doesn't compress HTML, this number equals the uncompressed size.

HTML, uncompressed

The size of the HTML after decompression, and the number of elements in it. This is what the browser has to parse. It is also the number that counts toward Googlebot's 2 MB limit.

Compression

How much smaller the HTML is over the network than uncompressed. HTML usually compresses by 70–90%. A result near 0% means the server sent the HTML uncompressed. Check gzip and Brotli on your site.

What the HTML is made of

Every byte of the uncompressed HTML goes into one row, so you can see where the weight is.

• Markup: the tags themselves and attributes not listed below.

• Hydration data: JSON that frameworks such as Next.js, Nuxt or Remix embed so the page can start in the browser.

• Class attributes: the contents of class="…". Utility-first CSS can make this a large share.

• Inline CSS: code inside <style> tags, including any url(data:…) images in it.

• Inline SVG: icons and illustrations written into the markup, including anything embedded inside them.

• Data URIs: base64 images and other files embedded in attributes such as src or href.

• Text: the words a visitor can read.

• Inline JS: code inside <script> tags, excluding hydration data and JSON-LD.

• JSON-LD: structured data for search engines.

• Style attributes: the contents of style="…".

• Outside head/body: the doctype, comments and whitespace outside <head> and <body>.

Head and body

How the HTML splits between <head> and <body>: size, number of elements, scripts, style tags and inline SVGs in each. A heavy head is worth checking first, because the browser and crawlers read it before any content.

What stands out

Short notes on the parts of the HTML that are unusually large, such as hydration data, inline CSS, inline SVG, or a low share of visible text.

Light, typical or heavy HTML

The label next to the result compares the compressed size with the median page, about 22 KB of HTML:

These thresholds are ours, not an industry standard. They show how a page compares with the rest of the web, not whether it passes any test.

How big should HTML be?

There is no official limit for visitors. Two reference points are useful:

• The median. According to the HTTP Archive Web Almanac 2025, the median home page ships about 22 KB of HTML over the network, on both desktop and mobile. (source)

• Googlebot's limit. Googlebot fetches the first 2 MB of an HTML file, uncompressed. That is a hard ceiling for search, not a target.

A practical goal is to keep compressed HTML under about 66 KB, three times the median, and uncompressed HTML far below 2 MB. Check every main template, not just the home page.

HTML size and SEO

Google doesn't rank pages by size, but HTML size affects search in two direct ways.

Googlebot's 2 MB limit

Googlebot fetches at most 2 MB of an HTML document, counted after decompression and including HTTP headers. Anything after the cutoff is ignored, as if the file ended there. Content, internal links and structured data placed below that point may not be indexed. External CSS and JS files are fetched separately and have their own limit, so they don't count toward the HTML's 2 MB. Source: Google Search Central blog, March 2026.

Few pages get close, but those that do usually carry large hydration data, inline SVG or base64 images. This checker shows the uncompressed size, which is the number to compare with the limit.

Speed

The HTML is on the critical path: the browser has to receive it before it can find the main image, stylesheet or font. A large document delays Largest Contentful Paint (LCP), and a very large DOM makes the page slower to respond, measured by Interaction to Next Paint (INP). Check your Core Web Vitals to see the effect on real visitors.

How to reduce HTML size

Start with the largest row in «What the HTML is made of».

Hydration data

• Send only the props the page renders. Large API responses passed through whole are a common cause.

• Move data that is needed only after interaction to a separate request.

• Consider server components or partial hydration if your framework supports them.

Inline CSS

• Inline only the critical CSS for the first screen and move the rest to a cached stylesheet.

• Remove unused rules. Coverage in Chrome DevTools shows how much of the CSS a page uses.

Inline SVG

• Replace repeated icons with a sprite and <use>, or with <img> pointing to an .svg file.

• Optimize SVG paths with a tool such as SVGO.

Class attributes and markup

• Extract repeated utility class combinations into components.

• Remove wrapper elements that add nothing. Fewer elements also means a smaller DOM.

Inline JS and base64

• Move scripts to external files so they can be cached.

• Replace base64 images and data URIs with regular image files.

Compression

• Serve HTML with Brotli or gzip. This doesn't change the uncompressed size, but it usually cuts the download by 70–90%.

How to check full page weight

To see everything a page downloads, open Chrome DevTools, go to the Network tab and reload the page. The bottom bar shows the total transferred size and number of requests. Run it on your heaviest templates too: product pages, long articles and landing pages, not only the home page.