Core Web Vitals explained — LCP, INP, CLS, their thresholds, and how they affect SEO. Test your site free.
Core Web Vitals are three specific, standardized metrics Google uses to measure real-world user experience: LCP (loading speed), INP (responsiveness), and CLS (visual stability). They're part of Google's broader page-experience signals, and passing all three genuinely means your pages feel authentically fast, responsive, and visually stable to real visitors — not merely fast according to some abstract, disconnected lab score. Here's exactly and precisely what each individual metric genuinely means, the specific numeric thresholds required for a "good" score, and how each one actually, honestly affects SEO rankings in practice today.
The Three Core Web Vitals, Explained Individually and Clearly
LCP — Largest Contentful Paint (loading) Measures how long it takes until the largest visible element on the page — usually a hero image, a video thumbnail, or a large block of text — actually renders and becomes fully visible to the visitor. This is the specific metric that directly answers the practical question "does this particular page feel like it genuinely loaded quickly to a real person looking at it?"
- ✅ Good: ≤ 2.5 seconds
- ⚠️ Needs improvement: 2.5–4 seconds
- ❌ Poor: > 4 seconds
INP — Interaction to Next Paint (responsiveness) Measures precisely how quickly the page genuinely responds when a real visitor taps, clicks, or types — the delay between the interaction and the page visually updating in response. INP replaced FID (First Input Delay) as an official Core Web Vital in March 2024, specifically because it measures responsiveness across a page's entire lifecycle rather than just the first interaction, giving a more complete and honest picture of how a page feels to actually use.
- ✅ Good: ≤ 200 milliseconds
- ⚠️ Needs improvement: 200–500 milliseconds
- ❌ Poor: > 500 milliseconds
CLS — Cumulative Layout Shift (visual stability) Measures precisely how much visible content unexpectedly and jarringly shifts around while the page is still loading — the frustrating experience of trying to tap a button just as an image finishes loading above it and shoves everything down.
- ✅ Good: ≤ 0.1
- ⚠️ Needs improvement: 0.1–0.25
- ❌ Poor: > 0.25
What "Passing" Core Web Vitals Actually Requires at Scale
For a site with dozens or hundreds of pages, "passing Core Web Vitals" isn't a single yes/no answer — Google assesses at the URL or URL-group level, meaning some pages can pass while others fail on the same domain. Search Console's report groups similar URLs together (product pages, blog posts, category pages) to make this manageable, showing which specific groups need attention rather than an undifferentiated site-wide average that could mask serious problems on one page type while others perform well.
A Worked Example: Diagnosing a Real Page
Say a product page scores LCP at 3.8 seconds (needs improvement), INP at 150ms (good), and CLS at 0.18 (needs improvement). Reading this diagnostically: the responsiveness is already fine, so JavaScript execution isn't the bottleneck here. The LCP problem points toward the hero product image — check whether it's compressed, correctly sized, and preloaded. The CLS problem points toward likely culprits like a promotional banner or a "recently viewed" carousel injecting content after the initial page paint without reserved space. Two specific, targeted fixes — optimizing the hero image and reserving space for the dynamically injected element — would likely resolve both flagged metrics without needing to touch anything else on the page.
Why These Three Specific Metrics
Google didn't pick these three arbitrarily — each one captures a genuinely distinct dimension of user experience that the others can't. A page can load its content quickly (good LCP) while still feeling sluggish to interact with (poor INP), or load quickly and respond instantly while still being visually frustrating because elements keep jumping around (poor CLS). Together, the three cover loading, interactivity, and stability — the three pillars of what actually makes a page feel fast and trustworthy to a real visitor, not just fast on a single narrow measurement.
A Brief History of Core Web Vitals
Google introduced Core Web Vitals in May 2020 as a formalized, standardized set of user-experience metrics, folding them into the broader "page experience" ranking signal that rolled out through 2021. Before this formalization, Google had used various looser signals related to speed and mobile-friendliness, but Core Web Vitals represented a deliberate effort to define exactly three specific, measurable dimensions of experience rather than leaving "good user experience" as a vague, unmeasurable concept. The March 2024 replacement of FID with INP was the most significant update since the original launch — a genuine improvement in measurement accuracy, not a cosmetic rename, since INP captures responsiveness across a visitor's entire session rather than only their very first interaction.
Lab Data vs. Field Data: A Crucial Distinction
- Lab data is measured in a controlled, simulated test environment — like our free Website Speed Test — under consistent conditions. It's excellent for diagnosing exactly what's slow and testing whether a fix worked, since it removes the variability of real-world conditions.
- Field data (also called Real User Monitoring, or RUM) is collected from actual visitors' real devices, connections, and conditions — available in Google Search Console's Core Web Vitals report. Google uses field data, not lab data, for the actual ranking assessment.
This distinction matters practically: a page can pass a lab test comfortably while still showing poor field data, if your real visitors are disproportionately on slow connections or older devices the lab test doesn't simulate. Always treat lab data as your diagnostic tool and field data as your actual scorecard.
The Broader Concept of "Page Experience" Signals
Core Web Vitals are the most measurable, best-known component of Google's broader page experience signal, but not the only one — mobile-friendliness, the absence of intrusive interstitials, safe browsing status (no malware or deceptive content), and HTTPS security all factor into the same broader signal alongside the three Core Web Vitals specifically. In practice, most sites already satisfy the non-Core-Web-Vitals components of page experience without dedicated effort, since modern hosting and CMS platforms handle HTTPS and basic mobile-friendliness by default — which is exactly why Core Web Vitals tend to dominate the practical conversation, as the component most sites genuinely still need to work at.
What Specifically Causes Each Vital to Fail
LCP typically fails because of an unoptimized hero image (too large, wrong format, not preloaded), slow server response time delaying when the browser can even start requesting the image, or render-blocking resources (CSS, fonts, JavaScript) that delay the browser from painting the largest element even after it's downloaded.
INP typically fails because of long-running JavaScript tasks that block the browser's main thread, preventing it from responding to a visitor's tap or click promptly — often from heavy third-party scripts, complex client-side interactivity, or inefficient event handlers that do more work than necessary on every single interaction.
CLS typically fails because of images or embeds without explicit dimensions (causing the browser to reflow the page once they load), web fonts that load after the initial text render and shift the layout when they swap in, or dynamically injected content (ads, cookie banners, promotional bars) that pushes existing content down after the page has already rendered.
Full Thresholds Table
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (loading) | ≤ 2.5s | 2.5s – 4s | > 4s |
| INP (responsiveness) | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS (visual stability) | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
To be classified as having "good" Core Web Vitals overall for a URL, Google requires all three metrics to fall in the "good" range for at least 75% of page visits — a strong performance on two out of three isn't enough to pass.
Do Core Web Vitals Affect Rankings?
Yes, but as part of a modest, secondary signal — Core Web Vitals are one input into Google's broader "page experience" ranking signal, functioning more as a tiebreaker between pages of otherwise comparable content quality and relevance, not a substitute for good content. Their bigger, more measurable impact is on conversions and bounce rate rather than raw ranking position — see does page speed affect SEO rankings for the fuller, honest breakdown of direct versus indirect impact.
Core Web Vitals by Page Type
Different page types on the same site tend to struggle with different vitals specifically. A homepage with a large hero image or video is especially prone to LCP problems. A product listing or category page with heavy filtering and sorting interactivity is especially prone to INP problems, since every filter click has to process and re-render results. A page with dynamically injected content — cookie banners, promotional bars, late-loading ads — is especially prone to CLS problems. Knowing this pattern helps you predict, before even testing, roughly which vital is most likely to need attention on a given page type.
Tools Beyond a Simple Speed Test
While a straightforward speed test gives you a fast, actionable snapshot, several complementary tools deepen the picture for specific situations: Chrome DevTools' own Performance panel lets you record and inspect exactly what happens during a page load, frame by frame; Search Console's Core Web Vitals report shows real field data aggregated across your whole site over time; and the Chrome extension "Web Vitals" shows live, per-visit metrics as you personally browse your own site. Each tool serves a different purpose — a quick site-wide health check, a real-world historical trend, or a hands-on frame-by-frame diagnosis — and knowing which one to reach for depends on whether you're doing a first-pass audit or debugging one specific, stubborn problem.
How Core Web Vitals Relate to Other Performance Metrics
Beyond the three official Core Web Vitals, several related metrics still matter for a fuller performance picture: Time to First Byte (TTFB) measures server response speed and heavily influences LCP; First Contentful Paint (FCP) measures when any content first appears, a useful earlier signal than LCP's "largest" element specifically; and Total Blocking Time (TBT), a lab-only proxy for INP, measures how long the main thread was blocked during load. None of these are official Core Web Vitals themselves, but each helps diagnose why a Core Web Vital is failing, functioning as supporting diagnostic detail rather than a competing scorecard.
Common Misconceptions About Core Web Vitals
- "A perfect 100 score is the goal." It isn't — Google's own guidance treats "good" as the target, not a perfect score; diminishing returns set in well before 100, and chasing the last few points often isn't worth the engineering effort relative to other priorities.
- "Core Web Vitals are the same as PageSpeed Insights score." Related but not identical — PageSpeed Insights reports Core Web Vitals alongside several other performance metrics and an overall score; Core Web Vitals specifically are LCP, INP, and CLS.
- "Passing Core Web Vitals guarantees a ranking boost." No — it removes a potential disadvantage relative to competitors, but doesn't actively boost a page above genuinely better, more relevant content.
How to Test and Improve Your Core Web Vitals
Run the free Website Speed Test to see exactly where your site stands on all three metrics, then work through how to improve website loading speed for the complete, prioritized fix guide. If you're specifically on WordPress or Shopify, see how to pass Core Web Vitals in WordPress and Shopify for platform-specific steps.
How Core Web Vitals Are Actually Measured
Google gathers Core Web Vitals field data through the Chrome User Experience Report (CrUX), which aggregates real, anonymized performance data from actual Chrome users who've opted into sharing usage statistics — not from every visitor to your site on every browser, but a large enough sample of real-world Chrome traffic to be statistically meaningful for most sites with reasonable traffic volume. Sites with genuinely low traffic sometimes don't have enough CrUX data for Google to report field data confidently, in which case Search Console falls back to origin-level data (aggregated across your whole domain) rather than per-URL data.
Why Core Web Vitals Differ Between Pages on the Same Site
It's a common point of confusion: two pages on the identical site, built from the same theme and hosting, can show meaningfully different Core Web Vitals scores. This happens because each page's specific content differs — a page with a large hero video has a different LCP profile than a text-heavy blog post; a page with an interactive form has different INP characteristics than a static page. Testing and optimizing your most important pages individually, rather than assuming one site-wide score applies everywhere, gives a more accurate and more actionable picture.
Core Web Vitals and Mobile vs. Desktop Scoring
Google evaluates Core Web Vitals separately for mobile and desktop, and mobile scores are frequently worse — mobile devices generally have less processing power, and mobile network connections are typically slower and less consistent than desktop broadband or Wi-Fi. Since Google's indexing and ranking process is mobile-first, your mobile Core Web Vitals score is the one that carries the most practical weight for SEO purposes, even if your desktop score looks comfortably better.
The Relationship Between Core Web Vitals and Overall Page Weight
A page's total weight (the combined size of its HTML, CSS, JavaScript, images, and fonts) correlates strongly with Core Web Vitals performance, though it's not a perfect one-to-one relationship — a smaller page with poorly optimized, render-blocking resources can still score worse than a slightly larger page that loads its resources in a smart, prioritized order. Reducing overall page weight is a reliable starting strategy, but the order and priority in which resources load often matters just as much as the total weight itself.
Core Web Vitals for Specific Site Categories
News and media sites, publishing frequently with high traffic volume, need particular attention to LCP given ad-heavy layouts and CLS given dynamically inserted ads and related-content widgets that often load after initial render. Portfolio and agency sites, often heavy on large imagery and custom animations for visual impact, need careful balance between visual ambition and LCP/INP discipline — every animation and large image is a deliberate trade-off worth making consciously rather than by default. Directory and marketplace sites, with many listings and heavy filtering interactivity, need particular attention to INP given how much client-side JavaScript typically powers their search and filter experience.
How Often Should You Check Your Core Web Vitals?
Treat this as an ongoing habit rather than a one-time check — a new plugin, a redesigned page template, a new third-party embed, or a hosting change can all silently degrade previously good scores without anyone noticing until traffic or conversions are already affected. Checking monthly, or immediately after any significant site change, catches regressions early rather than discovering them months later during an unrelated audit.
Setting Realistic Internal Goals Around Core Web Vitals
Rather than a vague company-wide mandate to "improve site speed," setting specific, measurable goals tied to the actual thresholds — "get LCP under 2.5 seconds on our top 10 landing pages within one quarter," for instance — gives a team something concrete to work toward and measure against, instead of an open-ended, hard-to-judge initiative. Tie these goals to the same field data Google itself uses (Search Console's Core Web Vitals report) rather than only lab data, so the internal goal actually reflects what matters for real users and real rankings, not just an artificially controlled test environment.
Communicating Core Web Vitals to Non-Technical Stakeholders
When explaining Core Web Vitals to a manager, client, or stakeholder without a technical background, analogies tend to land better than raw metric names: LCP is "how long before the page feels loaded," INP is "how quickly the page responds when you tap something," and CLS is "whether things jump around annoyingly while the page settles." Pairing each analogy with the concrete business impact — conversions, bounce rate, and a secondary SEO benefit — makes the case for investment without requiring the audience to understand the underlying technical mechanics in detail.
Putting It All Together
Core Web Vitals give you three concrete, measurable, actionable dimensions of user experience — loading, responsiveness, and stability — replacing what used to be a vague, hard-to-pin-down sense of a site feeling "slow" with something you can genuinely test, diagnose, and systematically fix.
Frequently Asked Questions
What are the three Core Web Vitals?
LCP (Largest Contentful Paint, measuring loading speed), INP (Interaction to Next Paint, measuring responsiveness), and CLS (Cumulative Layout Shift, measuring visual stability).
What are good Core Web Vitals scores?
LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 — all three need to be in this "good" range for at least 75% of page visits.
Did INP replace FID as a Core Web Vital?
Yes — INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024, since it measures responsiveness across the entire page interaction, not just the very first one.
Are Core Web Vitals a ranking factor?
Yes, as part of Google's page experience signals — but a relatively minor one that mainly acts as a tiebreaker between pages of similar content quality, not a way to outrank fundamentally better content.
What's the difference between lab data and field data?
Lab data comes from a controlled test (like a speed-test tool) and is best for diagnosis; field data comes from real visitors' actual experiences and is what Google uses for the real ranking assessment, visible in Search Console.
Do Core Web Vitals matter more on mobile or desktop?
Google evaluates them for both, but mobile matters disproportionately in practice since most web traffic today is mobile, and mobile devices and connections are more likely to expose genuine performance problems.
How quickly can I improve my Core Web Vitals?
Some fixes (image compression, enabling caching) can show measurable improvement within days; others (a hosting migration, a heavy JavaScript rewrite) take longer — see the full priority-ordered guide for realistic timelines per fix.
Is a "needs improvement" score bad enough to hurt my SEO?
It's worth fixing, but the impact is gradual rather than a cliff — moving from "needs improvement" toward "good" is a genuine, incremental improvement to both SEO and user experience, not a binary pass/fail switch.
Where can I see my site's real-world Core Web Vitals field data?
Google Search Console's Core Web Vitals report, under the Experience section, shows field data aggregated from real visitors over recent weeks, grouped by URL or by group of similar pages.
Do Core Web Vitals apply to single-page applications (SPAs) the same way?
Yes, though measurement is more nuanced — INP in particular matters heavily for SPAs since they rely on JavaScript for most interactions, and a poorly optimized SPA can show excellent initial LCP while still failing INP badly on subsequent in-app navigation.
Can third-party scripts I don't control hurt my Core Web Vitals?
Yes, significantly — analytics tags, ad networks, and embedded widgets from third parties run their own JavaScript on your page, and a slow or heavy third-party script can measurably drag down your INP and LCP even though you didn't write that code yourself.
Do Core Web Vitals apply equally to every page on my site, or just the homepage?
They apply to every individual URL, and Google evaluates them per page (or per group of similar pages when individual page data is too sparse) — a fast homepage doesn't compensate for slow, poorly optimized inner pages elsewhere on the same site.
Is there a way to see historical Core Web Vitals trends over time?
Yes — Search Console's Core Web Vitals report shows historical trend data over recent months, letting you see whether scores are improving, stable, or regressing rather than only a single current snapshot.
Can a single slow page hurt Core Web Vitals results for my entire site?
Not directly for other pages' individual scores, but if enough similar pages share the same underlying template or component causing the issue, Google's URL-grouping can reflect that shared problem across the whole group, not just one isolated page.
Should I worry about Core Web Vitals if my site gets very little organic search traffic?
It still matters for the direct user-experience and conversion benefits regardless of traffic source, but the SEO-specific motivation is naturally weaker for a site relying mainly on paid, social, or direct traffic instead of organic search.
Do Core Web Vitals thresholds ever change over time?
They can, though changes have been infrequent and well-communicated in advance — the March 2024 INP replacement of FID is the clearest recent example, and staying aware of official announcements is worth doing periodically rather than assuming today's thresholds are permanently fixed.
Can I have good Core Web Vitals but still lose to a competitor in search rankings?
Yes, easily — since content relevance and quality carry far more ranking weight than page experience, a competitor with better, more relevant content can outrank you even with slower Core Web Vitals than yours.
Failing Core Web Vitals and not sure why? Scult diagnoses and rebuilds slow sites properly, not just with a quick patch.
