Average web page size, measured the way Googlebot measures it: 27 homepages, one over 2MB

FIELD TEST · 2026-08-23 · 27 homepages · single crawl · bytes counted twice

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-23 with a browser user agent and Accept-Encoding: gzip, deflate, br. We recorded the bytes on the wire, decompressed the body, and counted the bytes again. HTML only — no images, scripts or stylesheets were fetched.

Average web page size is normally quoted as total page weight, images included. This is the narrower number and the one crawlers are actually limited by: the HTML document alone, uncompressed. Across 27 homepages the median is 574,601 bytes, one site ships 2,187,316, and visible text accounts for a median of 1.9% of those bytes.

How we measured it

One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: status 200, body at least 10,000 bytes, body containing <body. Three of the 30 failed — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27, the same three exclusions as previous batches.

Wire bytes are the length of the response body as delivered. HTML bytes are the same body after decompressing according to the Content-Encoding header. Visible text is characters in text nodes with script, style, noscript, template and svg contents removed and whitespace collapsed; inline script bytes are the contents of <script> elements in the document, which is not the same thing as the size of the external bundles those pages also load.

The limit is 2MB, and it is measured uncompressed

Google's Googlebot documentation, last updated 2026-02-03 and read on 2026-08-23, states the cutoff plainly: "When crawling for Google Search, Googlebot crawls the first 2MB of a supported file type, and the first 64MB of a PDF file." The sentence that matters more comes two lines later: "The file size limit is applied on the uncompressed data."

That is why the wire number is the wrong one to watch. A homepage delivered in 188 KB can be 2 MB by the time it is parsed, and the truncation rule reads the second figure. What happens at the cutoff is also documented: "Once the cutoff limit is reached, Googlebot stops the fetch and only sends the already downloaded part of the file for indexing consideration."

Compression protects your bandwidth bill. It does not protect your crawl budget for a single document.

One site is already over the line

www.framer.com served 2,187,316 bytes of HTML on 2026-08-23, from 188,641 bytes on the wire. That is past 2 MB whether the documentation means 2,000,000 bytes or 2,097,152 — it does not say which, and at this size the distinction does not rescue the page. Six more sites are between 1 and 2 MB.

The last row is the other end of the panel. Hacker News delivers a complete homepage in 5,651 bytes on the wire and 34,509 uncompressed, which is 1.6% of what Framer sends. It is not a fair comparison of design ambition, and it is a fair comparison of what a crawler has to read to find the same kind of information.

Why the average web page size in your network panel is wrong by 8x

All 27 sites returned a compressed body. Eighteen used Brotli, nine used gzip, and none served the HTML uncompressed. Ratios run from 3.6 on stripe.com to 14.5 on www.theverge.com, with a median of 7.9.

Added up, the panel ships 18,739,396 bytes of HTML in 2,431,758 bytes on the wire. So the average web page size you see in a network panel is off by roughly a factor of eight from the number Googlebot's limit is applied to, and the gap is widest exactly where the document is largest.

Visible text is 1.9% of it

The median homepage in this panel spends 1.9% of its HTML bytes on text a reader can see. The range runs from 0.2% on figma.com to 11.7% on news.ycombinator.com. Inline <script> content takes a median of 21.3%, and on five sites it takes more than half: figma.com 82.5%, www.nytimes.com 77.5%, railway.com 57.6%, vercel.com 56.9%, www.wired.com 56.1%.

Most of that inline script is serialised state — the data a framework needs to hydrate the page it just rendered. It is not waste in an engineering sense. It is simply not content, and it counts against the same 2 MB. What the remaining bytes are on the sites where inline script is small, we did not break down; markup, inline styles and SVG paths all live in there and this crawl did not separate them.

What this means for your site

Three checks, and only the first one is urgent.

• Measure the uncompressed size of your heaviest template, not your homepage. One command: curl -s --compressed URL | wc -c.
• If a page is over about 1.5 MB uncompressed, find out what the inline script is carrying before you touch anything else. On five of these 27 sites it is the majority of the document.
• Do not read your network panel's transfer size as the number Google applies. It is roughly eight times smaller on this panel.

Byte counts say nothing about whether the words survive to a crawler that does not run JavaScript; that question is measured separately in what AI crawlers actually see. For how long these same homepages take to answer at all rather than how much they send, see time to first byte across the panel. And if the underlying question is which of these to fix first, the diagnosis path starts here.

Common questions

How did you measure this?

One homepage request per site on 2026-08-23, with Accept-Encoding: gzip, deflate, br, following redirects, no JavaScript. Wire bytes were read from the response body length, HTML bytes after decompressing with the declared encoding.

Does page size affect rankings?

Google does not describe HTML size as a ranking factor. It describes it as a fetch limit, which is a different mechanism: past the cutoff, the rest of the document is not sent for indexing consideration at all. We did not measure any ranking effect and cannot infer one.

Is 2MB counted in decimal or binary megabytes?

The documentation says 2MB and does not define the unit. For the one page in this panel that exceeds it, the answer does not matter. For a page sitting at 2.05 MB it would, and we cannot tell you which way it falls.

Should I switch from gzip to Brotli?

It will cut your transfer bytes, and on this panel two-thirds of sites have already done it. It will not change the number Googlebot's limit is applied to, because that number is measured after decompression.