Fixing Mobile-Only Core Web Vitals Failures

Why mobile fails when desktop passes

The thresholds are the same on both: LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, each at the 75th percentile of real visits. What changes is the visitor's hardware and screen, and those change every metric in a different way.

Because the causes differ, a single "mobile speed" fix rarely works. Find out which metric fails on mobile first, then look at the rows in this table that apply to it.

Reading the mobile numbers

Check which metric fails, and how widely

The Core Web Vitals checker shows field data for mobile and desktop side by side. Look at each metric separately: a mobile failure driven only by INP needs different work from one driven by LCP. In Search Console, the Core Web Vitals report has a separate Mobile section; open it and look at which issue each URL group has, such as "LCP issue: longer than 2.5s (mobile)".

Why a lab test on your desktop misleads you

Loading the page on a fast laptop with the window made narrow tests the layout, not the performance. Your laptop's processor, memory and connection are still much faster than a typical phone. The mobile test in PageSpeed Insights and Lighthouse applies simulated throttling to approximate a mid-range phone on a slow mobile connection, which is closer, but it is still one simulated load with no scrolling or tapping.

Look for mobile-only elements

Open the page in DevTools device mode at a phone width, such as 390 or 412 pixels wide, and list anything that appears only there: a sticky footer bar, a hamburger menu, a different hero, a cookie banner that takes half the screen, an app install banner or an anchored mobile advert. These are the usual suspects for mobile-only CLS and INP.

Collect real-device data

If you already collect Core Web Vitals with the web-vitals library, add the viewport width or a device category to each report. Splitting results by width often shows that one breakpoint, such as small phones under 400 pixels, accounts for most failures.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function report(metric) {
  sendToAnalytics({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    width: window.innerWidth,
    cores: navigator.hardwareConcurrency || null,
    connection: navigator.connection ? navigator.connection.effectiveType : null
  });
}
onLCP(report); onINP(report); onCLS(report);

The connection details are not available in every browser, so treat them as a hint rather than a complete picture.

Testing like a real phone

The most reliable test is a real mid-range Android phone connected to your computer. In Chrome on the computer, open chrome://inspect, enable USB debugging on the phone, and you can run the full DevTools Performance panel against the page running on the phone itself. Recordings from real hardware show the actual script timings and the actual LCP element.

If you do not have a suitable phone, use DevTools on your computer with these settings together:

• Device mode at a common phone width, with touch input.
• CPU throttling at a 4x or 6x slowdown in the Performance panel settings. Recent Chrome versions can suggest a calibrated setting for a mid-tier or low-tier mobile device.
• Network throttling on a slow 4G or "Fast 3G" profile.
• Disable cache ticked, and a fresh profile or guest window so no cookies or consent choices are stored.

The fix, step by step

Images for phones: the markup that matters

Oversized images are the most common reason mobile LCP is slower than it should be. The browser can only choose a sensible file if you offer several and tell it how wide the image will be displayed.

<img
  src="/img/walled-garden-800.jpg"
  srcset="/img/walled-garden-480.jpg 480w,
          /img/walled-garden-800.jpg 800w,
          /img/walled-garden-1200.jpg 1200w,
          /img/walled-garden-1800.jpg 1800w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  width="1800" height="1200"
  alt="Walled garden in early summer"
  fetchpriority="high">

Here a phone showing the image full width picks a file close to its screen width multiplied by its pixel density, instead of the 1,800 pixel version. The width and height attributes give the browser the shape so it can reserve space, and fetchpriority="high" is used only because this is the hero.

Different images per screen size

When the mobile hero is a different crop or a different picture, use picture so only the right one is downloaded:

<picture>
  <source media="(max-width: 600px)" srcset="/img/hero-portrait-600.webp" width="600" height="750">
  <img src="/img/hero-wide-1600.webp" width="1600" height="700" alt="Workshop bench with tools" fetchpriority="high">
</picture>

Giving each source its own width and height lets the browser reserve the right shape on each screen, which avoids a shift when the portrait crop is taller than the desktop one.

Edge cases

• Tablets. The Chrome UX Report records tablets separately, but Search Console's report is split into mobile and desktop only. Do not be surprised if a tablet layout issue is hard to see in Search Console.
• Interstitials and pop-ups. A pop-up that covers the page on mobile is a poor experience and can be a layout shift if it pushes content rather than overlaying it. It can also be the element measured as LCP if it is large and appears early.
• Separate mobile sites. Sites that still serve a separate m-dot version have their own URLs and their own field data. Fix each version, or move to a single responsive site.
• AMP pages. Where AMP versions still exist, visitors from some sources may land on them. Their performance is measured under the AMP URL, not your main page.
• Low traffic on mobile. If mobile has no URL-level field data, Search Console may use grouped or origin-level figures. Use your own real-user data for individual pages.

Keeping mobile passing

• Test on a phone before every release of a new template, section or third-party tool, with CPU throttling if you cannot use real hardware.
• Design mobile first. Decide what the mobile visitor sees in the first screen and make that light, then add desktop extras.
• Keep a per-breakpoint image policy so editors cannot upload a single enormous image that every device downloads.
• Track mobile results separately in your own reporting, split by viewport width.

For the individual metrics, see slow LCP, poor INP and layout shift. Sizing and format questions are covered in the image optimisation fixes.