Core Web Vitals for Developers: What Actually Moves the Numbers
Core Web Vitals are three field measurements of how a page feels: how long until the main content appears, how much it moves while loading, and how quickly it responds to input. They are a ranking signal, and more importantly they correlate with whether people stay.
This guide covers what each metric measures, the specific causes behind poor scores, and the fixes that move field data rather than only lab scores.
What the three metrics measure#
Each has a threshold for "good" and each has a small number of usual causes. Note that the number that counts for ranking is field data from real visitors, not a lab score from your laptop.
| Metric | Good | Measures | Usual cause when poor |
|---|---|---|---|
| LCP | Under 2.5s | Time until the largest visible element renders | Unoptimised hero image, slow server, render-blocking CSS |
| CLS | Under 0.1 | How much layout moves during load | Images without dimensions, injected banners, late web fonts |
| INP | Under 200ms | Responsiveness to user interaction | Long JavaScript tasks blocking the main thread |
Lab tools measure one load on one machine. Field data is the 75th percentile of real visits, which includes old phones on poor networks — the visitors most likely to leave.
Fixing LCP#
LCP is almost always an image or a heading blocked behind something else. Work through these in order; the first two fix most sites.
- Identify the actual LCP element in field data. Optimising the wrong image is the most common wasted effort.
- Never lazy-load the LCP image. Give it fetchpriority="high" instead.
- Serve it in a modern format at the size it is displayed, with srcset for smaller screens.
- Preload the font used by the LCP text and use font-display: swap so text is not invisible while waiting.
- Remove render-blocking CSS and JavaScript from the head; inline the critical CSS if the page is small enough.
- Reduce Time to First Byte with caching and a CDN — no front-end work can compensate for a slow server.
- Cut third-party scripts in the critical path. Each one is a DNS lookup, a connection and an unpredictable file.
Fixing CLS#
Layout shift is almost entirely preventable and the fixes are cheap. It is also the metric visitors notice most viscerally — it is what makes people tap the wrong thing.
- Set width and height attributes on every image and video so the browser reserves space.
- Reserve space for ads, embeds and iframes with a fixed aspect ratio container.
- Never insert content above existing content after load — cookie banners belong at the bottom, or overlaid.
- Match the fallback font metrics to the web font, or use size-adjust, so the swap does not reflow the page.
- Avoid animating layout properties. Animate transform and opacity, which do not trigger reflow.
- Give dynamically loaded sections a min-height so they do not expand from zero.
Fixing INP#
INP replaced First Input Delay and is harder, because it measures every interaction across the visit rather than only the first. Poor INP is nearly always too much JavaScript running on the main thread.
| Cause | Fix |
|---|---|
| Large bundle parsed on load | Code-split; load only what the page needs |
| Long tasks over 50ms | Break work into chunks and yield to the main thread |
| Expensive event handlers | Debounce, and move heavy work off the interaction path |
| Heavy third-party tags | Load after interaction, or remove — audit what each one earns |
| Large DOM (10,000+ nodes) | Virtualise long lists; simplify deeply nested markup |
| Layout thrashing in handlers | Batch reads and writes instead of interleaving them |
On content sites the highest-value INP fix is usually deleting JavaScript rather than optimising it. Ask what each script earns; tag managers accumulate scripts nobody remembers adding.
Frequently asked questions
How much do Core Web Vitals affect rankings?
They are a real but modest signal, and they act as a tiebreaker rather than as a substitute for relevance. A fast page about the wrong thing does not outrank a slower page that answers the query. The stronger argument for fixing them is behavioural: slow, shifting pages lose visitors before ranking enters into it.
Why is my Lighthouse score good but my field data bad?
Because Lighthouse simulates one load on your machine with your connection, and field data is the 75th percentile of real visits — including three-year-old phones on congested mobile networks. When the two disagree, the field data is the one that counts. Use lab tools to diagnose, not to score.
Do I need to fix all three metrics?
Fix the ones that are failing, in the order of what your visitors experience. CLS is usually the cheapest to fix and the most annoying to users, so it is a good place to start. LCP has the biggest effect on whether people wait. INP matters most on interactive sites and least on static articles.
How long before improvements show up?
Field data is a 28-day rolling window, so meaningful movement takes about four weeks after a fix is deployed to all visitors. Do not judge a change after three days. Do check lab metrics immediately to confirm the fix actually did what you expected.
core web vitalslcpclsinppage speedweb performance
