Core Web Vitals: Everything You Need to Know

Core Web Vitals are a set of specific metrics that Google considers important for a web page's overall user experience. They are part of Google's page experience signals used in ranking, which makes them a real, measurable SEO factor — and one of the few where the fixes also directly improve how your site feels to actual visitors.

This guide covers the three current Core Web Vitals (LCP, INP, and CLS) for 2026, including the exact thresholds Google uses, the crucial difference between lab and field data, and concrete, prioritized fixes with code examples. Whether you run a marketing site, a store, or a web app, the principles here apply directly.

What Core Web Vitals Actually Measure

Each Core Web Vital captures a different dimension of the user experience: how fast the page feels, how responsive it is to input, and how stable it is visually. Together they answer three questions a visitor asks within the first few seconds of landing on your page:

• Is it loading? Largest Contentful Paint (LCP) — loading performance.
• Is it usable? Interaction to Next Paint (INP) — responsiveness to input.
• Is it stable? Cumulative Layout Shift (CLS) — visual stability.

A page passes Core Web Vitals only when it hits the "good" threshold for all three metrics at the 75th percentile of real visits. That last detail matters: Google does not grade your fastest visit or your average — it grades the experience of your slower-than-typical visitors (the 75th percentile), so a page that is fast for you on a wired connection can still fail in the field.

The Core Metrics

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible content element (an image, video poster, or large block of text) to render within the viewport. It reflects perceived load speed — the moment the page looks essentially loaded to the user.

• Good: 2.5 seconds or less
• Needs Improvement: 2.5 to 4.0 seconds
• Poor: over 4.0 seconds

The LCP element is usually the hero image, a large headline, or a background image. LCP breaks down into four parts: time to first byte (server response), resource load delay, resource load time, and render delay. Diagnosing which part dominates tells you where to focus.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. This was a major upgrade: FID only measured the delay before the browser started processing the first interaction, while INP measures the full latency — from the user's tap or click all the way to the next frame painted on screen — across all interactions on the page, then reports roughly the worst one. It is a far more honest measure of how responsive a page feels.

• Good: 200 milliseconds or less
• Needs Improvement: 200 to 500 milliseconds
• Poor: over 500 milliseconds

INP is dominated by JavaScript. When a user clicks, if the browser's main thread is busy running scripts, it cannot respond or paint until that work finishes. Heavy frameworks, large bundles, expensive event handlers, and third-party scripts are the usual culprits.

Cumulative Layout Shift (CLS)

CLS measures the total amount of unexpected layout shift that occurs over the page's lifespan. A layout shift happens when a visible element changes position unexpectedly — like when an image loads without reserved space and shoves the text down, or an ad slot pops in and you tap the wrong button. CLS is a unitless score, not a time.

• Good: 0.1 or less
• Needs Improvement: 0.1 to 0.25
• Poor: over 0.25

The score is calculated as impact fraction (how much of the viewport shifted) multiplied by distance fraction (how far it moved), summed across all unexpected shifts. Shifts that happen within 500 milliseconds of a user interaction are excluded, since those are usually intentional (like opening an accordion).

Thresholds at a Glance

Here is the full rating table. Remember: these are measured at the 75th percentile of real-world page loads, and a page must hit "good" on all three to pass.

Field Data vs Lab Data: The Most Important Distinction

This is the concept that trips up almost everyone, so it is worth slowing down. There are two fundamentally different ways to measure Core Web Vitals, and they answer different questions.

Field data (real user monitoring)

Field data is collected from actual Chrome users visiting your site, aggregated in the Chrome User Experience Report (CrUX). This is the data Google uses for ranking. It reflects real devices, real networks, and real interaction patterns over a rolling 28-day window. Critically, INP can only be measured in the field — it requires real users actually interacting with the page. Field data is the source of truth for whether your site passes.

Lab data (synthetic testing)

Lab data comes from a controlled, simulated test run in a tool like Lighthouse — one device, one network setting, no real user. It is reproducible and great for debugging because you can change one thing and re-test. But it cannot measure INP (there is no real interaction) and it can disagree wildly with the field. A page can score 100 in Lighthouse and still fail Core Web Vitals in CrUX because real users are on slower phones and flakier networks.

The practical workflow: use field data to learn whether you have a problem and which metric is failing, then use lab data to reproduce and fix it. You can pull both in one scan with the Core Web Vitals checker and the page speed test.

Additional Important Metrics

First Contentful Paint (FCP)

FCP measures how long it takes for the first piece of content (any text or image) to appear on screen. It is not a Core Web Vital, but it is a key diagnostic for LCP — if FCP is slow, LCP almost certainly will be too, pointing you at server or render-blocking problems.

• Good: 1.8 seconds or less
• Poor: over 3.0 seconds

Total Blocking Time (TBT)

TBT measures the total time between FCP and Time to Interactive where the main thread was blocked long enough to delay input. It is the best lab proxy for INP — since labs cannot measure INP directly, a high TBT in Lighthouse is your warning sign that real-world INP is likely poor.

