Core Web Vitals: Diagnose and Fix Each Metric

Core Web Vitals scores often arrive as a red warning in Search Console or a low number in a speed test, with little explanation of what to do next. Teams then try generic fixes, such as compressing every image or installing a caching plugin, and see little change because the real cause was elsewhere. Core Web Vitals are three measurements of real user experience: how quickly the main content appears, how quickly the page responds to interaction, and how stable the layout is while loading. Each one breaks down into parts that point to specific causes. This guide explains the metrics and thresholds, where to get trustworthy data, and how to diagnose and fix each metric methodically.

What Core Web Vitals measure

Google's Web Vitals guidance defines three Core Web Vitals and the thresholds for a good experience:

• Largest Contentful Paint (LCP): loading. The largest content element should appear within 2.5 seconds of the page starting to load.
• Interaction to Next Paint (INP): responsiveness. Pages should have an INP of 200 milliseconds or less.
• Cumulative Layout Shift (CLS): visual stability. Pages should maintain a CLS of 0.1 or less.

The guidance recommends assessing them at the 75th percentile of page loads, split by mobile and desktop, and considers a page as passing when it meets all three at that percentile. INP is the successor to First Input Delay, which only measured the delay before the first interaction; INP considers responsiveness across the page's lifetime.

Get field data before lab data

There are two kinds of measurement. Field data comes from real visitors on their own devices and networks. Lab data comes from a test run in controlled conditions. Both are useful, for different jobs.

Google Search Console's Core Web Vitals report shows how pages perform based on real-world usage data from the Chrome User Experience Report, and groups similar URLs together. Start there, or with your own real-user monitoring, to find which templates and which metric are failing. Then use lab tools to reproduce and diagnose the problem, and return to field data to confirm the fix. A perfect lab score on a fast connection does not mean real visitors on mid-range phones have a good experience.

Diagnose LCP by its parts

Google's guide to optimising LCP breaks the metric into four subparts:

• Time to First Byte: how long until the browser receives the first byte of HTML
• Resource load delay: the gap between that and when the browser starts loading the LCP resource, such as a hero image
• Resource load duration: how long that resource takes to load
• Element render delay: the time from the resource finishing to the element appearing

Each points to different fixes. A slow first byte suggests server, hosting or caching work. A long load delay means the browser discovers the hero image late, for example because it is lazy-loaded or added by JavaScript. A long load duration suggests the image is too large. A long render delay often means render-blocking styles or scripts.

Diagnose INP by interaction

Google's guide to optimising INP divides an interaction into input delay, processing duration and presentation delay. In practice, most poor INP comes from too much JavaScript on the main thread: large bundles, heavy event handlers, and third-party scripts competing for time. Find the slowest interactions in field data first, such as opening a menu or adding to a cart, then reproduce them in the lab and look for long tasks.

Typical fixes include breaking long tasks into smaller pieces, loading non-essential scripts later, reducing work in event handlers and rendering less on each interaction.

Diagnose CLS by what moves

Google's guide to optimising CLS lists the most common causes: images without dimensions; ads, embeds and iframes without dimensions; dynamically injected content; and web fonts. The fixes follow directly. Set width and height or an aspect ratio on images and embeds, reserve space for content added after load, such as banners, and choose font loading settings that minimise swapping. Google's CLS article explains that shifts within 500 milliseconds of user input can be excluded from the calculation, so focus on content that moves without the user doing anything.

Worked example: a Core Web Vitals diagnosis by template

The table below shows a hypothetical diagnosis for a company site whose Search Console report flags mobile pages. Findings and fixes are illustrative.

TemplateFailing metricDiagnosisFixHome pageLCPHero image lazy-loaded, so resource load delay is longLoad hero eagerly with high priority; serve correctly sized imageBlog postLCPSlow Time to First Byte; pages rendered on every requestCache pages at the edge or generate them staticallyService pageCLSCookie banner inserted above content after loadShow banner as an overlay or reserve its spaceContact pageINPMap embed and chat widget load early and block the main threadLoad both on interaction or when idleProduct listingINPFilter clicks re-render the whole listRender only changed items; debounce filter input

Each fix is checked in the lab first, then confirmed in field data over the following weeks, because the Search Console report reflects real visits over the last 28 days.

Prioritise by impact

Fix templates with the most traffic and the worst results first. A single template, such as blog posts, may account for most URLs in the report, so one fix can move many pages at once. Our guide to Next.js performance shows how framework features address these metrics for sites built with Next.js, and our guide to mobile-first web design covers design choices that keep mobile pages light from the start.

Prevent regressions

Core Web Vitals often degrade after launch as scripts, images and features are added. Add a performance check for key templates to your deployment process, review new third-party scripts before adding them, and look at field data each month. Catching a regression in one release is much easier than untangling months of small additions.

Common mistakes with Core Web Vitals

• Chasing a lab score instead of field data at the 75th percentile
• Applying generic fixes without identifying the failing subpart
• Lazy-loading the hero image
• Loading every third-party script early
• Inserting banners above content after load
• Declaring victory after one good test run

Frequently Asked Questions

What are Core Web Vitals?

Three metrics of real user experience defined by Google: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability.

What are the good thresholds?

According to Google's guidance, LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, assessed at the 75th percentile of page loads.

Why does my lab score differ from Search Console?

Search Console uses field data from real users on varied devices and networks, while lab tools run one test in controlled conditions. Use field data to judge and lab data to diagnose.

What replaced First Input Delay?

Interaction to Next Paint. Google describes INP as the successor to FID, measuring responsiveness across the whole page lifetime rather than only the first interaction.

Fix the metrics that matter

We diagnose Core Web Vitals with field data and fix the underlying causes template by template. See our custom app development services, or talk to us about your site's performance.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.