Core Web Vitals are three measurements of real user experience: how fast the main content appears (LCP), how quickly the page responds to input (INP), and how much it jumps around (CLS). To pass, a page must meet all three thresholds at the 75th percentile of real visits. Google does use them in ranking, but its own documentation says relevance comes first and that chasing a perfect score for SEO alone may not be a good use of your time. Fix them when they’re poor, because users feel the difference. Don’t expect a jump in rankings from going from good to perfect.
The three metrics and their thresholds
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP, Largest Contentful Paint | Loading: when the largest image or text block renders | 2.5 s or less | Up to 4.0 s | Over 4.0 s |
| INP, Interaction to Next Paint | Responsiveness: delay from input to the next visual update | 200 ms or less | Up to 500 ms | Over 500 ms |
| CLS, Cumulative Layout Shift | Visual stability: how much content moves unexpectedly | 0.1 or less | Up to 0.25 | Over 0.25 |
INP replaced First Input Delay as a Core Web Vital in March 2024. If you read an article that still mentions FID, it’s out of date. FID only measured the first interaction’s input delay, while INP looks at interactions across the visit, including how long the next paint took.
The 75th percentile. A page passes if at least 75 percent of visits meet the target, measured separately for mobile and desktop. One good test run on your office connection tells you nothing about this. A page that’s fast for most people and awful for a quarter of them is failing.
How the numbers are defined. LCP candidates are images, video posters or first frames, elements with a CSS background image, and block-level text. CLS isn’t a total over the page’s life: shifts are grouped into windows, with under one second between shifts and five seconds at most per window, and your score is the worst window.
Field data versus lab data
This is where most confusion starts.
Field data comes from real Chrome users, through the Chrome User Experience Report (CrUX). It’s what Search Console’s Core Web Vitals report and the field section of PageSpeed Insights show. It reflects real devices and networks, covers a rolling 28-day window, so changes appear slowly, and it needs enough traffic. A low-traffic page may have no field data of its own.
Lab data comes from a simulated visit, for example with Lighthouse or Chrome DevTools. It’s immediate and repeatable, and good for debugging and catching regressions before a release.
The two often disagree, and for good reasons:
- INP can’t be measured in a normal lab run, since nobody clicks anything. Total Blocking Time is the usual stand-in, and it isn’t the same thing.
- Lab CLS is often too low. web.dev says lab tools see only shifts that happen during load, so later shifts on scroll or from late ads are missed.
- LCP varies with the simulated device and network, the state of caches, and who’s logged in. Real users have cookie banners and returning-visitor caches, and a lab run may not.
Our rule is this: use field data to decide whether there’s a problem, and lab tools to work out why. Field data is what Google uses for its page experience assessment. A Lighthouse score of 100 isn’t a ranking signal in itself, and it doesn’t mean users are having a good time.
How much they affect ranking
Here’s what Google’s documentation says, without embellishment:
- “Core Web Vitals are used by our ranking systems.”
- “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.”
- “There is no single signal” for page experience.
- Good scores don’t guarantee a top position.
- “Trying to get a perfect score just for SEO reasons may not be the best use of your time.”
- Page experience matters more when many helpful pages compete for a query.
Our reading is that they work as a tie-breaker among pages of similar relevance. A thin page with perfect vitals won’t outrank a useful page with slower ones. Google publishes no weights, and we won’t invent any.
The stronger case for fixing them is what happens after the click, as slow and jumpy pages frustrate people regardless of what any ranking system thinks.
The fixes that matter most
web.dev’s list of top recommendations is a good place to begin. Here are the ones with the most effect, in the order we’d try them.
LCP
1. Find out what the LCP element is. PageSpeed Insights and DevTools tell you. Most of the time, it’s a hero image or a heading.
2. Don’t lazy-load it, and make it discoverable. The image must be in the HTML rather than added later by JavaScript or hidden in a CSS background. Give it priority:
<img src="/hero.webp" width="1200" height="630"
alt="Trail runner on a ridge" fetchpriority="high">Leave loading="lazy" off this image. Applying lazy loading across all images in a template is one of the most common LCP mistakes.
3. Reduce server response time. If the first byte takes 1.5 seconds, you’ve used most of your 2.5-second budget before anything else happens. Use a CDN, cache full pages where you can, and look at slow database queries. Each redirect adds a round trip as well, and the Redirect Chain Checker shows you how many you have.
4. Shrink the image. Serve a modern format at the size it’s displayed. Our Image Compressor handles a one-off file, but a build step or image CDN is better for a whole site.
5. Remove render-blocking resources. Large CSS files and synchronous scripts in the <head> delay everything. A/B testing tools that hide the page until they’ve loaded are a frequent cause.
INP
1. Break up long tasks. The browser can’t respond while JavaScript runs on the main thread. Split work into chunks and yield between them:
async function processAll(items) {
for (const item of items) {
process(item);
await scheduler.yield();
}
}scheduler.yield() isn’t available in every browser, so feature-check it and fall back to setTimeout.
2. Remove JavaScript you don’t need. Third party tags are usually the largest part of this. Audit tag managers, chat widgets and old analytics. Each one runs on your visitors’ phones.
3. Give immediate feedback. Update the interface first, then do the slow work. A button that visibly responds right away is what INP measures, and it’s also what people notice.
4. Keep rendering updates small. Very large DOMs and big re-renders are slow. Virtualize long lists, and avoid forcing layout in loops.
CLS
1. Set dimensions on images and video. With width and height attributes, the browser reserves space before the file arrives. This single fix is often enough.
2. Reserve space for ads, embeds and banners. Use a container with min-height. A cookie banner that pushes content down is a typical cause. Overlay it instead.
3. Don’t insert content above what people are reading. Late-loading notices and “related” bars shift everything beneath them.
4. Handle fonts. A late web font that changes text size causes a shift. Preload your main font, and use font-display along with metric overrides if needed.
5. Allow the back/forward cache. Pages restored from bfcache don’t shift or reload. Avoiding unload handlers and Cache-Control: no-store makes a page eligible, and web.dev lists this among its top CLS recommendations.
6. Animate with transform. Animating top, left, or height moves layout and can count as shifts.
Using our checker
Our Core Web Vitals Checker runs a URL through Google’s PageSpeed Insights API for mobile or desktop, and shows real-visitor field data and the simulated lab run as separate sections. Read them with what you now know. The field section is the one that reflects your visitors, and it may be missing for a low-traffic page, or reported for the whole site rather than that URL. The lab section helps explain causes, and it can’t measure INP. A single lab run also varies, so test a few times before you trust a number.
A workable process
- Open Search Console’s Core Web Vitals report. It groups similar URLs together, so you can fix a template rather than a page.
- Take the worst group, on mobile first.
- Reproduce the problem in PageSpeed Insights, and find the element or script responsible.
- Fix it, deploy it, and use Validate fix in the report. Then wait, since the data covers 28 days, and improvement shows up gradually.
- For quicker feedback, add real-user monitoring with Google’s
web-vitalsJavaScript library. CrUX alone doesn’t show per-page-view detail.
Stop once a group is in “good”. Move on to something else, such as content or internal links, and only come back if it slips. The difference between 2.4 and 1.8 seconds matters far less for search than the difference between a mediocre page and an excellent one.