Every few months, someone points out that the median web page has ballooned to over two megabytes and declares the web bloated. Google’s Gary Illyes and Martin Splitt used a recent podcast episode to push back on that framing directly. Their argument is not that page weight is irrelevant — it’s that “page weight” isn’t even a single, agreed-upon measurement, and treating it as a simple good/bad threshold misses what actually matters: whether the bytes on a page are doing something useful.

Page size means different things depending on what you’re counting

Splitt’s starting point was definitional. Are you measuring raw HTML? Total transfer size including CSS, images and JavaScript? Compressed bytes over the wire, or the decompressed size sitting on a user’s device? Each answer produces a different number, and conversations about page weight routinely conflate them.

Take the panic that spread when SEOs learned Googlebot caps HTML crawling at roughly 2 megabytes per page. That sounds alarming until you translate it: 2MB of HTML is close to two million characters, or roughly the length of two Harry Potter novels rendered as a single page. That limit governs crawler behavior, not the user-facing experience — a completely different conversation from how fast a page loads for a visitor, which depends on everything else the page pulls in.

Splitt pointed to HTTP Archive’s Web Almanac as an example of how easily this gets muddled. The Almanac reported the median page at 845 kilobytes in 2015 and 2.3 megabytes by July 2025, but Splitt noted the underlying definition of “page weight” in that report wasn’t as precise as it needed to be to draw firm conclusions from the trend line.

Compression makes the number a moving target

Even once you settle on “total data a user downloads,” compression complicates the answer further. Most servers compress files with Brotli before sending them, so a page that appears to be 10 megabytes on disk might only transfer 5 or 6 megabytes over the network — then decompress back to its full size once it reaches the browser.

So is that page 10 megabytes or 6? Splitt’s point is that the honest answer is “it depends which layer you’re looking at,” and most casual claims about page bloat don’t specify which layer they mean. That ambiguity alone should make anyone cautious about treating page weight as a clean, comparable metric across sites or over time.

A heavier page isn’t automatically a worse page

The more useful distinction, according to Splitt, is the ratio of actual content to overhead markup — not raw size. He used a deliberately extreme example: a 15-megabyte HTML document where nearly all of that weight is genuine content is arguably fine, because the size reflects real value delivered to whoever’s reading it.

Flip that ratio and the picture changes. A 5-megabyte page carrying only a small amount of visible content looks worse on paper despite being a third of the size, because most of its weight is markup rather than substance. But even that framing has exceptions: some of that markup might be metadata required for a third-party integration, a regulatory disclosure, or a licensing requirement. It’s not content the visitor benefits from directly, but it’s not waste either — it’s a cost of doing business online that happens to add bytes.

Not everything on a page is built for the person reading it

Illyes raised a related point: a growing share of page weight exists purely for machines, not for human visitors. Structured data is the clearest example — it helps search engines understand a page, but a visitor never sees a line of it. Publishers who load pages with every structured data type available are adding real weight in exchange for a benefit that has nothing to do with rendering speed for a human reader.

That’s a structural fact about the modern web worth internalizing: pages now serve multiple audiences simultaneously — people, crawlers, and increasingly AI agents and assistants — and each of those audiences has different requirements that add to total page weight in ways a simple size threshold can’t distinguish between.

Why splitting content from metadata sounds appealing and doesn’t work

If machine-facing data is inflating page weight without benefiting users, the obvious fix looks like separating the two: serve a lean, human-facing page and a separate, stripped-down feed for crawlers and AI systems. Illyes didn’t reference any specific proposal along those lines by name, but he was clear about why Google doesn’t pursue that architecture.

His objection is pragmatic, not theoretical. Google already fields an enormous volume of spam — by Illyes’ estimate, tens of billions of spam URLs a day — and a parallel, lighter-weight channel built specifically for machines would be a much easier target to abuse than a page that has to render correctly for a human being. He also pointed to Google’s own history with separate mobile and desktop pages as a cautionary tale: maintaining two versions of the same content reliably produced mismatches, ranking confusion, and situations where a page ranked for content that didn’t exist on the version a user actually landed on. That experience is a big part of why search engines have converged on a single-document model, even though it’s less efficient than a split approach would be in theory.

“Is the website fat” is the wrong question

Illyes reframed the entire debate by pointing out that asking whether a website is bloated doesn’t really mean anything at the site level — a large site with thousands of pages is not comparable to a single overweight page. The meaningful version of the question is about individual pages getting heavier, not sites in aggregate. That reframing turns a vague complaint into something you can actually measure and act on.

Heavier pages still carry a real cost, even when the framing is nuanced

None of this nuance means page weight doesn’t matter. Splitt was direct about the tradeoff: data he referenced elsewhere shows faster sites see better retention and better conversion rates, and page size is a direct input into speed. More data means more time for the network to transfer it and more processing time on whatever device renders it. Illyes summed up the stakes plainly: shipping unnecessary weight wastes resources, on both the server and the visitor’s end.

The practical takeaway for site owners isn’t “shrink your page at all costs” — it’s “know what’s making your page heavy before you decide whether that weight is a problem.” A page loaded with genuinely useful content, necessary structured data, and required compliance markup is doing something different from a page padded with redundant scripts or unoptimized assets, even if both show the same file size in a crawl report. Auditing what Googlebot can actually process, understanding how byte limits shape crawling architecture, and separating machine-facing markup from bloat rather than lumping them together is a far more useful exercise than chasing a single page-weight number down. It’s also worth revisiting the counterpoint Google made in an earlier discussion, where the message was that growing page sizes still matter even if the “bigger is automatically worse” framing doesn’t hold up.

Frequently asked questions

Is a larger page size bad for SEO?

Not automatically. Google’s own engineers argue that page weight only matters in context — a large page full of genuine content or necessary markup is different from a large page padded with unnecessary overhead, even though both would show the same number in a size audit.

What’s the difference between HTML size and total page weight?

HTML size refers only to the markup document itself, which is what governs Googlebot’s roughly 2-megabyte crawl limit per page. Total page weight includes everything else the page loads — CSS, JavaScript, images and fonts — which is what actually affects load speed for a human visitor.

Does compression change how page weight should be measured?

Yes. A page can transfer as roughly half its uncompressed size over the network thanks to server-side compression like Brotli, then expand back to full size once the browser decompresses it. That means the “size” of a page depends heavily on which stage of delivery you’re measuring.

Why doesn’t Google separate content for users from content for AI crawlers?

Google has considered similar ideas and rejected them, largely because a lighter, separate channel built for machines would be easier for spammers to exploit, and because past experience with separate mobile and desktop pages showed that maintaining parallel versions of a page reliably causes ranking and consistency problems.

What should site owners actually do about page weight?

Focus on individual pages that have genuinely grown heavier over time rather than the site as a whole, and distinguish between weight that delivers real value — content, necessary structured data, compliance markup — and weight that’s simply unoptimized overhead.