The Illusion of Speed: Why Misunderstood Page Weight Hinders Web Performance

The web is growing, but is it getting "fat"? This conversation with Google's Gary Illyes and Martin Splitt reveals that while pages are indeed expanding, the real problem isn't just size, but a fundamental misunderstanding of what "page weight" means and why it still matters. The non-obvious implication? Our current definitions and assumptions about web performance are failing us, potentially excluding users and hindering search engine effectiveness. Developers, SEO professionals, and anyone invested in the health of the web should read this to understand the hidden costs of bloat and how to build more resilient, accessible online experiences. The advantage gained is a deeper, more nuanced understanding that moves beyond superficial metrics to address the real-world impact of data transfer and processing.

The Illusion of Speed: Why "Fat" Pages Still Hurt

The initial question, "Are websites getting fat?", is deceptively simple. As Gary Illyes and Martin Splitt unpack it, the term "fat" itself is problematic, masking a deeper confusion about what constitutes page size and, more importantly, why it matters. The Web Almanac shows a dramatic increase in median mobile homepage size, from 845 KB in 2015 to 2.3 MB in 2025 -- a threefold increase. This isn't just about raw bytes; it's about the diverse interpretations of what those bytes represent. For users, it's the data needed to render a page, including images and other resources. For Googlebot, it’s a more constrained limit, typically 15 MB per URL, with sub-resources having their own limits. This discrepancy highlights a core tension: what’s manageable for a user on a fast connection is a significant hurdle for those on slower networks or with limited device storage.

"What is page size? It's a surprisingly difficult answer."

-- Martin Splitt

The conversation quickly pivots from the abstract "fatness" to the concrete implications of this growth. While high-speed connections like 10-gigabit fiber or constant 5G might mask the pain for some users, the reality for many others, especially in less developed regions or even in specific local environments like parking garages, remains starkly different. Martin recounts a metered satellite connection in Antarctica where 100 MB was a precious commodity, forcing him to disable data-saving features and avoid resource-intensive apps. This isn't a niche problem; it's a systemic exclusion. The assumption that faster networks have eliminated the problem of page weight is a dangerous fallacy, a first-order solution that ignores the downstream consequences of data accessibility and cost.

The problem is exacerbated by the sheer volume of data, particularly HTML. The HTML Living Standard, a single-page version, clocks in at a staggering 14 MB. While this is text-heavy content, it underscores how even the foundational structure of the web can become a significant data burden. The practice of inlining images directly into HTML, turning them into long strings of characters to avoid separate network requests, can inflate HTML files to 50 MB or more. This is a classic example of a seemingly clever optimization that creates a much larger problem down the line, impacting processing time and storage.

"I realized that some i was living in the same era so yeah i distinctly remember this yeah but like john for instance also lives in this or lived in the same era and he is like who thinks of floppy disks so you know i thought i explained i'm pretty sure our boss john miller was born roughly when the pharaohs were still running around but anyway he was probably here when electricity was invented yes yes"

-- Gary Illyes

This leads to the complex territory of structured data. Gary expresses a historical "beef" with structured data, noting its primary purpose is for machines, not users. While it can drive additional traffic by enabling richer search results, its inclusion significantly increases page bloat. The irony is that this machine-readable data, intended to enhance search, can paradoxically hinder it if it pushes pages beyond crawl limits or significantly slows down processing for both users and bots. The idea of separating metadata from user-visible content, perhaps via API endpoints for trusted clients, is floated as a utopian solution, but the reality of internet spam -- billions of URLs caught daily -- suggests this could exacerbate the problem rather than solve it. The principle of Hypermedia as the Driver of Application State (HATEOAS), which advocates for different representations of resources for different consumers, is a relevant concept here, but its adoption seems to have waned.

The conversation also touches upon the critical issue of parity between mobile and desktop versions of websites. The mobile-first indexing initiative revealed widespread discrepancies, with content, links, navigation, and even metadata missing on mobile versions when they were served from different URLs. This highlights how seemingly minor decisions in site architecture can have cascading negative effects on user experience and search rankings, demonstrating that even "trivial" differences can lead to significant problems.

Key Action Items: Navigating the Bloat

• Immediate Action: Re-evaluate your definition of "page size" and "page weight." Understand the difference between raw bytes, compressed transfer size, and on-device storage.
• Immediate Action: Audit your website's current page weight, focusing on median mobile homepages. Identify the primary contributors to bloat (HTML, images, scripts, structured data).
• Immediate Action: Implement image optimization techniques. This includes compression, using appropriate formats (WebP, AVIF), and responsive images that serve appropriately sized assets based on the user's device.
• Immediate Action: Review your use of structured data. While beneficial, ensure it's not excessively bloating your HTML and consider if all implemented structured data is truly necessary for your site's goals.
• Short-Term Investment (1-3 Months): Explore and implement transport-level compression (Gzip, Brotli) for your website's assets.
• Short-Term Investment (1-3 Months): Investigate lazy loading for images and other non-critical resources to improve initial page load performance.
• Long-Term Investment (6-18 Months): Develop a workflow that prioritizes efficient image handling from content creation through to deployment, potentially instituting internal limits on image file sizes. This requires a cultural shift and tooling.
• Strategic Consideration: Assess the necessity of serving significantly different content or functionality between mobile and desktop versions of your site, especially if using separate URLs. Aim for parity to ensure consistent user experience and search engine visibility.