Why are Core Web Vitals a disaster on mobile despite the mobile-first approach?

What do these numbers really reveal about the state of mobile web?

The data is indisputable: only 1 in 5 sites pass the Core Web Vitals benchmark on mobile. This is catastrophic considering that over 60% of global web traffic now comes from mobile devices.

The 13-point gap between desktop and mobile is not marginal. It reflects a technical reality: optimizing for mobile remains fundamentally more complex. Limited bandwidth, less powerful processors, variable network latency — these constraints are absent on desktop.

Why does this gap persist when mobile-first has existed since 2019?

The shift to mobile-first indexing should have triggered awareness. However, sites continue to develop desktop-first and then adapt for mobile — often poorly. Teams test on desktop, optimize on desktop, and only discover mobile issues once in production.

The problem is exacerbated by modern JavaScript frameworks that generate bulky bundles. A poorly configured React or Next.js site can easily push 500 KB of JavaScript before displaying any content. On a recent iPhone with 5G, it's manageable. On an average mid-range Android device on 4G — which accounts for the majority of global traffic — it's a disaster for LCP.

What are the three metrics involved and their actual thresholds?

The Core Web Vitals measure three distinct aspects: Largest Contentful Paint (LCP) must load in under 2.5 seconds, First Input Delay (FID) — now INP — must remain under 200 milliseconds, and Cumulative Layout Shift (CLS) must be less than 0.1.

For a site to be deemed ‘good’, **75% of real visits** — measured through the Chrome User Experience Report — must meet these three thresholds simultaneously. If any single metric fails on 30% of your visits, you drop out of the “green”.

• 33.1% success on desktop means that two-thirds of sites even fail under the optimal conditions of a desktop computer
• 20% on mobile reflects a massive failure of the web industry to adapt to the real constraints of users
• The 13-point gap between the two platforms reveals that desktop optimizations do not automatically translate
• These statistics include all types of sites, from WordPress blogs to complex e-commerce sites
• Google measures this data on real connections and devices, not in lab conditions with fiber optics

Do these numbers truly reflect the on-ground reality observed in our clients?

Honestly? Yes, and it’s even worse than what Google communicates. In real-world audits, I would say that less than 10% of e-commerce sites actually pass the three metrics on mobile in real conditions. The 20% announced by Google likely includes many simple showcase sites with little JavaScript.

The problem is that Google communicates averages. But in real life, a standard Shopify site with 10-15 third-party apps will systematically fail CLS and LCP on mobile. A WordPress site with Elementor and 8 plugins? The same. Marketing frameworks — Facebook pixels, Google Analytics 4, chatbots — are silent killers of Core Web Vitals.

Why doesn't the desktop-mobile gap close despite years of warnings?

Because the economic incentives are not aligned. Web agencies charge by package, not by performance. Delivering a site that “works” on desktop is enough to validate a client recipe. No one actually tests on a Samsung Galaxy A13 on 3G — the global median device.

And let’s be honest: optimizing for mobile is costly. It involves rethinking the architecture, smart lazy-loading, sizing images by breakpoint, and preloading critical resources. That's 30-40% additional dev time that most projects do not budget for. [To be verified] — Google does not specify whether these 20% include only sites with significant traffic or all crawled domains.

Should we then ignore desktop just because mobile is majority?

No, that would be a strategic mistake. Desktop still converts better across most e-commerce verticals. Desktop users have average baskets 20-30% higher and conversion rates often double. It’s not the volume of traffic that matters — it’s the business value.

But here’s the trap: with mobile-first indexing, Google crawls and evaluates your site via its mobile version. If your mobile is poor in Core Web Vitals, your overall ranking suffers, desktop included. You end up with less qualified desktop traffic because your mobile is terrible. Mobile optimization is no longer an option — it's a sine qua non condition to perform on both platforms.

Where to start effectively to bridge the mobile-desktop gap?

The first step: measure your actual situation. Forget about Lighthouse locally — it reflects nothing. Connect to PageSpeed Insights with CrUX data (Chrome User Experience Report). These are the real data from your real users on their real devices, which are often struggling on fickle 4G.

If you discover that your mobile LCP is at 4.5 seconds while your local Lighthouse showed 2.1 seconds, welcome to reality. The gap comes from the fact that Lighthouse simulates a theoretical 4G connection, not a real 4G connection with variable latency and packet loss. The CrUX data, however, does not lie.

What are the three optimizations that yield the most impact on mobile?

First lever: the weight of images. On mobile, an unoptimized hero image can weigh 800 KB and kill your LCP. Convert everything to WebP or AVIF, size it precisely according to the viewport, and lazy-load everything that is not above-the-fold. Use srcset with a minimum of 3 breakpoints: 375px, 768px, 1024px.

Second lever: JavaScript. Each third-party framework — analytics, chat, marketing pixels — adds 50-150 KB. On mobile, this translates to an additional execution delay of 300-800 ms. Load everything asynchronously except for the strict minimum for the initial render. Use Google Tag Manager in asynchronous mode, chatbots that initialize after user interaction, pixels that load after 3 seconds.

Third lever: CLS. Reserve explicit space for each element that loads asynchronously. Ad banner? `min-height` defined in CSS. Custom font? `font-display: swap` with a fallback sized identically. Image? Mandatory `width` and `height` attributes. Every element that “pushes” content after loading degrades your CLS — and on mobile, this is amplified due to narrower viewports.

How to avoid classic mistakes that specifically hinder mobile?

Mistake number 1: testing only in responsive mode in Chrome DevTools. It does not simulate the real CPU power of a mobile device. JavaScript that executes in 80 ms on your MacBook Pro will take 450 ms on a mid-range Android. Use 4x or 6x CPU throttling in DevTools, or better: test on real devices.

Mistake number 2: neglecting web fonts. A site that loads 4 custom fonts in 6 different weights easily pushes 300 KB of fonts — blocking text rendering during this time. On mobile, prioritize system fonts, or limit yourself to 2 weights maximum of a single font. Preload the critical font with `` and use `font-display: swap` systematically.

• Audit real CrUX data via PageSpeed Insights, not just local Lighthouse
• Implement responsive srcset for all images with minimum breakpoints of 375px, 768px, 1024px
• Defer the loading of all non-critical third-party scripts (analytics, chat, pixels) after 3 seconds or after interaction
• Explicitly reserve space for each dynamically loaded element with width/height or min-height
• Test on real mid-range Android devices with 4G network throttling, not just in desktop responsive mode
• Limit web fonts to 2 weights maximum of a single family, preload the critical font, use font-display: swap