Core Web Vitals Explained: LCP, INP and CLS (2026 Guide)

Core Web Vitals are three metrics Google uses to measure the real-world experience of a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A page passes when at least 75% of real visits score "good" on all three.

This guide explains what each metric measures, where the numbers come from, why your PageSpeed Insights score and your Search Console report often disagree, and which fixes actually move each metric. It also gives an honest answer to the question everyone asks: how much do Core Web Vitals matter for rankings?

What are Core Web Vitals?

Core Web Vitals are a subset of Google's Web Vitals initiative, chosen because they capture three distinct parts of user experience: how fast the main content appears, how quickly the page reacts when you tap or type, and whether the layout jumps around while you read.

The set has changed once. In March 2024, INP replaced First Input Delay (FID) as the responsiveness metric. FID only measured the delay before the browser started handling the first interaction; INP looks at the latency of interactions across the whole visit and reports one of the slowest. If an article or tool still talks about FID, it is out of date.

What are the Core Web Vitals thresholds?

Google publishes three bands for each metric. The target is "good" for every metric, on both mobile and desktop.

What does "75th percentile" mean?

Google assesses each metric at the 75th percentile of page loads, separately for mobile and desktop. In practice, this means that if 75% of visits to a page have an LCP of 2.5 seconds or less, the page is "good" for LCP. The remaining 25% can be slower without failing the assessment.

This design has two consequences. First, a fast test on your office Wi-Fi proves little: your slowest quarter of users, often on mid-range Android phones and mobile networks, decides the result. Second, averages hide problems. A page with a 1.8-second average LCP can still fail if a large share of visitors arrive on slow connections. When you set targets, always ask "good at p75, on mobile?" rather than "fast on my laptop?"

Field data vs lab data: why do my scores disagree?

This is the most common source of confusion, so it is worth being precise.

Field data (also called real-user monitoring, RUM) comes from actual Chrome users. Google's public source is the Chrome UX Report (CrUX), which aggregates the previous 28 days of data. Field data is what Google uses for the Core Web Vitals assessment and what Search Console reports.

Lab data comes from a single simulated load, typically Lighthouse, on a fixed device and network profile. It is reproducible and great for debugging, but it is not what Google evaluates.

The practical rule: use field data to decide what to fix and to confirm it is fixed; use lab tools to understand why and to verify a change before release. A Lighthouse performance score of 95 with failing field data means your real users are having a worse experience than the lab simulates, not that Google is wrong.

How do you measure Core Web Vitals?

Several free tools cover the whole workflow, from site-wide overview to a single slow interaction.

• Google Search Console → Core Web Vitals report. Groups similar URLs and shows how many are good, need improvement or poor, for mobile and desktop. Start here for a site-wide view. Groups are based on CrUX field data, so low-traffic sites may show "not enough data".
• PageSpeed Insights (pagespeed.web.dev). The top section shows CrUX field data for the URL (or the whole origin if the URL has too little traffic); the lower section is a Lighthouse lab run with diagnostics.
• CrUX API, CrUX Vis and BigQuery. For historical trends and comparisons across origins.
• Chrome DevTools → Performance panel. Shows live LCP, INP and CLS as you interact with the page, and lets you record a trace to see which script blocks an interaction.
• The web-vitals JavaScript library. Sends metrics from your own visitors to your analytics, including attribution data (which element was the LCP, which interaction was slow). This is how you get field data for pages CrUX does not cover.

A short workflow that works: open the Search Console report, pick the worst URL group on mobile, run one representative URL through PageSpeed Insights, then reproduce the problem in DevTools and fix it.

What causes poor LCP, and how do you fix it?

LCP is usually an image (a hero banner, a product photo) or a large text block. Google's guidance breaks LCP into four parts: time to first byte (TTFB), resource load delay, resource load duration and element render delay. Find which part is large before you change anything.

Typical fixes:

• Make the LCP image discoverable early. It should be in the initial HTML as an <img> with src, not injected by JavaScript or set as a CSS background.
• Never lazy-load the LCP image, and give it a higher priority:

<img src="/images/hero-1200.avif"
     srcset="/images/hero-800.avif 800w, /images/hero-1200.avif 1200w"
     sizes="100vw" width="1200" height="600"
     alt="Dashboard of an SEO audit report"
     fetchpriority="high">

• Reduce TTFB with caching, a CDN and server-side rendering or static generation, rather than rendering the main content in the browser.
• Serve smaller images: modern formats (AVIF, WebP), correct dimensions via srcset, and compression.
• Remove render-blocking resources: inline critical CSS, defer non-critical JavaScript, and avoid chains of redirects before the page starts loading.

