Gary Illyes and Martin Splitt of Google’s Search team sat down for a candid, unscripted conversation on Search Off the Record — and what came out of it was more honest than most official Google communications tend to be. No PR polish. No prepared talking points. Just two engineers working through a question that sounds simple until you actually try to answer it.
Are websites getting fat?
The short answer: yes, dramatically. The longer answer is where it gets interesting for anyone who builds, owns, or optimises websites for a living.
Post Summary:
- The median mobile web page has grown 202.8% in a decade — from 845KB in 2015 to 2.36MB in July 2025
- Page weight growth is outpacing mobile connection speed improvements
- Gary Illyes raised a rarely-discussed tension: structured data adds machine-readable bloat that users never see but always pay for
- Googlebot’s 2MB HTML fetch limit means bloated pages get silently truncated — with no warning in Search Console
- The definition of “page weight” itself is contested — and that confusion has real consequences for how developers optimise
I’ve been following Google’s public communications for a long time, and the Search Off the Record format consistently produces the most useful material they put out — precisely because it’s unscripted. Gary Illyes opening by saying “I don’t have a topic” and then proceeding to have one of the more substantive technical conversations in recent memory is peak Search Off the Record. This one is worth your time, and here is why.
Timeline: A Decade of Web Page Weight
In July 2015, the median mobile homepage was 845KB. As of July 2025, the same median page is now 2,362KB — a 202.8% increase over the decade. The median desktop homepage saw a 110.2% increase over the same period.
To put that in the unit of measurement Martin Splitt actually used on the podcast: a standard floppy disk holds 1.44MB. The median mobile page in 2015 fit on half a floppy. The median mobile page in 2025 requires nearly two.
Year over year, the median mobile homepage grew 8.4% from 2.4MB in 2024 to 2.6MB in 2025. Desktop grew 7.3%, reaching 2.9MB.
| Year | Median Mobile Page | Median Desktop Page |
|---|---|---|
| 2012 | ~288KB | ~669KB |
| 2015 | 845KB | — |
| 2022 | 2,037KB | 2,312KB |
| 2024 | 2,311KB | 2,652KB |
| July 2025 | 2,362KB | 2,862KB |
Source: HTTP Archive Web Almanac 2025
What “Page Weight” Actually Means — And Why Nobody Agrees
One of the most practically useful moments in the episode was Splitt’s admission that when he asked his Bluesky followers what page size means, he got completely different answers from different people. That is not a minor confusion — it changes what you measure, what you optimise, and what you report.
The three most common interpretations:
- Raw HTML bytes — what Googlebot fetches from the parent URL
- Transferred bytes over the wire — which compression reduces significantly
- Total bytes downloaded to the user’s device — HTML plus CSS, JavaScript, images, fonts, everything
The median mobile homepage weighs 2.56MB. Desktop is heavier at 2.86MB. Inner pages are considerably lighter: 1.77MB on mobile and 1.96MB on desktop.
The Web Almanac definition — total volume of data the user must download to view the page — includes images and everything else. That is why the 2015 figure of 845KB surprised Splitt: even with images included, it was still under a megabyte.
The confusion matters because a developer optimising for “HTML size” and a developer optimising for “total transfer size” are doing fundamentally different work — and may be measuring completely different things when they report results.
“There is no one true definition of page size. And I realized that when I asked this question publicly, different people had very different notions of how they understood page size.” — Martin Splitt, Google Search Relations, Search Off the Record, March 2026
What Is Actually Making Pages Heavier
Images account for 36 to 37 percent of total page weight. On a median mobile homepage, that is 911KB out of 2,559KB devoted to images. Images are the single largest resource type.
But the more interesting finding from the Web Almanac is what is happening with JavaScript. Mobile page weight grew 8.4% year over year in 2025. Despite all the optimisation tools available, pages are still getting heavier. The number of scripts on the median page has remained more or less stable — suggesting the increase in JavaScript weight is coming because individual scripts are becoming heavier, not because more scripts are being added.
Most of this growth comes from images and JavaScript, while HTML remains a relatively small part of total transfer size.
The emerging contributors Illyes flagged in the conversation are worth noting:
- Structured data — added for machine readability, invisible to users, but it inflates HTML size with every additional schema type implemented
- Inline images — developers sometimes base64-encode images directly into HTML to avoid an extra network request, producing HTML files measured in tens of megabytes
- Third-party scripts — analytics, chat widgets, ad tags, and personalisation tools that load regardless of whether the user interacts with them
The WHATWG HTML Living Standard — cited in the episode as an extreme reference point — has a single-page HTML version that weighs 14MB. It is, as Illyes noted, “not a fancy website” — mostly text with minimal styling. Which means 14MB of content that is genuinely useful. That is a very different situation from a 5MB page where most of the weight is framework overhead and unused CSS.
The Googlebot Problem Nobody Is Talking About Enough
The episode surfaces something that deserves more attention than it typically gets. Googlebot has a 2MB HTML fetch limit. If your HTML file is larger than 2MB, Googlebot does not reject the page — it stops the fetch exactly at the 2MB cutoff. That downloaded portion is passed to indexing systems as if it were the complete file. Any bytes that exist after the 2MB threshold are entirely ignored — not fetched, not rendered, not indexed.
And the alarming detail confirmed by independent testing: Google Search Console shows the page as indexed with no errors. Everything looks normal. The truncation happens silently.
Illyes discussed the broader 15MB default that applies across Google’s entire crawl infrastructure — for images, CSS, JavaScript, and other resources fetched separately. Each referenced resource gets its own byte counter. The 2MB limit applies specifically to the parent HTML document for Search.
Who actually needs to worry about this:
- Large e-commerce sites loading full product catalogues as inline JSON
- Pages with inline base64-encoded images
- Content platforms that embed large structured data blocks
- Sites with enormous navigation menus baked into every page’s HTML
According to the HTTP Archive Web Almanac 2025, only 0.82% of all analysed pages exceed 2MB. The median HTML file is around 33KB — approximately 60 times smaller than the limit. But for the sites that do hit it, the failure is invisible by default.
The Structured Data Tension Gary Illyes Raised Directly
This is the part of the conversation most SEOs will find most interesting — because Illyes is a Google Search team member openly expressing ambivalence about a Google-promoted feature.
His point: Sergey Brin’s early vision for Google was that computers should be able to figure out everything from plain text alone. Structured data is, by definition, a departure from that — it is markup added specifically for machines, not users. And Google supports a lot of schema types.
“If you keep piling on structured data on your pages — basically stuff that users will never actually see — then what? Is that good? Is that bad? For the site, it’s probably good, or it can be good. But for the user? I don’t know.” — Gary Illyes, Google Search Central, Search Off the Record, March 2026
This is not an argument against structured data. It is an honest acknowledgement that structured data adds weight that users never benefit from directly, and that this weight has a cost — particularly for users on slow or metered connections. The trade-off is real. It is rarely discussed this plainly.
Does Page Weight Actually Affect Business Results?
Illyes acknowledged in the episode that he personally does not feel the pain of heavy pages — he has a 10-gigabit home connection and permanent 5G on his phone in Switzerland. He is aware this is a bubble. The moment he travels to less developed markets, the experience changes entirely.
The data on business impact is clear and has been for years. Pages that take longer than three seconds to load tend to have much higher bounce rates, and additional delays are strongly linked to lower conversion rates.
Every additional 100KB adds approximately 50ms of load time on a 4G connection. For a 5MB page versus a 2MB page, the gap reaches 1.5 seconds. Loading a 2.6MB page costs approximately $0.32 USD in mobile data in some countries. At scale — 100,000 visitors per month — server bandwidth costs increase proportionally. Transferring 1GB of data emits roughly 0.3g of CO₂. A site with 100,000 page views per month and 5MB pages generates approximately 150kg of CO₂ per year from data transfer alone.
Only 48% of mobile pages pass all three Core Web Vitals. Desktop is better at 56%, but that still means nearly half of all websites fail Google’s performance standards.
The performance research Splitt referenced — that faster sites have better retention and conversion rates — is well-established. Google’s Think with Google research consistently shows that as page load time increases from one to three seconds, the probability of a user bouncing increases by 32%.
How to Check Your Own Page Weight
Splitt committed to a follow-up episode on specific optimisation techniques. In the meantime, the episode’s own references point to the most reliable methods:
“My own method of checking for the 2MB Googlebot limit? Searching for a quote from further down a page to see if Google has indexed it. No need to weigh bytes.” — John Mueller, Google Search Central (via community post, 2026)
Practical checks:
- Open Chrome DevTools (F12) → Network tab → reload the page → look at the HTML document size under “Size” (uncompressed)
- Right-click any page → View Page Source → check file size in the browser tab
- Use Screaming Frog, sort by “Size” descending (use the uncompressed column) — flag anything over 1MB for investigation
- The HTTP Archive Web Almanac provides annual benchmarks against which you can compare your own pages
Tips to reduce page weight without breaking anything:
- Move inline CSS and JavaScript to external files — each gets its own separate byte counter from Googlebot
- Use WebP or AVIF image formats instead of JPEG or PNG where browser support allows
- Enable Brotli compression at the server level — more efficient than GZIP for text-based resources
- Audit and remove unused third-party scripts — analytics tags, chat widgets, and ad frameworks loaded on every page regardless of user interaction are a common source of avoidable weight
- Place critical elements — meta tags, canonical tags, structured data — near the top of the HTML document, before any heavy content that risks being cut off at the 2MB limit
- Use lazy loading for images below the fold — but not for the LCP image, which should load as early as possible
Comparing Page Weight Across CMS Platforms (2025)
Squarespace produces the heaviest sites with a median mobile weight of 3,974KB. Joomla and WordPress are the lightest at 2,900KB and 2,894KB respectively.
| CMS | Median Mobile Page Weight |
|---|---|
| Squarespace | 3,974KB |
| Joomla | 2,900KB |
| WordPress | 2,894KB |
| Web average | ~2,362KB |
Source: HTTP Archive Web Almanac 2025, CMS chapter
The platform you build on sets a weight floor before you write a single line of custom code. Squarespace users start at nearly 4MB before any customisation.
Frequently Asked Questions
Is page weight a direct Google ranking factor? Not directly — Core Web Vitals (LCP, INP, CLS) are the ranking signals, and they are influenced by page weight but not identical to it. A heavy page can still pass Core Web Vitals if resources are well-prioritised and loaded efficiently. A lightweight page can fail if JavaScript blocks rendering. The relationship is real but indirect.
Does structured data contribute meaningfully to page weight? It can, yes — particularly if multiple schema types are implemented across every page. JSON-LD blocks are relatively compact per type, but a page implementing Article, BreadcrumbList, FAQPage, Product, and Organisation schema simultaneously adds several kilobytes of machine-readable markup that users never see. The trade-off is worth it for most sites, but the weight cost is real.
If my page is over 2MB HTML, will Google tell me? No. Testing has confirmed that Search Console reports oversized pages as “indexed” with no errors. The only reliable check is to inspect the raw HTML file size directly using browser developer tools or a crawler like Screaming Frog.
Does compression solve the page weight problem? Partially. Brotli and GZIP compression reduce the bytes transferred over the network significantly — often by 60–80% for text-based resources. But the browser still decompresses and stores the full file size locally. Users on limited device storage still pay the full uncompressed cost. Googlebot’s 2MB limit also applies to uncompressed bytes.
Are mobile pages catching up to desktop in weight? Yes, and fast. In 2010, a mobile page weighed 2.5 times less than a desktop page. By 2024, the gap was only 13%. Mobile follows desktop with roughly a 2-year lag. Mobile-specific optimisations like responsive images and lazy loading are no longer offsetting the overall growth in resources.
The Honest Conclusion From Two Engineers Who Actually Know
The most refreshing thing about this episode is what Gary Illyes said at the end. Asked whether we need to do anything to reduce page sizes, he gave an honest rather than a diplomatic answer: faster connections mean heavy pages hurt him less personally. But he travels, and the moment he leaves Switzerland, the reality changes. The median user is not on a 10-gigabit fibre connection in Zurich.
Splitt’s point is the one worth carrying into your next site audit: the median web page is 8% bigger than it was just one year ago. At that rate, the median page could reach 3MB within the year.
The tools to address this exist. The motivation — better user experience, better Core Web Vitals, safer distance from Googlebot’s silent truncation limit — is clear. The episode’s practical takeaway is not panic. It is awareness: know what your pages actually weigh, know where the weight is coming from, and make deliberate decisions about what is worth carrying.
Further reading: