Key takeaways
- Core Web Vitals are three metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability).
- Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital on 12 March 2024, and it measures every interaction on the page, not just the first.
- The good thresholds are LCP under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of real visits.
- Page experience is closer to a tiebreaker than a top ranking factor. Google says it will still show the most relevant content even when page experience is sub-par.
- Fix the worst real-user experience first using field data, rather than chasing a perfect lab score.
Core Web Vitals get discussed as if a perfect score were the goal. It is not. They are a small set of metrics Google uses to describe how a page feels to a real person, and they matter most as a way to find and fix the pages that genuinely frustrate visitors. This guide covers the three metrics, how much they actually affect rankings, how to measure them properly with real-user data, and the practical fixes that move the numbers.
The three metrics (including INP)
Core Web Vitals are the subset of Google’s Web Vitals program that applies to every page and is surfaced across every Google tool. According to Google’s web.dev documentation, the current set covers three aspects of the experience: loading, interactivity, and visual stability.
- Largest Contentful Paint (LCP) measures loading. It marks the moment the largest piece of content in the viewport, usually a hero image or a block of text, finishes rendering. A good LCP is under 2.5 seconds.
- Interaction to Next Paint (INP) measures responsiveness. It observes the latency of clicks, taps, and key presses across the whole page lifecycle and reports one figure that reflects overall responsiveness. A good INP is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability. It quantifies how much visible content jumps around as the page loads, the kind of shift that makes you tap the wrong button. A good CLS is 0.1 or less.
The change most people still get wrong is the responsiveness metric. On 12 March 2024, INP replaced First Input Delay (FID) as a Core Web Vital, as Google announced on the web.dev blog. The reason is straightforward: FID only measured the delay before the first interaction on a page, so a fast first click could mask slow behaviour everywhere else. INP instead considers the full set of interactions and captures the whole latency, including the time your event handlers run and the time to paint the result.
Common mistake. If you are still optimising for FID, you are optimising for a metric that no longer exists.
| Metric | What it measures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
Good thresholds per Google’s web.dev Web Vitals documentation, assessed at the 75th percentile.
One detail in that table does a lot of work: the thresholds are judged at the 75th percentile of page loads, segmented across mobile and desktop. In plain terms, roughly three quarters of your visits need to hit the good mark before a page counts as good. An average that looks fine can still hide a slow experience for a quarter of your users, which is exactly the group worth fixing.
How much they really matter
Core Web Vitals are a ranking signal, but a modest one. Google’s page experience documentation is candid about the ceiling: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.” Read that carefully. Relevance and content quality decide the shortlist. Page experience helps separate pages that are already close.
The same documentation warns against the score-chasing that Core Web Vitals tend to inspire. Good results in a report “doesn’t guarantee that your pages will rank at the top,” and “trying to get a perfect score just for SEO reasons may not be the best use of your time.” The metrics exist to improve the experience for users, not to be gamed for a green light. A fast site full of thin answers stays a thin site. For the work that actually earns the shortlist, see our complete technical SEO guide.
That framing should change your priorities, not your effort. Poor Core Web Vitals still cost you real visitors regardless of ranking, because a page that loads slowly or jumps around loses people before they read a word. Treat the metrics as a user-experience tool with a ranking bonus attached, and you will spend your time in the right place.
How to measure real-user data
Core Web Vitals are field metrics first. That distinction matters. Field data (also called real-user data) records what actual visitors experienced on their own devices and networks. Lab data comes from a synthetic test in a controlled environment. The two can disagree sharply, and Google’s own guidance on lab and field differences explains why: a lab test cannot reproduce the range of devices, connections, and behaviours your real audience brings.
The source of Google’s field data is the Chrome User Experience Report (CrUX), which collects anonymised measurements from real Chrome users over a rolling 28-day window. CrUX is what powers the Core Web Vitals numbers in PageSpeed Insights, the Search Console Core Web Vitals report, and Chrome DevTools. A practical consequence: because CrUX is a 28-day rolling dataset, a fix you ship today will take weeks to show up fully in these reports, so do not panic if the graph does not move overnight.
Lab tools still have their place. Lighthouse and DevTools are the right way to catch regressions before release and to diagnose a problem in a repeatable environment. But note one limit: as Google’s documentation points out, a lab tool like Lighthouse cannot measure INP because there is no user to interact with the page. Total Blocking Time (TBT) is the lab proxy to watch instead, and improving TBT in the lab often improves INP in the field. The workflow that holds up is simple: use field data to decide what to fix, and lab data to work out how.
Practical fixes that move the numbers
Start by finding your worst real-user experience, then work metric by metric. Google’s roundup of the most effective ways to improve Core Web Vitals is a good reference, but the highest-impact moves cluster into a short list.
Improving LCP (loading)
- Serve the largest element fast. Prioritise the LCP image or text block, preload it where sensible, and avoid lazy-loading the hero.
- Cut render-blocking CSS and JavaScript so the browser can paint sooner, and reduce slow server response times, which Google’s optimize LCP guide flags as a common culprit.
- Compress and correctly size images, and use a modern format.
Improving INP (responsiveness)
- Break up long tasks so the main thread is free to respond when a user clicks. Google’s optimize INP guide covers yielding to the main thread and deferring non-critical work.
- Reduce the JavaScript that runs during load, since heavy scripts are the usual reason an early interaction feels stuck.
- Trim or audit third-party scripts, which frequently block the main thread at the worst moment.
Improving CLS (visual stability)
- Set explicit width and height (or CSS aspect-ratio) on images and video so the browser reserves space before they load.
- Reserve space for ads, embeds, and banners rather than letting them push content down on arrival.
- Preload web fonts to avoid the late swap that reflows text, as covered in Google’s optimize CLS guide.
What a focused effort looks like
A documented example shows the payoff of prioritising the worst real-user experience. In a web.dev case study, the Brazilian housing platform QuintoAndar reduced its INP by 80% (mobile INP fell from 1,006 milliseconds to 216 milliseconds in real-user data) after it identified that certain search interactions took around 4 seconds at the 75th percentile. The share of pages meeting the good INP threshold went from 42% to 78%, and pages delivering a poor experience dropped from 32% to 6.9%. QuintoAndar reported a 36% year-over-year increase in conversions over the same period, which it links, though not solely, to the improved experience. The lesson is the method, not the exact figures: measure real users, fix the interactions that hurt the most, and guard against regressions.
Frequently asked questions
What replaced First Input Delay, and when?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, per the web.dev announcement. FID only looked at the first interaction, while INP considers interactions across the whole page lifecycle, so it is a more honest measure of responsiveness.
Are Core Web Vitals a major ranking factor?
No. They are one of many signals and function closer to a tiebreaker. Google’s documentation states it will still show the most relevant content even when page experience is sub-par, so relevance and content quality carry far more weight.
Why is my PageSpeed lab score different from Search Console?
Because they use different data. Search Console and the field section of PageSpeed Insights report real-user data from CrUX, while the lab score comes from a single synthetic test. Google explains the gap between lab and field data as a product of real devices, networks, and behaviours that a lab cannot reproduce.
Should I aim for a perfect score?
No. Google notes that “trying to get a perfect score just for SEO reasons may not be the best use of your time.” Aim to clear the good thresholds at the 75th percentile for real users, then invest the rest of your time in content and relevance.
Written by Matthis Duarte, a senior SEO and organic growth expert with 10+ years of experience driving organic growth for international brands across highly competitive verticals. He is the founder of Knownful, an independent publication on SEO and organic growth featuring in-depth guides, best practices, playbooks and original analyses, including a free monthly study of which brands AI actually recommends across 10 industries.
