Core Web VitalsCWV

nounalso called LCP, INP, CLS or page experience

Definition

Core Web Vitals are Google’s three field metrics for page experience — Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability — measured from real Chrome users and used as a modest ranking signal.

Updated 6 min read8 cited sources

On this page8 sections

Why it matters for founders and small teams

Core Web Vitals are one of the few ranking inputs Google names outright, but Google also says relevance comes first — and small teams regularly burn weeks chasing a perfect score that changes little. The useful goal is “good” at the 75th percentile on the templates that earn traffic, plus a fast server response, which is also what AI engines’ live fetchers need when they pull your page while a user waits.

What are the three Core Web Vitals?#

The three Core Web Vitals are Largest Contentful Paint (LCP), which measures loading; Interaction to Next Paint (INP), which measures responsiveness; and Cumulative Layout Shift (CLS), which measures visual stability — each judged at the 75th percentile of real Chrome users’ page loads, mobile and desktop separately.

MetricWhat it measuresGoodNeeds improvementPoor
LCP — Largest Contentful PaintWhen the largest image or text block in view finishes rendering≤ 2.5 s≤ 4 s> 4 s
INP — Interaction to Next PaintHow quickly the page responds visually to clicks, taps and key presses across the visit≤ 200 ms≤ 500 ms> 500 ms
CLS — Cumulative Layout ShiftHow much visible content jumps around unexpectedly≤ 0.1≤ 0.25> 0.25

INP replaced First Input Delay as a Core Web Vital on 12 March 2024, so any audit, plugin or agency report still quoting FID is out of date. A page passes only when all three metrics are good at the 75th percentile: up to a quarter of visits can be slower and the page still passes, but one poor metric fails it.

The data comes from the Chrome UX Report (CrUX), which records real visits from Chrome users — field data, not a lab simulation. That’s why the metrics reward what visitors actually experience on their own devices and connections, and why a fast developer laptop proves little.

Do Core Web Vitals affect rankings?#

Core Web Vitals do affect rankings — Google says they “are used by our ranking systems” — but modestly: Google also says it shows the most relevant content even when page experience is sub-par, and that chasing a perfect score just for SEO “may not be the best use of your time.”

  • Used in ranking

    Official

    Google’s page experience FAQ: “Core Web Vitals are used by our ranking systems.” Other page experience aspects “don’t directly help your website rank higher.”

  • Relevance comes first

    Official

    Google shows the most relevant content even if the experience is poor; a great experience helps most when many pages are equally helpful.

  • Mostly page-level

    Official

    Google’s core ranking systems “generally evaluate content on a page-specific basis,” though it also has “some site-wide assessments.”

  • Small sites may have no field data

    Official

    Search Console’s report needs a minimum amount of real-user data. Quiet URLs are grouped with similar pages or rolled up to the whole origin, and some are left out entirely.

Rankbox benchmark

The Core Web Vitals Scorecard

Google’s published thresholds for each Core Web Vital, plus the server-response target web.dev offers as a rough guide. Score each traffic-earning template at the 75th percentile of real-user data, mobile and desktop separately.

≤ 2.5 s

LCP — good

Largest Contentful Paint within this time for 75% of page loads. Poor starts above 4 seconds.

≤ 200 ms

INP — good

Interaction to Next Paint at or under this for 75% of page loads. Poor starts above 500 ms.

≤ 0.1

CLS — good

Cumulative Layout Shift at or under this score for 75% of page loads. Poor starts above 0.25.

3 of 3 at p75

Passing rule

A page passes only when all three are good at the 75th percentile; Search Console grades a URL group by its slowest metric.

≤ 0.8 s

Time to First Byte — rough guide

Not a Core Web Vital, but web.dev suggests most sites aim for this, with poor above 1.8 seconds. It’s the part of speed crawlers and live AI fetchers feel.

How to read it: Read it top to bottom for each template. Any poor metric is the priority, needs-improvement is worth fixing when it’s cheap, and good is done. Then check server response time, because a page that’s good for people but slow to respond can still lose a bot’s live fetch.

Free to use and adapt. If you cite it, link to rankbox.xyz/glossary/core-web-vitals.

How do you measure Core Web Vitals?#

Measure Core Web Vitals with field data from real Chrome users — Search Console’s Core Web Vitals report and PageSpeed Insights both draw on the Chrome UX Report — and use lab tools like Lighthouse only to debug, because a lab test has no real user and cannot measure INP.

