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.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | When the largest image or text block in view finishes rendering | ≤ 2.5 s | ≤ 4 s | > 4 s |
| INP — Interaction to Next Paint | How quickly the page responds visually to clicks, taps and key presses across the visit | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS — Cumulative Layout Shift | How 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
OfficialGoogle’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
OfficialGoogle 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
OfficialGoogle’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
OfficialSearch 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.
| Tool | Data | Use it for |
|---|---|---|
| Search Console → Core Web Vitals | Field (CrUX), grouped by similar URLs | Which templates fail, on mobile and desktop |
| PageSpeed Insights | Field (CrUX) plus a Lighthouse lab run | One URL’s real-user scores and likely causes |
| Lighthouse, Chrome DevTools | Lab | Debugging LCP and CLS, with Total Blocking Time as a stand-in for INP |
The web-vitals library | Field, in your own analytics | Pages too quiet to appear in CrUX |
// Send real-user Core Web Vitals to your own analytics endpointimport { 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.
Do Core Web Vitals matter for AI search?#
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-UserandPerplexity-Userretrieve 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.
Related terms#
- SSRTechnical SEOServer-side renderingThe practice of generating a page’s full HTML on the server before sending it, so crawlers that don’t run JavaScript — which includes most AI crawlers — can read the content in the first response.Read the entry
- Technical SEOCrawl budgetThe number of URLs a search engine is willing and able to crawl on a site in a given period, set by how much load the server can take and how much the engine wants the content — a real constraint mainly for large or fast-changing sites.Read the entry
- SEOAI search & GEOSearch engine optimizationThe practice of improving a website’s content, technical setup and authority so search engines crawl, index and rank it for relevant queries — and because most AI answer engines retrieve their sources from a search index, it is also the foundation of AI visibility.Read the entry
- GSCMeasurementGoogle Search ConsoleGoogle’s free tool for site owners that reports how a site performs in Google Search — queries, impressions, clicks, position and indexing — and since 2026 it also reports impressions in Google’s generative AI features and lets owners opt out of them.Read the entry
- AI search & GEOAI OverviewsAI-generated summaries shown at the top of some Google search results, written by a Gemini model from pages in Google’s search index and linked to their sources — so they are won through ordinary Google eligibility, not a separate submission or special markup.Read the entry
Go deeper
Sources
- 1.Understanding Core Web Vitals and Google search resultsGoogle Search Central · developers.google.com ↗
- 2.Understanding page experience in Google Search resultsGoogle Search Central · developers.google.com ↗
- 3.Web Vitalsweb.dev · web.dev ↗
- 4.Defining the Core Web Vitals metrics thresholdsweb.dev · web.dev ↗
- 5.Interaction to Next Paint is now a stable Core Web Vitalweb.dev · web.dev ↗
- 6.Core Web Vitals reportSearch Console Help · support.google.com ↗
- 7.Time to First Byte (TTFB)web.dev · web.dev ↗
- 8.How to optimize for ChatGPTSE Ranking · seranking.com ↗
