Core Web Vitals Explained: LCP, INP, and CLS Thresholds and Fixes

How Core Web Vitals Are Measured

The detail that explains most Core Web Vitals confusion is where the numbers come from. They are field metrics, collected from real Chrome users who visit your pages, anonymized and aggregated into the Chrome User Experience Report (CrUX). Google evaluates each metric at the 75th percentile over a rolling 28 day window: if 75% of visits have LCP at or under 2.5 seconds, the page passes LCP. The 75th percentile means a quarter of your visitors can have a worse experience and you still pass, but your typical visitor cannot.

This is why a perfect Lighthouse score and a failing vitals assessment coexist: the lab run simulated one mid-range device, while your field data reflects your actual audience's devices and networks. It also means fixes take patience, after you deploy an improvement, the 28 day window has to roll forward before your assessment fully reflects it. Pages without enough traffic for CrUX data get evaluated by grouping with similar pages, and site-wide origin data fills in where page-level data is thin.

Where to look: Google Search Console's Core Web Vitals report groups your pages into passing and failing by URL group, making it the scoreboard to check first. PageSpeed Insights shows field and lab data for a single URL side by side, and the web-vitals JavaScript library or the CrUX API feed the raw numbers into your own dashboards. Testing methodology for the lab side is covered in our website speed test guide.

Largest Contentful Paint (LCP)

LCP measures how long until the largest content element in the viewport finishes rendering, typically the hero image, a video poster, or the main headline block. It is the "when did the page actually show up" metric. Good is 2.5 seconds or less at the 75th percentile, needs improvement runs to 4 seconds, and beyond that is poor.

LCP problems decompose cleanly into four phases, and finding which phase is slow tells you the fix. First, time to first byte: a server that takes 1.5 seconds to respond has spent 60% of the LCP budget before the browser sees a single tag, and the fixes are caching, CDNs, and faster backends as covered in our speed testing guide. Second, resource load delay: the browser cannot download the LCP image until it discovers it, and images injected by JavaScript or referenced only in CSS backgrounds get discovered late. Putting the LCP image in the initial HTML as a plain img tag, or adding a preload link for it, removes the delay. Third, resource load time: a 2 megabyte hero PNG takes seconds on cellular, while the same image as a properly sized WebP or AVIF takes a fraction of that; setting fetchpriority="high" on the LCP image tells the browser to prioritize it over less important resources. Fourth, render delay: render-blocking stylesheets and synchronous scripts in the head postpone painting anything, so inline critical CSS, defer noncritical scripts, and keep the head lean.

A practical LCP checklist for the common case of a hero image page: serve the image in a modern format sized to its slot, reference it directly in the HTML, mark it fetchpriority="high", do not lazy-load it, preconnect to the image CDN if it lives on another origin, and get TTFB under 800 milliseconds. Those six items fix the large majority of failing LCP pages.

Interaction to Next Paint (INP)

INP replaced First Input Delay in March 2024 and measures something stricter: for each tap, click, and keypress across the whole visit, how long until the next frame paints in response, with the page graded on roughly its worst interaction. Good is 200 milliseconds or less, needs improvement runs to 500, and beyond that is poor. Where FID only measured the delay before an event handler started, INP measures until the user sees a response, covering the handler's full execution and the rendering after it.

INP is a JavaScript metric. The browser processes interactions on the main thread, and anything else occupying that thread, a long-running handler, a framework re-rendering a large component tree, a third-party script parsing, makes the interaction wait. The classic INP failures: a click handler that does synchronous work for 400 milliseconds, an input field that re-filters a 10,000 row list on every keystroke, and hydration storms in JavaScript-heavy sites where the page looks ready but the main thread is drowning.

The fixes share one theme, get off the main thread and do less at once. Break long tasks into chunks so the browser can paint between them, yield to the event loop inside heavy handlers, debounce input-driven work so it runs once per pause rather than per keystroke, virtualize long lists so updates touch dozens of DOM nodes instead of thousands, and move genuinely heavy computation into a web worker. For third-party scripts, the biggest INP offenders on many sites, load them after interaction or drop them: measure what each tag costs in the Performance panel and ask whether the heat map widget is worth failing vitals for. Chrome DevTools' performance trace with the interactions track shows exactly which task blocked which interaction, turning INP debugging from guesswork into reading.

Cumulative Layout Shift (CLS)

CLS measures visual stability: how much the page's content jumps around during the visit, scored by how much of the viewport shifted and how far. Good is 0.1 or less, poor is above 0.25. It is the metric for the universally hated experience of tapping a button just as an ad loads above it and pushes it out from under your finger.

Layout shift has a short list of causes, all preventable. Images without dimensions: the browser reserves no space, then reflows everything when the image arrives, fixed by width and height attributes on every img so the space is reserved before load. Injected content: ads, banners, and embeds that push content down when they load, fixed by reserving a fixed-size container for them regardless of what loads into it. Web fonts: text renders in a fallback font, then reflows when the web font arrives with different metrics, mitigated with font-display strategies and size-adjust so the swap barely moves anything. Late-arriving UI: cookie notices and promo bars inserted at the top of the document, fixed by overlaying them instead of inserting them into the layout flow.

One subtlety: CLS accumulates across the whole visit, not just initial load, so shifts triggered by lazy-loaded sections and infinite scroll count too. Shifts caused within 500 milliseconds of a user interaction are excluded, expanding an accordion does not hurt you, but content that moves on its own always does.

Do Core Web Vitals Affect Rankings?

Yes, as one signal among many, and Google has been consistent about both halves of that sentence. Vitals are part of the page experience signals used in ranking, they function as a factor rather than the factor, and great content on a failing page still outranks thin content on a passing one. The practical read: in competitive queries where content quality is comparable, experience signals are a tiebreaker you control, and the failing site is donating that tiebreaker to its competitors.

The indirect effects are less debated and probably larger. Slow, janky pages convert worse, get abandoned more, and earn fewer return visits, all behaviors that feed back into performance of the site as a business regardless of the ranking algorithm's internals. Fixing vitals is one of the rare projects that serves SEO, conversion, and user satisfaction with the same work. Site-wide crawls like SE Ranking's audit pair vitals data with the technical SEO issues on each page, useful for prioritizing when a large site fails in multiple ways at once.

Keep perspective on effort allocation: going from failing to passing is valuable, going from LCP 2.4 to LCP 1.9 is polish with diminishing returns. Fix the failing metric, verify the fix in field data over the following weeks, then put the remaining energy into content and product.

Monitoring Vitals Continuously

Vitals regress the way all performance regresses, quietly, via a new tag manager script or an unoptimized image in a template. The monitoring stack mirrors the measurement split. For field truth, check Search Console's vitals report on a regular cadence and treat new failing URL groups as bugs. For pre-deploy protection, run Lighthouse CI with metric budgets in the pipeline, per our Lighthouse audit guide, so a change that doubles LCP fails the build instead of the field assessment. For custom visibility, the web-vitals library reports real user numbers into your own analytics, letting you segment by device, geography, and page template to find exactly who is having the bad experience. Scripted browser checks with Playwright extend measurement to logged-in flows that public tools cannot reach, and website monitoring covers the availability side of the same discipline.