Core Web Vitals measure how a page feels to use:
Core Web Vitals are three specific metrics Google publishes to measure the user experience of a webpage. They quantify how fast the page loads, how quickly it responds to interaction, and how stable the visual layout is once it starts rendering. Each metric has a defined threshold separating good performance from poor performance.
The metrics exist because page speed and responsiveness affect what users do on a page. A page that takes seven seconds to render its main content loses readers who hit the back button before the content arrives. A button that doesn’t respond for two seconds after the user taps it gets tapped again, and again, until the user gives up. A page that shifts visible elements around as it loads makes the user tap the wrong link by accident. Each of these is a measurable failure that the user experiences as friction, even if no single moment looks especially bad.
Google folds Core Web Vitals into the page experience signals used in ranking. The signals aren’t dominant compared to relevance and authority, but they tip the balance between competing pages. Two pages with similar content quality differ in ranking partly based on how their performance metrics compare. A site that ignores Core Web Vitals loses ground to one that doesn’t.
Three metrics, three distinct user moments:
Each Core Web Vital tracks a different aspect of the loading experience. Knowing which moment each metric covers makes the optimization work easier to scope.
| Metric | What it measures | Good threshold | Poor threshold |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible element finishes rendering | Under 2.5 seconds | Over 4.0 seconds |
| INP (Interaction to Next Paint) | Time from user input to visual response | Under 200 milliseconds | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | Total layout shift during page load (unitless score) | Under 0.1 | Over 0.25 |
LCP measures loading speed. The moment the user perceives the page as “loaded” usually corresponds to the moment the biggest visible content finishes rendering. That’s often the hero image, but sometimes it’s a large block of text, a video thumbnail, or a banner. LCP is the time from page request to that moment.
INP measures responsiveness. The metric replaced First Input Delay (FID) in March 2024 because INP captures interaction quality more thoroughly. Where FID measured only the first input on a page, INP measures every interaction during the page’s lifetime, reporting the worst response time as the page’s score. A page that responds instantly to the first click but stutters on subsequent clicks scores poorly on INP and accurately reflects what the user experiences.
CLS measures visual stability. As a page loads, elements appear progressively (images load, ads render, fonts swap). Each of these can shift content that was already visible. The cumulative effect is the layout shift score, a unitless number that adds up the visible movement during loading. A score of 0 means no shift. A score of 1 means the entire visible viewport shifted once. Most real-world scores fall between 0 and 0.3.
The three metrics together cover most of what makes a page feel fast or slow, responsive or sluggish, stable or chaotic. A page passing all three thresholds feels solid. A page failing one or more feels broken in a specific way that maps to the failing metric.
LCP: the moment the page looks done:
The Largest Contentful Paint timestamp marks when the largest above-the-fold content element finishes rendering. The browser tracks every visible element during page load, identifies the largest one in the viewport, and reports the time at which that element became visible.
Several element types can be the LCP target:
| Element type | Common LCP cases |
|---|---|
| <!–INLINECODE0–> | Hero image, product image, article featured image |
| <!–INLINECODE1–> poster | Video player with poster image |
| Background image | CSS background on hero section |
| Block-level text | Large H1, opening paragraph, headline |
| <!–INLINECODE2–> | Embedded SVG illustration |
For most content pages, the LCP element is a hero image or a large block of headline text. The optimization target is the time from page request to that element being fully rendered and visible.
The optimization patterns that move LCP the most:
Image format and size. WebP or AVIF instead of JPG cuts file size 25-34% (WebP, Google’s official measurement) or substantially more with AVIF. Responsive images via srcset deliver the right resolution for the device, avoiding wasted bandwidth on oversized images.
Prioritizing the LCP resource. Two complementary signals tell the browser to load the hero image early. fetchpriority="high" on the <img> tag bumps the image up from the default low priority it would otherwise receive. <link rel="preload" as="image"> in the head helps when the image isn’t discoverable through normal HTML parsing (CSS backgrounds, lazy-discovered resources). For most cases, fetchpriority on the img tag is enough; preload is the heavier intervention for the harder cases.
Server response time. Slow server response delays everything else. The browser can’t render until it has the HTML, and it can’t fetch images until it knows what images to fetch. Reducing time-to-first-byte (TTFB) directly improves LCP.
Render-blocking resources. Stylesheets and synchronous scripts in the head block rendering until they download and execute. Critical CSS inlined in the head and non-critical CSS loaded asynchronously frees up the rendering pipeline.
Content delivery network. CDN edge locations serve resources from geographically closer servers, reducing network latency. For sites with global audiences, this can shave hundreds of milliseconds from LCP.
The LCP threshold (under 2.5 seconds for the “good” rating) reflects what’s reasonable on most networks and devices. Pages that consistently exceed 4 seconds for LCP indicate substantial performance problems that affect ranking.
INP: the moment the page responds to a tap:
Interaction to Next Paint measures how long the page takes to visually respond after any user input (click, tap, keystroke, scroll trigger). The metric uses the worst observed response time during the page’s lifetime as the score, reflecting the user’s experience of the slowest interaction.
What causes high INP:
Heavy JavaScript on the main thread. Long-running scripts block the browser from processing user input until they complete. A page with 500ms of JavaScript execution time after a button click can’t paint a response until that work finishes.
Synchronous third-party scripts. Analytics, advertising, and social embed scripts often run synchronously, blocking the main thread while they execute. Each script adds to the total blocking time.
Large DOM updates. Replacing or modifying many DOM elements in response to a click takes time. A button click that triggers a 1,000-row table re-render produces noticeable lag.
Layout thrashing. JavaScript that reads and writes the DOM in alternating patterns forces the browser to recalculate layout repeatedly. The cumulative cost shows up as response delay.
The optimization patterns:
Defer non-critical JavaScript. Scripts that don’t need to run immediately (analytics, A/B testing tools, third-party widgets) can be loaded with async or defer attributes, or executed after the page becomes interactive.
Break up long tasks. JavaScript tasks longer than 50 milliseconds block input handling. Splitting work into smaller chunks (using requestIdleCallback or setTimeout(fn, 0)) lets the browser handle input between chunks.
Use web workers. Computational work that doesn’t need DOM access can run in a web worker on a separate thread, leaving the main thread free for input handling.
Server-render the initial state. Pages that depend on JavaScript to populate initial content force the browser to download, parse, execute, and render before becoming interactive. Server-rendered initial state shifts that work to the server, leaving less for the browser.
The INP threshold (under 200 milliseconds for “good”) corresponds to what feels instantaneous. Response times between 200 and 500ms feel sluggish but functional. Times above 500ms feel broken, with users uncertain whether their input registered.
CLS: the moment the page stops moving:
Cumulative Layout Shift measures how much visible content moves around during page load. Each shift contributes to the cumulative score based on how much of the viewport the moving content covers and how far it moved.
Common causes of layout shift:
Images without explicit dimensions. When an image loads without width and height attributes, the browser doesn’t know how much space to reserve. Surrounding content shifts when the image finally renders. The fix is adding width and height to every image, which lets the browser reserve space immediately.
Ads loading after content. An ad slot rendering after the page’s text content pushes the text down. The user sees content move at exactly the moment they were trying to read it.
Web fonts swapping. When the page loads a fallback font initially and then swaps to a custom web font, the line heights and character widths often differ slightly, shifting the entire layout. The fix is font-display: optional (which prevents the swap if the font doesn’t load quickly) or explicit size-adjust declarations that match the fallback to the custom font’s metrics.
Late-injected content. Newsletter signups, cookie banners, related-content widgets, and anything else injected by JavaScript after initial render push existing content out of position.
Animations that affect layout. CSS transitions on properties like width, height, or top cause the browser to recalculate layout for the animated element. Animating transform properties instead (translate, scale) animates without affecting layout.
The CLS threshold (under 0.1 for “good”) allows for minor shifts during normal page loading. Scores above 0.25 indicate substantial layout instability that frustrates users trying to interact with the page.
Where the measurements come from:
Google reports Core Web Vitals data from two distinct sources, each with its own purpose.
The Chrome User Experience Report (CrUX) collects anonymized field data from real Chrome users who have opted into usage statistics. The data represents the experiences of actual visitors loading the actual pages on the actual devices and networks they use. CrUX data feeds into Google’s ranking signals and is the data that matters for SEO.
Lab data comes from synthetic testing tools like Lighthouse, PageSpeed Insights, and WebPageTest. These tools run automated tests under controlled conditions, measuring the page’s performance against simulated network speeds and device profiles. Lab data is useful for diagnosis (it identifies what’s slowing the page down) but doesn’t directly affect ranking.
The two data sources frequently disagree. A page can score well in lab tests run on fast simulated connections and score poorly in CrUX data collected from real users on slower mobile networks. The CrUX data is the source of truth for ranking purposes, but the lab data is what surfaces actionable optimization targets.
Search Console’s Core Web Vitals report shows the CrUX data for the site, broken down by URL group and device type. The report categorizes URLs as Good, Needs improvement, or Poor based on their LCP, INP, and CLS scores at the 75th percentile of measured visits. The 75th percentile threshold means a page needs to perform well for three-quarters of its visitors to qualify as “good”, which is stricter than typical median measurements.
For sites without enough CrUX traffic to generate field data (typically smaller sites), the report shows no data. The page still gets evaluated by Google’s algorithm based on the technical signals it can measure during crawl, but the CrUX-derived ranking input doesn’t apply.
The CWV-ranking relationship, calibrated:
Core Web Vitals are part of Google’s ranking algorithm, but the weight is moderate rather than dominant. Several practical observations frame the actual impact.
Content quality matters more. A high-quality page with poor Core Web Vitals scores ranks above a low-quality page with perfect scores. The performance signals act as a tiebreaker between pages of similar quality, not as a replacement for the relevance and authority signals that drive most ranking.
Mobile measurements drive the signal. Mobile-first indexing means the mobile Core Web Vitals are the ones Google uses for ranking. A site with great desktop performance and poor mobile performance ranks based on the mobile experience.
The Good/Needs Improvement/Poor thresholds matter more than the exact scores. Moving from “Poor” to “Needs Improvement” changes the signal. Moving from 2.6 seconds LCP to 2.4 seconds LCP changes the rating from “Needs Improvement” to “Good”, which crosses a threshold. Improvements that don’t cross thresholds may not change anything in ranking, even if they reduce the measured value.
Page experience is broader than CWV alone. The page experience signal includes HTTPS, mobile-friendliness, and no intrusive interstitials alongside Core Web Vitals. A site can fail page experience for reasons unrelated to CWV (a security cert error, an intrusive popup), and the broader signal reflects the full set of factors.
The ranking impact compounds slowly. Improvements in Core Web Vitals don’t produce immediate ranking jumps. The signal influences ranking gradually as Google’s data accumulates and the algorithm processes the new metrics. Sites that fix performance problems often see results over weeks rather than days.
Seven Core Web Vitals anti-patterns:
Pages that fail Core Web Vitals usually fail in predictable ways. The same patterns show up across CMS platforms, themes, and frameworks.
- Hero image without priority signal. The largest image on the page is discovered through normal HTML parsing and assigned a low default priority, delaying LCP. Fix: for images directly in the HTML, add
fetchpriority="high"to the LCP candidate (<img src="hero.webp" fetchpriority="high">). For LCP images loaded via CSS background or that need earlier discovery, add<link rel="preload" as="image" href="hero.webp" fetchpriority="high">to the head. The image optimization piece covers the trade-off between the two approaches in more depth.
- Render-blocking CSS or JavaScript. Resources in the head delay rendering until they download and execute. Fix: inline critical CSS, defer non-critical CSS with
media="print" onload="this.media='all'", and useasyncordeferon scripts that don’t need to block.
- Images without width and height attributes. Layout shifts as images load because the browser can’t reserve space. Fix: add explicit
widthandheightto every image tag. The values can be in pixels even when CSS resizes the image responsively.
- Late-loading ads or embeds. Ad slots and third-party widgets render after content, pushing the visible page around. Fix: reserve space for ad slots with
min-heightCSS so the layout doesn’t shift when the ad arrives. Defer non-critical third-party content until after main content loads.
- Long JavaScript tasks blocking interaction. Heavy scripts on the main thread prevent input from being processed. Fix: break long tasks into smaller chunks with
setTimeout(fn, 0)orrequestIdleCallback. Move computational work to web workers when DOM access isn’t needed.
- Web fonts causing layout shift on load. Font swap between fallback and custom font shifts the entire text layout. Fix: use
font-display: optionalto skip the swap when the custom font doesn’t arrive quickly. Match fallback fonts to custom fonts withsize-adjustdeclarations.
- Lab testing without CrUX validation. The site looks fast in PageSpeed Insights but scores poorly in real-user data. Fix: check the Search Console Core Web Vitals report for field data. CrUX is what Google uses for ranking, not Lighthouse scores.
An eighth pattern worth flagging: optimizing scores without changing user experience. Performance improvements that game the metrics without actually making the page feel faster (placeholder images that swap in later, hidden content that delays its appearance) eventually get caught when CrUX data reflects real user experience. Fix: optimize for the experience, not the score. The score follows.
Three metrics, one larger question:
Core Web Vitals decompose a single question, “does this page work for the user?”, into three measurable pieces. LCP asks whether the page loads in time to keep the user. INP asks whether the page responds when the user tries to do something. CLS asks whether the page holds still while the user reads it.
The three metrics are specific. The underlying question they answer is general. Sites that focus only on the metrics, treating Core Web Vitals as a checklist of technical optimizations, sometimes hit the thresholds without producing a better experience. Sites that focus on the underlying question, treating the metrics as proxies for whether the page is usable, end up improving the metrics naturally as a side effect of making the page feel right.
The page experience framework that includes Core Web Vitals points in the same direction. Page experience isn’t just performance. It’s the combined experience of using the page (fast enough, responsive enough, stable enough, secure, mobile-friendly, free of interstitials that block reading). Each piece is measurable. The combined effect is what determines whether the user stays.
What the three metrics get right is that the user’s experience can be measured, at least partially, from outside the user’s head. The time the page took to render is measurable. The lag between input and response is measurable. The amount of visible motion during loading is measurable. The general question of whether the page is good to use breaks down into these specific questions, and the specific questions have specific answers. The work of optimization is reading those answers and adjusting until each one passes. The underlying experience improves at the same time, because the metrics were chosen for exactly that reason. The specifics are how the general gets handled.