• Good: 200 milliseconds or less
• Poor: over 600 milliseconds

Time to First Byte (TTFB)

TTFB measures how long the server takes to send the first byte of the response. It is the foundation of LCP — every millisecond of slow server response pushes everything downstream. Aim for under 800 milliseconds; high TTFB usually points to slow hosting, missing caching, or heavy server-side rendering.

How to Improve LCP

Work through these in order — server response first, then the critical resource, then render-blocking.

1. Speed up the server (TTFB) — add caching, use a faster host, and serve from a CDN edge close to users. Target TTFB under 800ms.
2. Optimize the LCP image — use modern formats (WebP/AVIF), compress aggressively, serve responsive sizes with srcset, and always set explicit width and height.
3. Preload the critical resource — tell the browser to fetch the hero image or critical font early so it does not wait for CSS or JS to discover it.
4. Do not lazy-load the LCP element — a common mistake. Lazy-loading the hero image delays the very thing LCP measures. Lazy-load only below-the-fold images.
5. Eliminate render-blocking resources — defer non-critical JavaScript and inline only the critical CSS needed for the first viewport.
6. Use a CDN — serve images, fonts, and static assets from edge servers.

A correct LCP image preload looks like this:

<!-- Preload the hero image and set dimensions to avoid layout shift -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

<img
  src="/hero.avif"
  width="1200"
  height="630"
  alt="Product dashboard screenshot"
  fetchpriority="high"
/>

The fetchpriority="high" hint tells the browser this image matters more than other downloads, which often shaves meaningful time off LCP on its own.

How to Improve CLS

CLS is usually the easiest Core Web Vital to fix because the causes are predictable: things appearing on the page without space reserved for them.

1. Always set dimensions on media — give every image and video explicit width and height (or a CSS aspect-ratio) so the browser reserves space before the file loads.
2. Reserve space for ads, embeds, and iframes — give every dynamic slot a fixed minimum height in CSS so it cannot push content when it fills.
3. Never insert content above existing content — banners, cookie notices, and "you have a new message" bars that push the page down are classic CLS offenders. Overlay them or reserve space.
4. Preload fonts and use font-display: optional — prevents the layout jump when a custom font swaps in (FOUT).
5. Use transform for animations — animate with transform and opacity, not properties like top or height that trigger layout.

The single highest-impact fix is reserving space for images:

/* Reserve the correct space before the image loads -- prevents shift */
img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

/* Reserve a minimum height for ad and embed slots */
.ad-slot {
  min-height: 280px;
}

How to Improve INP

INP is the metric most sites struggle with in 2026, because it is almost entirely a JavaScript problem and modern sites ship a lot of JavaScript. The goal is to keep the main thread free so it can respond to input quickly.

1. Break up long tasks — any task over 50ms blocks input. Split heavy work into chunks and yield control back to the browser between them.
2. Reduce JavaScript — remove unused code, code-split so each page ships only what it needs, and lazy-load non-critical scripts.
3. Tame third-party scripts — analytics, chat widgets, and tag managers run on your main thread. Load them with async/defer, delay them until after interaction, or remove the ones that do not earn their cost.
4. Keep event handlers cheap — avoid expensive synchronous DOM reads/writes inside click and input handlers; debounce high-frequency events.
5. Offload heavy computation to a Web Worker — move parsing, sorting, or number-crunching off the main thread entirely.
6. Decouple visual feedback from heavy work — paint the response (e.g. show a spinner or update the button) first, then do the expensive work, so the user sees immediate feedback.

Yielding to the main thread is the highest-leverage technique. The modern API is scheduler.yield(), with a fallback for older browsers:

