Core Web Vitals are three metrics with which Google measures the feel of a page's loading and responsiveness. They honestly assess important parts of the experience, but a good score on its own does not make the content relevant. That same technical book card in a multilingual store may score perfectly in the lab and still answer none of the shopper's query. What needs optimizing is the real interaction, not just the test number.
Let us take apart what each metric measures. LCP (Largest Contentful Paint) records the moment the main above-the-fold content becomes visible - for the card that is usually the book cover and the title; a good threshold is 2.5 seconds. INP (Interaction to Next Paint) shows how fast the interface visually responds to user actions - a click on the buy button, expanding the description; a good threshold is 200 milliseconds. CLS (Cumulative Layout Shift) measures how unexpectedly the layout moves while the page is still loading; a good threshold is 0.1. The thresholds are taken not at the average but at the 75th percentile of real loads: a page counts as fast only if three quarters of users see it that way, not a lucky minority on a fast connection.
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP | when the main above-the-fold element is visible | 2.5 s |
| INP | how fast the interface responds to an action | 200 ms |
| CLS | how unexpectedly the layout shifts | 0.1 |
How this ties to search. Page experience, which includes Core Web Vitals, is a ranking signal but a weak one: it does not override relevance. Between two equally useful pages the engine will prefer the faster one, but a slow page with the exact answer will beat a fast empty shell. Hence the naive mistake - chasing the number 100 in the report instead of improving what a person actually feels. Page experience does not end there: the same group of signals includes HTTPS and the absence of intrusive interstitial banners that cover the content.
To avoid optimizing blindly, two kinds of data are kept apart. Field data is measurements from real users, collected in CrUX and your own RUM system; it is exactly what reflects the experience and counts in ranking. Lab data is a synthetic run in Lighthouse on fixed hardware; it is there to reproduce and diagnose the problem. The field says what hurts, the lab says why. An important subtlety: INP is by definition measured on live clicks, so a pure lab cannot really see it - it shows potentially long tasks, but only the field gives the real number. Segmenting the field is mandatory: by page template, device, country, and connection type - an average hides the fact that the book card is slow only on a budget Android in one country.
A separate lever is how the page renders. If the cover, price, and title arrive already in the server HTML, they are visible at once and LCP comes early. If the same content is painted by JavaScript after a request to an API, the browser first shows an empty shell and the crawler waits for the render - and both LCP and indexing are delayed. The same choice between server and client that decides the fate of indexing also determines the speed.
The failure looks mundane. In the lab the card scores 100, but in the field INP runs past half a second: a heavy script blocks the thread on the first click on buy. And a late-loaded price banner shoves the button down at the instant of the tap - a high CLS, and the shopper misses. A lab score would have shown neither; you can see it only in the segmented field. Performance is worth paying for where it obstructs a real action, not for the sake of a pretty number.