To improve Core Web Vitals on mobile, first identify which part of the experience is slow. Downloading the main image, responding to a tap, and shifting the layout are different problems. Treating them all as “the website needs to be faster” makes it easy to change things that do not affect the bottleneck.
A fast desktop result is encouraging, but a simulated mobile test applies different constraints. Conversely, a single disappointing lab run is not proof that every real visitor has the same experience. Use repeatable tests and keep the conditions visible.
Understand the three metrics
Google's Web Vitals guidance identifies Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. The good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile of visits.
Those are experience metrics, not a promise that a particular Lighthouse score will produce rankings. Lighthouse's Total Blocking Time is a laboratory diagnostic; it is not the same measurement as field INP. Keep the labels distinct when discussing results with a developer.
Separate field evidence from a lab simulation
PageSpeed Insights can show real-user data when enough eligible data is available, alongside a controlled Lighthouse test. Check whether the field section refers to the individual URL or the wider origin. “No data” means insufficient available field evidence, not that the page is fast or broken.
For comparisons, keep the URL, device mode, throttling, and tested release consistent. Run more than once and look for a pattern. Browser extensions can add work in local tests, so use a clean setup. Record dates and screenshots instead of reporting the best result from unrelated conditions.
For slow LCP, identify the actual element
The largest visible element might be a photograph, a headline, or another content block. Expand the LCP breakdown before assuming the hero image is responsible. The web.dev LCP optimization guide separates server response, resource discovery, resource loading, and rendering delay.
If discovery is late, make the resource available in the initial page and prioritize only the genuine critical resource. If the download is large, resize and compress it. If it is already downloaded but waits to appear, investigate blocking styles, scripts, or an animation that hides it. Compressing an image cannot fix every kind of delay.
Reduce work without weakening the site
Check whether the homepage loads styles intended only for account screens or article templates. Examine font requests and avoid preloading every available weight. A short list of genuinely critical assets is more useful than flooding the browser with priority hints.
For images, compare the selected resource with its displayed size and intended sharpness. Responsive sources should reflect real layout widths, including mobile gutters. Lazy-load below-the-fold media, but do not lazily hide the likely LCP image. Keep useful analytics unless measurements show a problem; removing measurement makes future decisions harder.
Investigate interaction and stability separately
If taps feel slow, inspect long tasks and expensive event handlers. A repeated layout calculation during scrolling needs a different fix from an overly large JavaScript bundle. Avoid interpreting every millisecond of “other” browser work as application code without a trace.
For layout shifts, reserve space for images, embeds, and delayed interface elements. Test font changes, validation messages, and banners as well as the initial screen. A stable first screenshot does not establish that the page stays stable during an enquiry or menu interaction.
A useful performance handoff
- Exact URL, device, and reproduction steps.
- Field data availability and lab-test conditions.
- The affected metric and identified element or interaction.
- One proposed change and its expected mechanism.
- Before-and-after tests plus visual and functional checks.
Common questions
Should I chase a score of 100?
Not at the cost of essential functionality or trustworthy measurement. Prioritize a reliably usable experience and meaningful bottlenecks over small fluctuations.
Can desktop performance prove the mobile experience?
No. Mobile layouts, network conditions, and processing constraints can expose different issues. Review both and include real devices when practical.
Combine this process with a technical SEO review and responsive design checks. For implementation help, share the report and affected page, not just the overall score.