Mobile Core Web Vitals Failing: How to Fix It

What this check flags

This fires when your mobile CrUX data shows a failing Core Web Vitals assessment, meaning real Chrome users on phones are getting LCP, INP, or CLS numbers worse than Google's "good" thresholds at the 75th percentile. It matters more than the desktop equivalent because Google evaluates the Core Web Vitals ranking signal using the mobile experience, so a mobile fail is the one that actually costs you.

Mobile is the version Google grades

Under mobile-first indexing, Google crawls, indexes, and assesses your site as a phone would see it, and that includes Core Web Vitals. Your desktop numbers can be spotless while mobile quietly fails, and the ranking signal only cares about the failing one. Two things make phones brutal on vitals: CPUs a fraction as fast as a laptop, which punishes any JavaScript-heavy page through slow INP, and flaky mobile networks that stretch out LCP. If you've only ever tested on your own hardware over office wifi, you have never seen what Google is measuring. Confirm you're even being indexed mobile-first with mobile-first indexing verification before you dig into the vitals themselves.

A real example, and the fix

A common pattern: desktop passes, mobile fails on both LCP and CLS. The culprit is a responsive layout that loads the full-resolution desktop hero on mobile and reserves no space for a late-loading ad slot. Fix the image with proper responsive sources so phones download a phone-sized file:

<img srcset="/hero-480.avif 480w, /hero-960.avif 960w, /hero-1600.avif 1600w"
     sizes="(max-width: 600px) 100vw, 960px"
     src="/hero-960.avif" width="1600" height="900"
     fetchpriority="high" alt="Hero">

Then kill the layout shift by reserving space for anything that loads late, ad slots, embeds, images without dimensions:

/* Reserve the slot so nothing jumps when the ad arrives */
.ad-slot { min-height: 250px; }
img, iframe { aspect-ratio: attr(width) / attr(height); }

The phone now pulls a 480w image instead of a 1600w one, and the reserved space stops content from lurching downward when the ad fills in. That's an LCP win and a CLS win from two small edits.

Which vital is dragging mobile down

How to detect it

1. PageSpeed Insights, Mobile tab. This is the fastest read. The top card shows the field-data assessment for phones; if it's failing, the metric summary tells you whether LCP, INP, or CLS is the offender.
2. Search Console Core Web Vitals report. Open the Mobile report specifically. It groups your failing URLs by issue and shows how many URLs each template pattern affects, so you fix one template and clear hundreds of pages.
3. CrUX Dashboard or BigQuery. For origin-level trends over time, pull the public CrUX data. BigQuery lets you segment by device, so you can watch the mobile 75th-percentile line specifically instead of a blended number.
4. DevTools device emulation. In Chrome DevTools, toggle device mode, set CPU to 4x slowdown and network to Slow 4G, and profile. This is the closest you'll get to a real mid-range Android without buying one, and it exposes the long tasks wrecking INP.

How to fix it

1. Serve phone-sized images. Responsive srcset and sizes so a 375px screen never downloads a 1600px file, in modern formats.
2. Cut and defer JavaScript. Mobile INP lives and dies on main-thread work. Ship less JS, break up long tasks, and defer third-party scripts, the tactics in minimize main-thread work.
3. Reserve space to stop shifts. Width and height on every image, min-height on ad and embed slots, and no injecting content above what's already visible.
4. Test on a real mid-range phone. Emulation gets you close, but a $200 Android on real cellular is the ground truth. Whatever passes there passes for most of your users.

If desktop is also flagged, the fixes overlap heavily, see the sibling desktop CWV failing check.

The order of operations that actually works

Teams burn weeks here by fixing whatever the last tool complained about. Don't. Pull the mobile field data first and identify the single failing vital with the widest URL footprint, then find the one template driving it. Ship the fix to that template, confirm it landed for real users, and wait for the 28-day CrUX window to turn over before you judge it. Only then move to the next vital. Chasing three vitals across five templates simultaneously is how you end up unable to attribute any improvement to anything, and how a "quick performance sprint" becomes a quarter of thrashing. One template, one vital, measured, repeat.

FAQ

Desktop passes but mobile fails, do I still have a problem?

Yes, and it's the problem that counts. Google uses the mobile experience for the Core Web Vitals ranking signal, so a mobile fail is a real ranking exposure even with a perfect desktop score.

How long until fixes show up in Search Console?

CrUX is a 28-day rolling window, so field data updates gradually. Expect two to four weeks after a fix ships and gets crawled before the report flips from failing to passing, assuming the fix actually landed for real users.

My emulated mobile test passes but CrUX still fails. Why?

Emulation runs on your fast machine's CPU with a throttle applied; it can't fully reproduce a real budget Android's thermals and memory pressure. Trust the field data and test on actual hardware when the gap is stubborn.

Which mobile vital should I fix first?

Whichever is failing at the 75th percentile with the most affected URLs. In practice INP is the hardest on mobile because weak CPUs punish JavaScript, so if it's failing, start there.