How to Optimize Core Web Vitals for Mobile Performance

This guide is for site owners, developers and SEOs whose mobile Core Web Vitals report is red or amber while desktop looks fine. I will show you how to find which metric and which template is failing on phones, the fixes that move each metric in the order I apply them on audits, and a checklist you can work through. It uses the current metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). If you still see First Input Delay in a report, read why FID was replaced by INP first.

Why mobile Core Web Vitals fail when desktop passes

Google ranks with your mobile pages. Its mobile-first indexing documentation states that Google “uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” The Core Web Vitals report in Search Console also splits mobile and desktop, and the mobile side is usually worse for three reasons:

• Slower processors. The same JavaScript that runs in 50 ms on a laptop can take several times longer on a budget Android phone. This is what hurts INP.
• Slower, less stable networks. Higher latency on mobile data makes server response time and every extra request more expensive. This is what hurts LCP.
• Different layouts. Mobile templates add sticky headers, cookie and app banners, and ads that slot in above content, which is where CLS problems come from.

The 2024 Web Almanac shows the gap clearly: 43% of mobile sites had good Core Web Vitals against 54% of desktop sites, and LCP was the biggest mobile weakness at 59% good. In Pakistan and other markets where most traffic comes from mid-range Android phones on 4G, the gap on the sites I audit is often wider than those global averages suggest.

The mobile thresholds you are aiming for

Google assesses each metric at the 75th percentile of real page loads, split by device. A page group passes only when all three are good.

For a deeper explanation of each metric, see my Core Web Vitals guide.

Step 1: Measure mobile performance properly

Most wasted effort I see comes from chasing a Lighthouse score instead of the field data Google actually uses. Work in this order:

1. Search Console, Core Web Vitals, Mobile. This groups similar URLs, so it tells you which template is failing (product pages, blog posts, category pages), not just which URL. Fixing the template fixes the group.
2. PageSpeed Insights, mobile tab. The top section is field data from the Chrome UX Report over 28 days. The lower Lighthouse section is a lab simulation; use it for diagnosis, not as the score that matters. My free PageSpeed and Core Web Vitals checker shows both for a quick check.
3. Chrome DevTools on a throttled profile. Set CPU throttling to 4x or 6x and a mobile network profile, then record a Performance trace while loading the page and tapping the menu, filters and forms.
4. A real mid-range phone. Connect an Android phone with USB debugging and inspect it from desktop Chrome. Nothing replaces seeing your own site stutter on the device your customers use.

Step 2: Fix LCP on mobile

Google’s LCP optimisation guide splits LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. It suggests most of the time should go on loading the HTML and the LCP resource itself, with load delay and render delay each under about 10%. That breakdown tells you where to look.

Reduce server response time

• Use full-page caching so the HTML is served without running PHP and database queries on every visit.
• Put a CDN in front of the site, especially when your audience is far from your server. A Pakistani audience served from a US-only host pays for that distance on every request. My guide to hosting, caching and CDNs covers the options.
• Remove redirect chains on landing URLs; each hop costs a round trip on mobile data.

Load the LCP image early

• Never lazy-load the hero image. Google is explicit that lazy-loading the LCP image always causes unnecessary delay. The Web Almanac still found 16% of mobile pages with an image LCP lazy-loading it in 2024.
• Add fetchpriority="high" to the hero <img>, and to no more than one or two images.
• Use a real <img> tag rather than a CSS background image, so the browser finds it in the HTML.
• Serve mobile-sized images with srcset and sizes, in WebP or AVIF. My free image compressor and WebP converter handles quick one-off files; see also optimising blog images.

Remove render-blocking work

• Inline the small amount of CSS needed for the first screen and load the rest without blocking.
• Defer scripts that are not needed to show the first screen.
• Avoid hero sliders on mobile: they usually load several large images and JavaScript to show one.

Step 3: Fix INP on mobile

INP is where low-powered phones expose JavaScript-heavy sites. When I audit, the slow interaction is usually the menu button, a filter, an add-to-basket button or a form field, and the cause is usually a script that has nothing to do with that button.

• Audit third-party scripts. List every tag in Tag Manager and every widget. Remove the ones nobody uses; load chat and heatmap tools only after the visitor interacts or after a delay.
• Break up long tasks. Split heavy work into smaller chunks and yield to the main thread between them, so a tap can be handled in the gap.
• Ship less JavaScript to phones. Remove unused code, split bundles by page, and do not load desktop-only features (mega menus, hover effects) on mobile.
• Show the result first. In click handlers, update the screen before sending analytics or saving data.
• Keep the DOM small. Huge page-builder layouts make every re-render slower on a phone.

My INP guide walks through finding the exact slow interaction in DevTools.

Step 4: Fix CLS on mobile

• Give every image, video and iframe width and height attributes, or a CSS aspect-ratio, so space is reserved before it loads.
• Reserve fixed-height slots for ads and embeds, including when no ad fills the slot.
• Show cookie and app banners as overlays at the bottom of the screen, not inserted above content after load.
• Preload the main web font and use a fallback font with similar metrics so text does not jump when the font arrives.
• Do not inject “related posts”, reviews or promo bars above content that is already visible.

The full list of causes is in my guide on how to fix Cumulative Layout Shift.

Which fix to do first

Effort and impact vary by site, so this is the order I usually work in rather than a promise of results:

Mistakes I see on mobile performance projects

• Optimising for the Lighthouse score. A 95 in the lab with poor field data is still poor in Google’s eyes.
• Testing only on a fast phone. An iPhone on office Wi-Fi hides most INP problems.
• Stacking speed plugins. Two caching or optimisation plugins on WordPress often conflict and break layouts, which creates CLS.
• Lazy-loading everything. Applying lazy-loading to all images, including the first one, slows LCP.
• Treating speed as a one-off project. A new tag, plugin or slider can undo months of work. Set a simple budget and recheck after each release.
• Expecting rankings to jump. Core Web Vitals are one of many page experience signals; Google says relevance comes first. The more reliable payoff is fewer abandoned visits, as the speed and conversion data above suggests.

Mobile performance sits inside the wider topic of mobile SEO, and it is one part of a holistic SEO approach rather than a replacement for good content. If you want background on how Google moved to mobile, see my note on the mobile-first indexing update.

Frequently asked questions

Sources

• HTTP Archive, “Web Almanac 2024: Performance” (2024).
• web.dev (Google Chrome team), “Optimize Largest Contentful Paint” (accessed 2026).
• Google Search Central, “Mobile-first indexing best practices” (accessed 2026).
• web.dev, “Milliseconds make millions” case study of Deloitte research (2020, data from late 2019).

If your mobile report is still red after the cheap wins, my website speed optimisation service traces each failing template to its cause, or you can send me your URL and ask a question.