Why mobile Core Web Vitals matter more than desktop
If you have to pick which Core Web Vitals number to chase, pick mobile. There are two reasons, and one of them is decisive.
Reason 1: Google uses mobile for ranking
Google switched to mobile-first indexing in 2019 — which means the mobile version of your page is the version Google uses for rankings. Your desktop LCP can be 800ms and it won't save you if the mobile LCP is 4.5s.
This is true even for pages whose primary audience is desktop. The signal Google's ranking algorithm looks at is the mobile number.
Reason 2: mobile is where performance problems hide
Desktop users are usually on fast WiFi and fast CPUs. Mobile users are a much wider distribution:
- Network speeds range from LTE to flaky 3G to captive-portal hell
- Device CPUs range from M-series iPad tier to $100 Android with a 2-core chip
- Memory pressure causes background tabs to get evicted, pages to reload constantly
This is why CrUX mobile data is almost always worse than desktop. You haven't built a faster page for desktop — you've built the same page that runs on faster hardware.
How to check each
This tool shows combined, mobile, and desktop data separately:
/example.com— all form factors combined/example.com/mobile— phone form factor (what Google uses for ranking)/example.com/desktop— desktop form factor
Compare the two. If mobile LCP is 2x desktop LCP, your JavaScript bundle is likely the bottleneck — desktop CPU can parse it fast, mobile can't.
Fixes that help mobile more
These optimizations disproportionately help mobile because mobile is CPU-constrained, not network-constrained, for most modern phones with decent 4G/5G:
- Reduce JavaScript bundle size (tree-shake, code-split, remove dead deps)
- Server-render above-the-fold content (don't wait for React to hydrate)
- Serve AVIF/WebP images at responsive sizes (mobile shouldn't download a 2400px hero)
- Use
content-visibility: autoto skip off-screen layout work - Reduce third-party JavaScript — it taxes mobile CPU hardest
Fixes that don't move mobile much
- CDN with fast TTFB (helps, but mobile users see CDN latency too)
- HTTP/2 push (deprecated anyway)
- Critical CSS inlining (helps a bit, but rarely the bottleneck)
Focus the effort where the biggest gap is, and that's almost always JavaScript parse time on mobile CPU.
By Paulo de Vries · Published