async function processItems(items) {
  for (const item of items) {
    doExpensiveWork(item);

    // Give the browser a chance to handle pending input
    if (window.scheduler && scheduler.yield) {
      await scheduler.yield();
    } else {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

By yielding between items, a click that arrives mid-loop can be handled almost immediately instead of waiting for the entire loop to finish — which is exactly what INP measures.

Common Core Web Vitals Mistakes

Most failing pages fail for a handful of recurring reasons. Scan this list before you start optimizing — you will likely recognize at least one.

• Lazy-loading the hero image — adding loading="lazy" to the LCP element delays the exact thing LCP measures. Lazy-load only what is below the fold.
• Images with no width and height — the most common cause of CLS. Without reserved space, every image that loads shoves the page around.
• Trusting Lighthouse alone — a perfect lab score does not mean you pass. Always confirm against field data, which is what Google ranks on.
• Loading too many third-party scripts — chat widgets, A/B testing tools, tag managers, and analytics pile onto the main thread and wreck INP. Audit every script and remove what does not earn its keep.
• Cookie banners and notification bars that push content — overlay them or reserve space; never let them shift the layout.
• Huge unoptimized images — shipping a 2MB PNG hero when a 120KB AVIF would look identical. Convert to modern formats and compress.
• Web fonts that block render — preload key fonts and set a sensible font-display value so text appears immediately.
• Fixing the wrong metric — optimizing LCP when INP is what is failing. Check field data first to learn which metric actually needs work.

A Step-by-Step Optimization Workflow

Rather than randomly applying fixes, follow a diagnose-then-treat loop. This is how professionals approach a failing page.

1. Pull field data first — run the Core Web Vitals checker or check the Search Console report to see which of the three metrics is actually failing at the 75th percentile. Never optimize blind.
2. Reproduce in the lab — run a page speed test on the same URL, throttled to a mid-tier mobile device, so you can iterate quickly without waiting for field data.
3. Identify the bottleneck — for LCP, find the LCP element and break down its load phases; for INP, profile the main thread during interactions; for CLS, watch the page load and note what jumps.
4. Apply one fix at a time — change a single thing, re-test in the lab, and confirm the metric moved. Bundling many changes makes it impossible to know what worked.
5. Ship and wait for the field — deploy, then watch field data over the following four weeks as the 28-day window refreshes.
6. Re-audit the whole site — Core Web Vitals are grouped by URL pattern in Search Console, so a fix on a template often lifts thousands of pages at once. A full site audit confirms the improvement spread as expected.

One more tip: prioritize by template, not by page. If your product template fails CLS, fixing the template fixes every product page in one change. That leverage is why technical SEO work scales so well.

Why Core Web Vitals Matter for SEO and AI Search

Core Web Vitals are a genuine ranking signal, but it is important to keep their weight in perspective. They are a tiebreaker, not a magic bullet: relevant, high-quality content will outrank a faster but weaker page. Where Core Web Vitals decide outcomes is among pages of similar quality competing for the same query — there, the faster, more stable, more responsive page wins.

Beyond rankings, the business case is direct. Faster pages convert better, reduce bounce, and keep users engaged; studies consistently link load time to revenue. And in 2026, performance increasingly shapes AI search too — AI crawlers that struggle to render slow, JavaScript-heavy pages may parse your content less reliably. A fast, stable, well-structured page serves humans, classic search, and AI engines alike. See how your overall search visibility tracks alongside performance, and check AI readiness on the AEO page.

Measuring Core Web Vitals

Use DarnItSEO's Core Web Vitals checker to measure all three metrics in one scan, combining field and lab data. Run a page speed test for a full waterfall breakdown of loading performance, and a complete site audit to see Core Web Vitals in the context of your wider SEO health. You can also cross-check with Google's PageSpeed Insights (which surfaces CrUX field data), the Core Web Vitals report in Google Search Console, and the free web-vitals JavaScript library for real user monitoring on your own site. For the bigger picture, pair this with our technical SEO checklist and the SEO audit guide, and review your dashboard regularly to catch regressions early.

Frequently Asked Questions

What is a good Core Web Vitals score?

A page passes when it hits the "good" threshold on all three metrics at the 75th percentile of real visits: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Hitting "good" on two of three is not enough — Google treats the assessment as pass or fail across all three together.

Why does my Lighthouse score differ from Google Search Console?

Because they measure different things. Lighthouse runs a single simulated lab test on one device and network, while Search Console reports real-world field data from actual Chrome users over a 28-day window. Real users are often on slower phones and networks than your test environment, so field scores are frequently worse than lab scores. Field data (CrUX) is what Google uses for ranking, so trust it over Lighthouse when they disagree.

Did INP replace FID? What changed?

Yes. INP replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the browser began processing the very first interaction. INP measures the complete latency — from input to the next painted frame — across all interactions on the page, then reports the worst one. It is a much more accurate picture of responsiveness, and it is also harder to pass, which is why so many sites focus on it now.

Can I measure INP in a lab tool like Lighthouse?

No. INP requires real users actually interacting with the page, so it can only be measured in the field (via CrUX or your own real user monitoring). In the lab, use Total Blocking Time (TBT) as a proxy — a high TBT in Lighthouse strongly predicts a poor real-world INP, and the same JavaScript fixes improve both.

How much do Core Web Vitals affect rankings?

They are a real but relatively lightweight signal, best thought of as a tiebreaker. Content relevance and quality matter far more, so a faster page will not outrank genuinely better content. But among pages of similar quality, Core Web Vitals can decide who ranks higher — and they affect conversions and bounce rate regardless of rankings, so the work pays off either way.

Which Core Web Vital is usually the hardest to fix?

INP, by a wide margin in 2026. CLS is usually a quick fix (reserve space for media and dynamic content), and LCP responds to image and server optimization. INP is a deeper problem because it stems from how much JavaScript your site runs and how it is structured. Fixing it often means reducing bundle size, breaking up long tasks, and reining in third-party scripts — work that touches the core of how the site is built.

How often is field data updated?

CrUX field data is a rolling 28-day average, updated daily, with a monthly dataset also published. This means improvements you ship today will take roughly four weeks to fully reflect in your field scores, because the window still includes data from before your fix. Be patient after deploying a change — use lab tools to confirm the fix works immediately, then watch the field data catch up over the following month.