TL;DR Summary:
Page Size Redefined: Google experts clarify page size varies by measurement—HTML limited to 15MB for crawling, but images/CSS/JS affect user speed differently, with compression shrinking transfer sizes dramatically.Value Over Volume: Larger pages with useful content outperform small bloated ones; focus on content-to-overhead ratio rather than raw size for better user value and SEO.Performance Priority: Individual page speed matters for retention and conversions, not total site weight—heavy pages hurt mobile users, demanding smart optimization without cutting essential machine-readable data.Does page size actually matter for SEO and website performance?
Google’s recent podcast with Gary Illyes and Martin Splitt revealed something surprising: larger web pages aren’t necessarily a problem. This goes against what most website owners have been told for years.
The confusion starts with how we measure page size in the first place.
Page Size Depends on What You’re Actually Measuring
When someone says a webpage is “heavy,” they might mean completely different things. Martin Splitt explains that page size depends on what you’re measuring.
Are you looking at just the HTML code? Or are you including images, CSS files, and JavaScript? These create two very different conversations.
Here’s why this matters: Googlebot limits HTML crawls to 15 megabytes per page. That sounds restrictive until you realize 15 megabytes of HTML equals about 15 million characters. That’s roughly the same amount of text as 15 novels.
When you add images, CSS, and JavaScript to the mix, you’re now talking about user experience and loading speed, which is a different issue entirely.
The Web Almanac found that median page size grew from 845 kilobytes in 2015 to 2.3 megabytes in July 2025. These numbers sound alarming, but they mix different types of page weight measurements, which makes them hard to interpret.
Compression Changes Everything About Page Size
Your actual page size gets complicated because of compression. Most servers use compression algorithms like Brotli to shrink files before sending them to browsers.
Here’s how this works: a webpage might be 10 megabytes when fully loaded on your device. But when that same page travels over the internet from the server to your browser, compression might reduce it to just 5 or 6 megabytes.
So which number represents the real page size? The 10 megabytes your device processes, or the 5-6 megabytes that actually traveled over the network?
Martin Splitt points out this creates confusion: “When you ask people what they think, if this is big or not, you start getting very different answers depending on how they think about page size. And there is no one true definition of it.”
This ambiguity means that page weight as a metric loses much of its meaning.
Large Pages Can Deliver More Value Than Small Ones
Google’s team made an important distinction: a large page isn’t automatically inefficient. They gave an example of a 15-megabyte HTML document that was acceptable because “pretty much most of these 15 megabytes are actually useful content.”
Compare that to a 5-megabyte page where most of the weight comes from unnecessary markup and very little actual content. Which page is really “worse”?
The ratio of useful content to overhead matters more than raw page size. A page heavy with valuable information serves users better than a lightweight page filled with bloated code.
This shifts the focus from arbitrary size limits to what the data actually represents.
Why Pages Include Content Users Never See
Much of what makes modern webpages heavy comes from content users never directly see. Gary Illyes points to structured data as a prime example.
Structured data helps search engines understand your content, but it adds weight to every page. The same goes for metadata required for regulatory compliance, licensing information, and code that serves third-party tools.
This reveals a structural reality: webpages aren’t built only for human readers anymore. They serve search engines, AI systems, analytics tools, and other automated systems. Each of these requirements adds weight.
Publishers face a choice between lighter pages and better search visibility. Most choose the extra weight because it brings more traffic.
Separating User Content from Machine Data Doesn’t Work
One obvious solution would be serving different versions of content to humans versus machines. Users would get lightweight pages, while search engines would access the full data.
Gary Illyes dismisses this as “utopic” because spammers would exploit it immediately. Google already catches billions of spam URLs daily. Separate content streams would multiply spam problems.
Google’s experience with mobile and desktop versions taught them that separate content creates consistency problems. Users often land on pages missing the content they searched for because the ranking came from a different version.
This is why search engines prefer single-document models, even when they’re less efficient.
Website Size Versus Individual Page Performance
Gary Illyes makes a crucial distinction: “The first question is, are websites getting fat? I think this question is not even meaningful. Because it does not matter in the context of a website if it’s fat. In the context of a single page, yes. But in the context of a website, it really doesn’t matter.”
The focus should be on individual page performance rather than overall website weight. A site with 10,000 pages doesn’t load differently because it has many pages. Each page loads based on its own size and optimization.
This reframes the entire discussion from abstract website bloat to measurable page-level performance.
Heavy Pages Still Create Real Problems for Users
Even though page size definitions vary, heavier pages carry real costs. Martin Splitt acknowledges this: “I think we are wasting a lot of resources. We know that there are studies that show that websites that are faster have better retention and better conversion rates.”
Faster sites keep more visitors and convert better. Page size directly affects loading speed because larger files take longer to transfer and process.
The performance impact hits mobile users hardest. A 2.3-megabyte page on a slow connection creates frustrating delays that drive users away.
Resource waste extends beyond individual user experience. Heavier pages consume more bandwidth, processing power, and battery life across millions of devices.
For WordPress site owners dealing with plugin conflicts and optimization challenges, this creates a clear need for unified performance solutions. The complexity of balancing useful content with efficient delivery requires tools that understand both the technical requirements and user experience impacts. WP Website Speedy addresses these concerns by automatically optimizing page delivery without removing the structured data and metadata that help your site rank in search results.