What causes poor INP, and how do you fix it?

INP measures the whole cycle of an interaction: input delay (the main thread is busy), processing time (your event handlers) and presentation delay (rendering the next frame). Almost every INP problem comes down to too much JavaScript running on the main thread at the wrong time.

Typical fixes:

• Break up long tasks (anything over 50 ms). Yield to the browser between chunks of work so it can respond to the user:

button.addEventListener('click', async () => {
  showSpinner();              // give visual feedback first
  await scheduler.yield();    // let the browser paint (fallback: setTimeout)
  runExpensiveFilter();
});

• Audit third-party scripts: chat widgets, tag managers, A/B testing and ad scripts are frequent culprits. Remove what you do not use; load the rest later.
• Do less work per interaction: debounce input handlers, avoid re-rendering the whole page for a small state change, and keep the DOM size reasonable.
• Avoid layout thrashing: reading layout properties (such as offsetHeight) right after changing styles forces extra synchronous layouts.

Because lab tools cannot click for you, confirm INP issues with field data or by interacting with the page in DevTools.

What causes poor CLS, and how do you fix it?

CLS grows whenever visible content moves without the user causing it: an image loads without reserved space, a cookie banner pushes the page down, or a web font swaps in with different metrics.

Typical fixes:

• Always set width and height (or CSS aspect-ratio) on images, videos and iframes so the browser reserves space.
• Reserve space for ads, embeds and late-loading widgets with a fixed min-height container.
• Do not insert content above existing content unless it responds to a user action. Show banners as overlays, not by pushing the layout.
• Stabilise fonts: preload key fonts and use font-display with a metric-matched fallback (size-adjust) to reduce the jump when the web font arrives.
• Animate with transform, not properties like top or height, which trigger layout shifts.
• Keep pages eligible for the back/forward cache (bfcache), which makes back navigations instant and stable.

Core Web Vitals fixes at a glance

How much do Core Web Vitals matter for SEO?

Core Web Vitals are part of the signals Google's ranking systems use, under the umbrella of page experience. But Google Search Central is explicit that relevance comes first: a page with excellent vitals will not outrank a much more relevant, helpful page. Good scores alone do not guarantee top positions.

In practice, Core Web Vitals work like a tie-breaker. When several pages are similarly relevant and trustworthy, a better experience can help. Moving from "poor" to "good" is worth doing; chasing a perfect Lighthouse 100 on pages that already pass rarely changes rankings.

The stronger argument is business impact. Slow, jumpy, unresponsive pages lose visitors and conversions regardless of rankings. That is also why Core Web Vitals appear in every serious technical SEO audit: not as the main ranking lever, but as a measurable part of the experience users and search engines both see.

Do Core Web Vitals affect AI Overviews?

Google has not described Core Web Vitals as a separate factor for AI features. AI Overviews and AI Mode draw on pages that are indexed and eligible to appear in Search, so the same fundamentals apply: crawlable, indexable, helpful pages. A fast page is simply one less reason for users to bounce.

How to prioritise Core Web Vitals work

1. Check field data first. If Search Console and PageSpeed Insights show "good" on mobile, performance is probably not your biggest SEO issue.
2. Fix templates, not URLs. Search Console groups similar pages; one fix to a product or article template can move thousands of URLs.
3. Start with "poor", on mobile, on high-traffic templates. That is where users and revenue are.
4. Validate and wait. After deploying, use "Validate fix" in Search Console and allow up to 28 days for CrUX to reflect the change.
5. Monitor with RUM so regressions (a new script, a redesign) are caught within days, not months.

For how Core Web Vitals fit alongside indexing, content and internal linking checks, see our SEO audit checklist.

Key takeaways

• Core Web Vitals are LCP (≤ 2.5 s), INP (≤ 200 ms) and CLS (≤ 0.1), assessed at the 75th percentile of real-user data.
• INP replaced FID in March 2024; lab tools approximate it with Total Blocking Time.
• Google evaluates field data (CrUX), not your Lighthouse score. Use lab data to debug.
• Fix by template and metric: prioritise the LCP image, trim main-thread JavaScript, reserve space for everything that loads late.
• Core Web Vitals are a real but modest ranking signal; relevance and content quality matter more.

Check your site's Core Web Vitals in context

Performance numbers are most useful next to everything else that affects visibility: indexing, canonicals, content and internal links. If you want an evidence-based view of where your site stands, you can request a free SEO audit preview with your score and several real issues, or look at the sample report first to see what the full audit covers.