Core Web Vitals explained

What LCP, INP and CLS measure, the thresholds Google documents, how they relate to ranking and page experience, and how to measure them in CrUX, PageSpeed Insights and Search Console.

Core Web Vitals are Google's primary field metrics for loading, interactivity, and visual stability. Search Central recommends achieving good Core Web Vitals for success with Search and for users generally. This guide summarizes the official definitions, thresholds, how Google describes their role in ranking and page experience, and how to measure and improve them — without inventing targets beyond what Google and web.dev publish.

The three metrics

web.dev and Search Central document the same three Core Web Vitals and the same "good" thresholds. Assess at the 75th percentile of page loads, separately for mobile and desktop; a page passes when all three metrics meet the good target at that percentile.

Metric	What it measures	Good threshold (official)
LCP — Largest Contentful Paint	Loading performance (when the main content likely appeared)	Within 2.5 seconds of when the page starts loading
INP — Interaction to Next Paint	Responsiveness to user input	200 milliseconds or less
CLS — Cumulative Layout Shift	Visual stability (unexpected layout movement)	Less than 0.1

INP replaced First Input Delay (FID) as a stable Core Web Vital in 2024, per web.dev's lifecycle notes. LCP, INP and CLS are all listed as stable metrics.

How Google uses them in Search

Search Central's page-experience documentation states that Core Web Vitals are used by Google's ranking systems. It also states there is no single "page experience signal," that core ranking systems look at a variety of signals, and that evaluation is generally page-specific (with some site-wide assessments).

Important caveats from the same docs:

Good scores in Search Console or third-party tools do not guarantee top rankings — content relevance still comes first.
Google Search always seeks to show the most relevant content even when page experience is weak; when many helpful results exist, stronger page experience can contribute to success.
Beyond Core Web Vitals, other page-experience aspects (HTTPS, mobile friendliness, avoiding intrusive interstitials, and so on) may not directly boost rank the same way, but they align with what ranking systems seek to reward.

In short: treat Core Web Vitals as real ranking-related signals and as user-experience work — not as a silver bullet.

How to measure: field first, then lab

Core Web Vitals are primarily field metrics. The Chrome User Experience Report (CrUX) collects anonymized real-user data and powers PageSpeed Insights, Search Console's Core Web Vitals report, and related Chrome tooling.

Search Console — Core Web Vitals report — groups URLs by status (good / needs improvement / poor) based on CrUX field data. Use it to find templates that fail at scale.
PageSpeed Insights — shows field (CrUX) data when available, plus lab diagnostics from Lighthouse for a single URL.
Chrome DevTools / Lighthouse — lab measurement for development. Lighthouse can measure LCP and CLS in the lab; it cannot measure INP without real interaction, and uses Total Blocking Time (TBT) as a lab proxy for interactivity issues.
web-vitals JavaScript library — web.dev recommends it for instrumenting your own real-user monitoring so you can debug regressions CrUX alone will not explain.

Lab numbers help while you develop; only field data shows how real devices, networks and interactions affect LCP, INP and CLS.

Practical directions to improve

Google publishes dedicated optimize guides for each metric. High-level themes (details and techniques live in those docs):

Improve LCP

Shorten server response time (TTFB) and use a fast, nearby origin or CDN.
Eliminate render-blocking resources that delay the largest content; prioritize the LCP image or text.
Size and compress the LCP image appropriately; avoid lazy-loading the LCP element.
Faster HTML delivery (including SSR or pre-rendering on JS-heavy apps) often helps both users and crawlers — related to JavaScript SEO and crawl efficiency.

Improve INP

Break up long main-thread tasks so input handlers can run sooner.
Avoid heavy JavaScript on critical interactions; defer non-critical work.
Watch third-party scripts that steal main-thread time after the page looks ready.

Improve CLS

Always set width and height (or CSS aspect-ratio) on images and embeds so space is reserved.
Avoid inserting content above existing content after load.
Prefer transform animations over properties that trigger layout; be careful with late-loading web fonts (font-display strategies).

What "good" does and does not mean

Meeting the official thresholds at the 75th percentile means your page delivers a good experience for most visits in CrUX's sample — not that every visit is perfect, and not that Search will rank you first. Search Central explicitly warns against chasing a perfect score only for SEO reasons; the metrics exist to help you improve the site for users.

Supporting metrics such as Time to First Byte (TTFB) and First Contentful Paint (FCP) are useful diagnostics for LCP, and Total Blocking Time (TBT) is a useful lab proxy when investigating INP. They are not themselves Core Web Vitals. Keep the core three as the pass/fail bar, and use the supporting metrics to explain why a vital is slow.

A sensible workflow

Open Search Console's Core Web Vitals report and note which URL groups fail on mobile vs desktop.
Sample failing URLs in PageSpeed Insights; separate field regressions from lab-only warnings.
Reproduce in DevTools performance tooling; ship fixes; re-check field data after CrUX has enough fresh traffic (field reports lag real deploys).
Keep technical hygiene elsewhere — clean robots.txt, accurate sitemaps, and fewer wasted crawls via the Crawl Budget Snapshot — so Google spends time on the pages you are optimizing. Browse all explainers on the guides index.

Check your own site

The free Crawl Budget Snapshot fetches a site's public robots.txt and sitemaps and gives a quick crawl-waste score with suggested fixes. It is a starting point, not a replacement for Search Console or log analysis.