ToolDataUse it for
Search Console → Core Web VitalsField (CrUX), grouped by similar URLsWhich templates fail, on mobile and desktop
PageSpeed InsightsField (CrUX) plus a Lighthouse lab runOne URL’s real-user scores and likely causes
Lighthouse, Chrome DevToolsLabDebugging LCP and CLS, with Total Blocking Time as a stand-in for INP
The web-vitals libraryField, in your own analyticsPages too quiet to appear in CrUX
js
// Send real-user Core Web Vitals to your own analytics endpoint
import { onCLS, onINP, onLCP } from "web-vitals";
 
function send(metric) {
navigator.sendBeacon("/analytics", JSON.stringify({
name: metric.name, // "LCP" | "INP" | "CLS"
value: metric.value,
rating: metric.rating, // "good" | "needs-improvement" | "poor"
page: location.pathname,
}));
}
 
onCLS(send);
onINP(send);
onLCP(send);

Search Console grades each group of URLs by its slowest metric and reports the last 28 days of data, and its fix validation runs a 28-day monitoring session. Expect a month between shipping a fix and seeing it confirmed in Search Console.

Core Web Vitals matter to AI search indirectly: Google’s AI Overviews and AI Mode rest on the same ranking systems that use them, but AI crawlers never click, scroll or watch the layout, so what they feel is server speed and page weight.

Google AI Overviews & AI ModeHelps
AI Overviews and AI Mode are grounded in core ranking, which uses Core Web Vitals. Google’s AI optimization guide lists “a good page experience” — including reducing latency — among the technical basics.
Server response timeHelps
Not a Core Web Vital, but the part of speed a bot experiences. Live fetchers such as ChatGPT-User, Claude-User and Perplexity-User retrieve pages while the user waits — see AI crawlers — and slow responses also lower how much Google crawls, as covered under crawl budget.
Fast first paintHelps
SE Ranking found pages with a first contentful paint under 0.4 seconds averaged 6.7 ChatGPT citations, against 2.1 for pages slower than 1.13 seconds. A correlation, not proof of cause.
Page weightRequired
Googlebot reads only the first 2 MB of a page’s HTML, and Brave’s discovery fetches — which feed Claude’s search provider — refuse pages over 2 MB and time out after 10 seconds.
INP and CLS, for AI crawlersNo effect
Crawlers don’t tap, type or look at the layout, so these can’t change what a bot reads. They still feed Google’s rankings, and through them its AI features.

Server-side rendering often helps both audiences at once: the HTML arrives complete, the largest element can paint without waiting for a script bundle, and non-rendering bots get the full text in a single fetch.

Common mistakes with Core Web Vitals#

The most common Core Web Vitals mistakes are optimizing a Lighthouse lab score instead of field data, chasing perfection on pages already rated good, still reporting First Input Delay after INP replaced it, and speeding up the homepage while the templates that earn traffic stay slow.

Myth

A Lighthouse score of 100 means the page passes.

Reality

Lighthouse is a lab test of one simulated load and can’t measure INP. Google uses field data from real Chrome users at the 75th percentile.

Myth

Core Web Vitals are the biggest ranking factor.

Reality

Google says good scores don’t guarantee top rankings and relevance comes first. Treat them as a floor to clear, not a lever to pull forever.

Myth

An empty Core Web Vitals report means we're fine.

Reality

It usually means too little traffic for CrUX, not a pass. Check PageSpeed Insights, which can fall back to origin-level data, or collect your own with the web-vitals library.

Myth

Speed only matters for human visitors.

Reality

AI fetchers retrieve pages live, and heavy or slow pages can miss their deadlines — Brave’s discovery fetches stop at 10 seconds. A fast server response is the speed bots actually feel.

Sources

  1. 1.Understanding Core Web Vitals and Google search resultsGoogle Search Central · developers.google.com
  2. 2.Understanding page experience in Google Search resultsGoogle Search Central · developers.google.com
  3. 3.Web Vitalsweb.dev · web.dev
  4. 4.Defining the Core Web Vitals metrics thresholdsweb.dev · web.dev
  5. 5.Interaction to Next Paint is now a stable Core Web Vitalweb.dev · web.dev
  6. 6.Core Web Vitals reportSearch Console Help · support.google.com
  7. 7.Time to First Byte (TTFB)web.dev · web.dev
  8. 8.How to optimize for ChatGPTSE Ranking · seranking.com

Know someone who’d find this useful? Send it their way.

Written by

Rankbox Team

The team behind Rankbox. We study how ChatGPT, Perplexity, Gemini, and Google AI Overviews choose their sources, and publish what we learn so you can put it to work.

See which AI answers cite you today

Enter your site to see how often ChatGPT, Perplexity, Gemini, and Google cite your brand, and exactly what to publish next.

No credit card required · Free 7-day trial