What the three metrics actually measure
Largest Contentful Paint is the moment the main content becomes visible; good is under 2.5 seconds at the 75th percentile of real visits. Interaction to Next Paint replaced First Input Delay in 2024 and measures how quickly the page responds to taps and clicks across the whole session; good is under 200 milliseconds. Cumulative Layout Shift measures how much the page moves under the reader's finger; good is under 0.1. The official definitions and thresholds live in Google's Web Vitals documentation.
The three fail for different reasons, which matters when scoping the work. LCP is usually a server, image or render-blocking resource problem. INP is almost always JavaScript: too much of it, running at the wrong moment, on a mid-range phone rather than the developer's laptop. CLS is layout: images without dimensions, fonts swapping, banners injected above content. A programme that treats them as one ticket usually fixes the easy one and reports success.
Field data is the only data that counts here. Lab tools simulate a device and a connection; the Chrome User Experience Report measures what your actual visitors experienced, and the two routinely disagree by a factor of two. Start from the Core Web Vitals report in Search Console, drill into the worst template, and only then open a lab tool to diagnose the cause.
Ranking signal or conversion lever?
Core Web Vitals are a confirmed ranking signal and a weak one. Google has been explicit that page experience breaks ties between results of comparable relevance rather than promoting a fast page over a more useful slow one. Any agency selling a performance sprint as a ranking strategy is overselling; any agency ignoring a poor-rated site is underselling, because the conversion effect is real and much larger.
The conversion elasticity used here — between 0.4 and 1.0 % of relative conversion movement per 100 ms of LCP — comes from repeated public measurements: Deloitte's retail study, Vodafone's LCP experiment, and the case studies collected on web.dev. The spread is wide because the effect depends on device mix, journey length and how impatient the intent is. The simulator exposes it as a choice rather than burying a single constant in the code.
The return is not linear across the range, which is the practical planning point. Moving a site from 5 seconds to 3 changes user behaviour visibly; moving from 2.2 to 1.9 rarely does, and often costs more engineering. Prioritise templates that are currently rated poor, on mobile, on the highest-traffic journeys — and check the result in field data a month later, not in a lab score on the day of the deploy.
- Always start from field data at the 75th percentile
- Diagnose LCP, INP and CLS as three separate problems
- Prioritise poor-rated mobile templates on high-traffic journeys
- Expect diminishing returns below about 2 seconds LCP
- Verify improvements in field data after 28 days, not in a lab run
- Treat ranking gain as a bonus; conversion is the business case