LCP, INP, CLS: what each metric measures
Three metrics, three distinct dimensions of perceived experience. LCP measures loading speed, INP measures responsiveness, CLS measures visual stability. None replaces the others: a page can display fast yet remain unplayable, or respond instantly while dancing before your eyes. The audit handles all three separately.
LCP — Largest Contentful Paint
LCP measures the time elapsed until the largest visible element in the viewport is displayed: typically a hero image, a video or a large block of text. Passing threshold: under 2.5 seconds. Beyond 4 seconds, the page is judged slow. LCP is dominated by four factors: server response time (TTFB), render-blocking resources (synchronous CSS and JS), the load time of the resource itself, and the delay before the browser discovers it.
INP — Interaction to Next Paint
INP replaced FID in March 2024. It measures the latency between a user interaction (click, tap, keystroke) and the next visual render that results from it. Unlike FID, which only judged the first interaction, INP observes every interaction in the session and keeps the worst. Threshold: under 200 milliseconds. A degraded INP almost always reveals a main thread saturated by JavaScript that runs too long.
CLS — Cumulative Layout Shift
CLS quantifies unexpected visual shifts: a button that jumps because a banner loads late, an image without dimensions that pushes the text down. Threshold: under 0.1. It is a unitless score, calculated as the fraction of the screen that moved multiplied by the distance of the shift.
Lab data vs field data
A credible Core Web Vitals audit rests on two complementary sources that are too often confused. Lab data diagnoses, field data validates.
Lab data comes from a simulated visit under standardized conditions: a defined machine, a throttled network, no cache. Lighthouse is its reference source. Its strength is reproducibility and debugging: you isolate a cause, you fix it, you re-measure immediately. Its limit: it does not reflect your real audience, its devices, its connections.
Field data comes from the Chrome User Experience Report (CrUX) or your own RUM (Real User Monitoring). It aggregates real visits over a rolling 28 days. This is the data Google uses to judge a URL, and it is what appears in Search Console.
| Criterion | Lab data | Field data |
|---|---|---|
| Source | Lighthouse, simulation | CrUX, RUM, Search Console |
| Conditions | Standardized, reproducible | Real devices and networks |
| INP measurable | No (no real interactions) | Yes |
| Usage | Diagnose and debug | Validate the real impact |
| Google verdict | None | Determines compliance |
Practical consequence: never judge INP on a lab score. Lighthouse clicks on nothing. INP only exists in the field. An audit that announces a 'perfect' INP from Lighthouse is using the wrong tool.
The tools to run the audit
Five tools are enough, each for a specific use. The trap is to use only one and believe the audit is complete.
The starting point. It groups your URLs by status (good, needs improvement, poor) from field data. It reveals the true scale of the problem across the whole site, not on an isolated page.
The only tool that displays lab AND field data side by side for a URL. Ideal for confirming that a lab problem holds true for real users.
For deep diagnosis. It lists quantified opportunities: blocking resources, oversized images, unused JS. This is where you find the root causes.
For INP and the main thread. You record a real interaction and you see exactly which JS task blocks the render.
To measure continuously on your own journeys, in real conditions, without waiting for CrUX aggregation.
The method: Search Console to frame the scope, PageSpeed Insights to prioritize template pages, Lighthouse and the Performance panel to dissect each metric. Do not drown in the detail of a single URL before you have the big picture. This frame-before-detail logic is the same as that of a complete SEO audit.
Fixing each metric, by root cause
An effective fix targets the dominant cause, not every symptom. Each metric has its own levers. You fix, you re-measure, you move to the next bottleneck.
Fixing LCP
Start with TTFB: a slow server or a missing cache drags down everything else. Enable the cache, bring the data closer with a CDN, lighten the server-side rendering. Then prioritize the LCP resource: fetchpriority="high" on the hero image, preloading (preload) the font and the critical image, removing lazy-loading on the above-the-fold element. Finally, eliminate render-blocking resources: inline critical CSS, non-essential JS as defer.
Fixing INP
INP is won on the main thread. Break long JavaScript tasks into shorter chunks, defer everything not needed for the immediate interaction, and offload heavy computations to a Web Worker. Beware of third-party scripts (analytics tags, chat, A/B testing): they are often the prime culprit behind a degraded INP.
Fixing CLS
CLS is almost always solved by reserving space. Systematically declare width and height (or aspect-ratio) on images and videos. Reserve room for banners and ads before they load. Load fonts with font-display: optional or preload them to avoid text shift (FOIT/FOUT).
LCP is by far the metric most often failing on French sites. The number one culprit remains TTFB, followed by unoptimized hero images and blocking JavaScript. Fixing the server before the images almost always delivers the best return.
One structural detail weighs on the whole: pages rendered only client-side. LLMs do not execute JavaScript, which makes SSR or static HTML indispensable for AI visibility — and the same server rendering mechanically improves LCP by delivering the content without waiting for hydration. A single architecture decision serves two objectives.
To structure this approach end to end, our 2026 SEO audit checklist includes a directly actionable performance section.
Real SEO impact and priority trade-offs
Core Web Vitals are a ranking factor, but a minor one. Let us be precise to avoid both over-investment and neglect. They belong to the page experience signal, which decides between results of comparable relevance. They will never make up for weak content, and a site already in the green zone will not gain positions by going from 2.4 to 1.8 seconds of LCP.
Rational trade-off follows three rules. First, getting out of the red zone is a priority; going from light green to dark green is not. Second, treat the templates, not isolated URLs: fixing a category template repairs thousands of pages at once. Third, the business impact often exceeds the direct SEO impact — a faster page converts better, and the bounce rate drops.
This balance is part of the continuous technical optimization work we carry out for our clients as an SEO agency: cross the thresholds, secure the field, then invest where the growth lever is real. To apply this rigor to your own audit, the GEO Audit Templates Pack provides ready-to-use measurement and prioritization grids.
Request your free GEO audit: technical performance, AI citability and priorities ranked by real gain.
Questions fréquentes
Are Core Web Vitals a Google ranking factor?+
Yes, but a minor one. They are part of the page experience signal, which decides between results of comparable relevance. A slow page with superior content can outrank a fast page with weak content. Core Web Vitals act as a tie-breaker, not as a relevance lever.
What is the difference between the Lighthouse score and Search Console data?+
Lighthouse measures a simulated visit in a lab, on a standardized machine and network. Search Console displays field data (CrUX), aggregated over the real visits of the last 28 days, at the 75th percentile. It is this field data that determines whether a URL is deemed compliant by Google.
Has INP replaced FID?+
Yes. Since March 2024, INP (Interaction to Next Paint) has replaced FID as the responsiveness metric. INP is more demanding: it measures the latency of all interactions on a page, not just the first, and keeps the worst. Many sites that passed FID fail INP.
How long before you see the effect of a Core Web Vitals fix?+
Lab tools show the effect immediately. Search Console field data, however, is calculated over a rolling 28-day window. So you have to wait about four weeks after deployment to see a URL's status flip to the green zone.
