Has mobile page weight really tripled in just one decade?

Where does this explosion in page weight come from?

The Web Almanac reveals a heavy trend: the median weight of mobile pages has tripled over 11 years. Several factors explain this drift: proliferation of JavaScript frameworks, unoptimized high-resolution images, multiplication of third-party scripts (analytics, advertising, chatbots), and unminified CSS/JS.

This inflation is not harmless. It translates into degraded loading times, especially on slow networks (3G, unstable 4G). Yet, Google has clearly indexed speed as a ranking factor through Core Web Vitals since mid-2021.

What does a median weight of 2.3 MB concretely mean?

Concretely, 2.3 MB represents approximately 80 HTTP requests on average. On a 3G connection (around 1.6 Mbps), this gives a theoretical download time of ~11 seconds—not counting parsing and rendering. The median also masks extreme situations: some sites exceed 5-6 MB.

For an SEO practitioner, this poses a direct problem: the LCP (Largest Contentful Paint) explodes. If your hero image weighs 800 KB and arrives after 2 MB of JS, you're out of bounds. The "good" LCP threshold is 2.5 seconds—difficult to achieve with such ballast.

Why is Gary Illyes making this statement now?

Gary Illyes isn't throwing out this figure by accident. Google is observing a widespread degradation of performance in its index. By pointing out this inflation, he's sending a clear message: SEOs and developers must regain control of page weight.

This statement is part of Google's ongoing discourse on user experience. After introducing Core Web Vitals, the search engine is reminding us that technical optimization remains a prerequisite—not a cherry on top of the cake.

• The median weight has tripled: from 845 KB to 2.3 MB in 11 years
• JavaScript and images are the main culprits behind this inflation
• Direct impact on Core Web Vitals, particularly LCP and FID
• Mobile sites are hit hardest: slow networks + high weight = UX disaster
• Google reiterates that speed remains a ranking criterion

Is this statement consistent with what we observe in the field?

Yes, absolutely. The audits I conduct systematically show pages that easily exceed 3-4 MB, especially on e-commerce and media sites. The problem is that many clients don't even measure their page weight—they discover the figure during the initial audit.

What strikes me is that this inflation is often invisible on desktop. With fiber connections and powerful machines, internal teams don't feel the pain. But as soon as you test on a real mobile device, on throttled 4G, reality hits: 8-10 seconds to display the main content.

What nuances should we add to this finding?

Gary Illyes is talking about the median, not the average. This means that 50% of sites are above 2.3 MB. But be careful: some very well-optimized sites stay under 1 MB, even with rich content. The problem is therefore not a technical inevitability—it's a matter of discipline and priorities.

Another nuance: raw weight doesn't tell the whole story. A site weighing 2.3 MB with intelligent lazy loading, code-splitting, and HTTP/2 can load faster than a poorly structured 1.5 MB site. Weight is an indicator, not automatic condemnation. [To verify]: Gary Illyes doesn't specify whether Google weighs the raw weight or takes into account deferred loading strategies in its assessment of Core Web Vitals.

In what cases does this rule not apply strictly?

If you operate a site as a PWA (Progressive Web App) with a properly configured service worker, initial weight matters less: caching does the job for subsequent visits. Same for sites with high repeat traffic (SaaS, business tools) where the user only sees the weight once.

But let's be honest: for a typical content site (blog, e-commerce, media), the first visit counts enormously. Google crawls like a new user—without cache. If your LCP explodes on the first load, you lose in ranking. The rule therefore applies to 90% of cases.

What should you concretely do to reduce page weight?

First priority: complete technical audit. Use WebPageTest, Lighthouse, and PageSpeed Insights to identify heavy resources. Next, scrutinize images, JavaScript, and CSS. Images often represent 50-70% of weight—compress them systematically.

For images, adopt modern formats (WebP, AVIF) with fallback. Implement native lazy loading (loading="lazy") for everything that isn't above-the-fold. On the JS/CSS side, minify, compress (Gzip/Brotli), and strip out everything that isn't critical.

What mistakes must you absolutely avoid?

Don't load 15 third-party scripts without auditing them. Every tracking pixel, every chatbot, every social widget adds 100-300 KB. Many of these scripts are unused or redundant. Triage: keep what truly serves your goals, defer or cut the rest.

Another pitfall: unoptimized web fonts. Loading 6 variants of a Google Font in WOFF2 can weigh 400 KB. Limit yourself to 2-3 weights maximum, use font-display: swap, and host locally if possible.

How do you verify that your site complies with best practices?

Test your site under multiple network conditions (3G slow, 4G, fiber) via Chrome DevTools. Total weight should ideally stay under 1.5 MB for mobile. If you exceed 2 MB, it's a red flag: dig into every resource over 100 KB.

Establish a performance budget in your CI/CD. Tools like Lighthouse CI or SpeedCurve can block a deployment if weight or LCP degrades. Automating monitoring prevents silent regressions.

• Audit page weight with WebPageTest and Lighthouse
• Compress all images (WebP/AVIF + lazy loading)
• Minify and compress JS/CSS (Gzip/Brotli)
• Triage third-party scripts: keep essentials, defer or remove extras
• Optimize web fonts: 2-3 variants max, font-display: swap
• Test on slow connections (3G slow) to detect regressions
• Implement automated performance budgeting in CI/CD