Core Web Vitals Explained for People Who Ship Pages
What the three metrics measure, the thresholds that matter, and which fixes give the best return for the least effort.
Core Web Vitals are three measurements chosen because they correlate with what people actually notice: does something appear quickly, does the page respond when I touch it, and does it stop moving while I am trying to read it. They replaced a longer list of metrics over time precisely because a small set that predicts experience is more useful than a large set that does not.
The three
| Metric | Measures | Good | Needs work | The usual cause |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | When the largest visible element finishes rendering | 2.5s or less | Over 4s | A slow server response, a large hero image, or a render-blocking stylesheet |
| INP — Interaction to Next Paint | How long the page takes to respond visually to a tap, click or keypress | 200ms or less | Over 500ms | Long JavaScript tasks, heavy event handlers, or too much work on the main thread |
| CLS — Cumulative Layout Shift | How much visible content moves unexpectedly after it appears | 0.1 or less | Over 0.25 | Images and ads without reserved space, late web fonts, or content injected above what is already on screen |
Thresholds are evaluated at the 75th percentile of real page loads, segmented by device type. In plain terms: three quarters of visits must be faster than the threshold, not the average visit. A very fast median with a slow tail fails, which is why the long tail of old devices and poor connections is the thing to optimise.
LCP in practice
Largest Contentful Paint is the single largest visible element — usually an image, a heading block or a large text area. The common causes, in the order worth attacking them:
-
Server response time
Everything else is downstream of this. A static build or a CDN in front of the origin removes the whole class of problem.
-
A render-blocking stylesheet
Nothing paints until the CSSOM is complete. Inline the above-the-fold rules and load the rest asynchronously.
-
The hero image itself
Serve an appropriately sized image, in a modern format, at the display size rather than the design size, with width and height set so it can be reserved.
-
A late web font
font-display: swap shows fallback text immediately, or preload the single file used above the fold.
-
Too many connections to set up
Preconnect to origins you know you will need, and consolidate assets onto fewer origins so fewer handshakes are on the critical path.
INP in practice
INP replaced First Input Delay in 2024 and measures the full round trip from an interaction to the next paint, which is much stricter. Almost always the cause is a long task: JavaScript occupying the main thread for more than about 50 milliseconds, during which nothing can respond to anything.
- Ship less JavaScript. The most effective intervention, and the only one with no trade-off. Every library on the page is a candidate for removal.
- Split by route. Load the code for the page you are on, not for every page you might visit.
- Defer what is not needed for the interaction. Analytics and chat widgets are the usual offenders and rarely need to block anything.
- Break up long tasks. Yield to the main thread between chunks of work, or move it to a worker.
- Make handlers cheap. If a click handler does real work, do it after the visual response has been painted.
CLS in practice
Layout shift is a symptom of content arriving after the space for it was already claimed. The fix is almost always to reserve the space in advance, and it is the cheapest of the three to solve.
- Set
widthandheighton every image so the browser can reserve the box before the file arrives. - Reserve space for ads, embeds and anything injected by a third party, including the empty state before it fills.
- Avoid inserting content above what the reader is already looking at, and avoid banners near the top of the viewport that push everything down on load.
- Handle font loading so text does not reflow: a fallback with similar metrics, plus size-adjust, or a swap strategy that does not change line counts dramatically.
Field data versus lab data
| Source | Lab data | Field data |
|---|---|---|
| What it is | A measurement you run yourself on a controlled device | Measurements collected from real visits |
| What it answers | Can I make this change and improve the score? | Are real users having a good experience? |
| Weakness | Never represents your actual audience | Slow to accumulate, and slow to reflect a fix |
| Use it for | Diagnosing and comparing | Deciding whether a fix actually mattered |
A sensible order of work
-
Measure with real users if at all possible
Analytics, or a lightweight field library. Without it you are guessing about the long tail.
-
Fix the server response time
Static output, a CDN, or caching. It improves everything else and it is rarely the hard part.
-
Fix the hero image and the render-blocking CSS
Large, cheap wins, and they address LCP directly.
-
Reserve space for everything that loads late
Fixes most CLS on a typical page.
-
Cut JavaScript and defer the rest
Addresses INP, and improves LCP as a side effect.
-
Then re-measure and stop
Diminishing returns are real, and further tuning costs complexity that will need maintaining.
Common questions
Frequently asked questions
Do these metrics affect search rankings?
They are not a direct ranking factor, and any claim of a specific position jump is not supported. They matter because page experience is used as a tiebreaker among otherwise comparable pages, and because a technically good page is usually a better one anyway. The honest framing is that they are worth doing because users benefit, not as a ranking tactic.
Is a perfect score achievable on a content site?
For a plain HTML page with one stylesheet and a small amount of JavaScript, comfortably yes, and this site is built that way. The metrics become hard when the page has a video player, a live chat widget, several analytics scripts and a third-party ad. Choosing not to include those is often the most effective optimisation available.
What is the 75th percentile and why does it matter?
It is the value below which 75 percent of observations fall. Using it means your score is decided by your slower visitors rather than your faster ones, which is a deliberate choice: the fourth slowest experience is still an experience somebody had, and it is usually somebody on an older phone over a poor connection.
How do I test without a real user base?
Lab measurements under mobile emulation with a slowed connection, run several times and compared on the median. It will not tell you how real users behave, but it is entirely adequate for answering "did this change make this specific thing faster?", which is the question you are usually asking.
Where to go next
These are the services referenced above. Compare them on your own terms before you sign up for anything.