Core Web Vitals (CWV) are Google's standardized set of real-user metrics that measure a webpage's loading performance, interactivity, and visual stability. Core Web Vitals form a subset of Web Vitals and sit inside Google's broader page-experience signals. The metrics are assessed with field data collected from real users, measured at the 75th percentile, so a passing score means most visitors receive a satisfactory experience.
The three Core Web Vitals metrics are Largest Contentful Paint (LCP), which measures loading performance; Interaction to Next Paint (INP), which evaluates interactivity and responsiveness; and Cumulative Layout Shift (CLS), which tracks visual stability. Each metric is classified against fixed thresholds as Good, Needs Improvement, or Poor, giving clear benchmarks for performance assessment.
Field data, collected from real users through the Chrome User Experience Report, differs from lab data generated in controlled testing environments. Google provides multiple tools to measure Core Web Vitals, including PageSpeed Insights, the Search Console Core Web Vitals report, the Chrome User Experience Report (CrUX), Lighthouse, and the Chrome DevTools Performance panel, while third-party monitoring platforms support continuous tracking across field and lab environments.
Core Web Vitals influence Google Search visibility as a page-experience ranking signal, acting as a tie-breaker rather than overriding content relevance. Beyond SEO, the metrics shape user experience, engagement, bounce rate, and conversion rates, which makes them matter for any site indexed by Google Search, above all high-traffic e-commerce platforms, media sites, and conversion-driven web properties. Within a technical-SEO program, Core Web Vitals complement crawlability, rendering efficiency, and indexing rather than operating as a standalone task.
Core Web Vitals issues should be prioritized by identifying the worst-performing metric, weighting URL groups by traffic volume, and applying fixes across LCP, CLS, and INP in a deliberate order. SEO agencies should audit Core Web Vitals during site migrations, major redesigns, traffic drops, algorithm updates, and new page-template launches. Common causes of poor scores include render-blocking CSS and JavaScript, large or unoptimized images, slow server response times and high Time to First Byte (TTFB), heavy third-party scripts, unsized page parts, and content injected late in the loading cycle. Those root causes trace back to particular website resources: images, fonts, CSS files, JavaScript execution, and third-party embeds.
Performance risks vary by website type: image-heavy e-commerce and media sites struggle with LCP and CLS, JavaScript-intensive single-page applications and SaaS platforms face INP challenges, while lighter content blogs hold better baseline scores. Monitoring combines real-user measurement through tools like the Search Console Core Web Vitals report with synthetic testing for pre-production validation, enabling continuous tracking and re-validation after each optimization. The monitoring loop returns to the definition of Core Web Vitals: standardized, real-user metrics that quantify the loading, interactivity, and visual stability experiences behind search visibility and user satisfaction.
What are Core Web Vitals?
Core Web Vitals are standardized real-world user-experience metrics developed by Google. Core Web Vitals form a subset of Web Vitals and act as a page-experience signal within Google's ranking algorithm, assessing three dimensions of web performance: loading speed, interactivity, and visual stability.
The three Core Web Vitals metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures loading performance, INP evaluates responsiveness, and CLS assesses visual stability. Each metric is rated Good, Needs Improvement, or Poor against fixed thresholds, and how the ratings get measured in practice follows below.
How do Core Web Vitals work?
Core Web Vitals work by measuring real-world page experience through metrics that assess loading performance, interactivity, and visual stability. The metrics are evaluated with field data collected from actual user interactions across a range of devices and network conditions, so Core Web Vitals reflect the performance most users encounter rather than a synthetic best case.
The evaluation runs on the Chrome User Experience Report (CrUX), which aggregates data over a 28-day rolling window to smooth out temporary anomalies. Google assesses the metrics at the 75th percentile, meaning 75% of user visits must meet the thresholds for a page to earn a "Good" rating, a standard that reflects consistent experience rather than isolated best-case loads. Core Web Vitals feed Google's page-experience signals, shaping how Google evaluates and ranks webpages on the strength of their user experience.
How does Core Web Vitals field assessment work?
Core Web Vitals field assessment works on real-user data collected through the Chrome User Experience Report (CrUX). The data aggregates over a 28-day rolling window, so metrics reflect the most recent four weeks of user visits. The assessment applies the 75th percentile: 75% of real user visits must meet the "Good" threshold for each metric, from Largest Contentful Paint (LCP) to Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS), per Google's "Web Vitals" documentation on web.dev, which defines a passing page as one meeting the targets at the 75th percentile of page loads.
A URL group's status follows its worst-performing metric: if any one of the three metrics lands in "Needs Improvement" or "Poor" at the 75th percentile, the whole page fails the Core Web Vitals assessment. Google's tools, from PageSpeed Insights to the CrUX-based views in Search Console, expose the field data so site owners can monitor and improve performance, and the rolling window keeps assessments responsive to recent site changes.
What are the Core Web Vitals metrics?
The Core Web Vitals metrics are listed below:
- Largest Contentful Paint (LCP) measures loading performance by tracking the time until the largest visible element on the page renders. A good LCP score is under 2.5 seconds.
- Interaction to Next Paint (INP) evaluates page responsiveness by measuring the time between user interactions and the next visual update. A good INP score is less than 200 milliseconds.
- Cumulative Layout Shift (CLS) assesses visual stability by quantifying unexpected layout shifts during page load. A good CLS score is less than 0.1.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) measures the render time of the largest visible element on a webpage, such as a hero image, video, or text block, and stands as the loading-performance metric from the user's perspective. LCP falls into three performance bands: Good at 2.5 seconds or less, Needs Improvement from above 2.5 seconds to 4.0 seconds, and Poor beyond 4.0 seconds. Reaching a Good LCP score takes optimized server response times, fewer render-blocking resources, and efficient client-side rendering.
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) is the Core Web Vitals metric that gauges a webpage's responsiveness to user interactions throughout the page's lifecycle. INP replaced the First Input Delay (FID) metric on March 12, 2024, moving to a fuller measurement of interactivity, as announced in the web.dev post "Interaction to Next Paint becomes a Core Web Vital on March 12." INP evaluates how quickly a page responds and renders visual feedback after user actions such as clicks, taps, and key presses. A good INP score is less than 200 milliseconds, scores between 200 and 500 milliseconds need improvement, and scores above 500 milliseconds rate as poor. Long-running JavaScript tasks are the primary cause of poor INP scores, since they block the main thread and delay the next paint. Improving INP means breaking up long tasks, deferring secondary scripts, and keeping interactive controls responsive.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) measures the visual stability of a webpage by quantifying unexpected layout movements. Layout shifts occur when images, ads, or embeds load without specified dimensions and push content around mid-load. Common causes of poor CLS scores include unsized images, advertisements without reserved space, and late-loading web fonts that trigger text reflows. A good CLS score is 0.1 or lower, scores between 0.1 and 0.25 need improvement, and scores above 0.25 rate as poor. Improving CLS starts with reserving space for dynamic content before it loads, keeping the page stable and predictable.
How are Core Web Vitals ratings classified?
Core Web Vitals ratings are classified in a three-tier system: Good, Needs Improvement, and Poor. Each metric, from Largest Contentful Paint (LCP) to Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS), is scored against fixed thresholds. A page reaches "Good" status only when all three metrics meet the Good criteria at the 75th percentile of real-user data, meaning 75% of page loads must land in the Good range for every metric.
Any single metric falling into "Needs Improvement" or "Poor" fails the whole page. The all-or-nothing rule holds pages to a consistently positive experience across loading performance, interactivity, and visual stability, and the 75th-percentile benchmark keeps the assessment anchored to typical users rather than visitors with the fastest devices and connections.
What are the Core Web Vitals score thresholds?
The Core Web Vitals score thresholds classify a webpage's performance as Good, Needs Improvement, or Poor, and Google standardizes the values so every website is evaluated the same way. The thresholds for each metric are presented in the table below:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2.5 seconds | 2.5 - 4.0 seconds | > 4.0 seconds |
| Interaction to Next Paint (INP) | ≤ 200 milliseconds | 200 - 500 milliseconds | > 500 milliseconds |
| Cumulative Layout Shift (CLS) | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
A webpage passes Core Web Vitals when all three metrics rate Good at the 75th percentile of real-user visits, so at least 75% of page loads must meet the Good threshold for each metric. The threshold values come from the official documentation "Understanding Core Web Vitals and Google search results" published by Google Search Central.
How do field and lab Core Web Vitals data differ?
Field and lab Core Web Vitals data differ in how they are collected and used, as the table below outlines:
| Aspect | Field data | Lab data |
|---|---|---|
| Data source | Real users visiting the site, collected from actual user experiences | Simulated page load in a controlled environment with fixed device and network conditions |
| Collection method | Aggregated from anonymized real-world visits, reported at the 75th percentile over a rolling 28-day window | Collected from one or more test runs under predefined conditions to create repeatable results |
| Reporting tools | Google Search Console Core Web Vitals report, Chrome UX Report, and PageSpeed Insights field section | Lighthouse, Chrome DevTools Performance panel, and the lab section of PageSpeed Insights |
| Which metrics are measurable | The Core Web Vitals field set: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) | Lab tools measure LCP and CLS, but INP is not fully captured in synthetic conditions because it depends on real user interactions |
Field data captures how real users experience a page across devices and network conditions, while lab data suits debugging because its controlled, repeatable conditions isolate performance issues.
Why can field and lab Core Web Vitals results differ?
Field and lab Core Web Vitals results can differ because the two data sets come from different collection methods. Field data reflects real-world visits across devices, network conditions, and locations, aggregated over 28 days at the 75th percentile. Lab data simulates a single page load under controlled conditions with a fixed device profile and network settings, which buys reproducibility at the cost of the variability real traffic carries.
Two metrics show the gap most sharply. Interaction to Next Paint (INP) measures responsiveness across all interactions in a session, which lab tests rarely capture in full. Cumulative Layout Shift (CLS) accumulates layout shifts through the whole page lifecycle, including shifts from dynamic content that never fire in a lab run. A page can pass lab tests yet fail the field assessment, or the reverse.
Which tools measure Core Web Vitals?
The tools that measure Core Web Vitals are listed below:
- PageSpeed Insights: combines field data from the Chrome User Experience Report with lab diagnostics from Lighthouse, delivering real-world performance scores and improvement recommendations.
- Google Search Console Core Web Vitals report: provides URL-level field data aggregated across entire sites, highlighting which metrics are failing.
- Chrome User Experience Report (CrUX): Google's public dataset of real-user field measurements collected from Chrome browsers, used for origin-level and URL-level analysis.
- Lighthouse: an open-source, automated lab testing tool that simulates page loads under controlled conditions to measure performance, accessibility, and best practices.
- Chrome DevTools Performance panel: records and analyzes runtime performance in detail, capturing rendering, JavaScript execution, layout shifts, and interaction delays.
- Web Vitals extension / web-vitals library: measure Core Web Vitals directly in the browser or feed analytics platforms for continuous field tracking.
- WebPageTest: a third-party lab testing platform for advanced waterfall analysis, repeatable synthetic tests, and performance troubleshooting.
- GTmetrix: combines lab-style testing with diagnostics for Core Web Vitals bottlenecks.
- DebugBear: a monitoring and testing platform pairing real-user data with custom lab tests for ongoing analysis.
- RUMvision, Treo, Lumar, Oncrawl, and Semrush: third-party platforms that track Core Web Vitals at scale, combining real-user monitoring and synthetic data.
Which Google tools report Core Web Vitals?
The Google tools that report Core Web Vitals are listed below:
- PageSpeed Insights: combines field data from the Chrome User Experience Report (CrUX) with lab diagnostics from Lighthouse for a full view of real-world page performance.
- Search Console Core Web Vitals report: aggregates field data across URL groups, categorizing pages as Good, Needs Improvement, or Poor from the 28-day rolling CrUX dataset.
- Chrome User Experience Report (CrUX): a public dataset of real Chrome user metrics, available through BigQuery, the CrUX API, and the CrUX Dashboard.
- Lighthouse: an open-source automated tool integrated into Chrome DevTools, delivering lab measurements and actionable recommendations.
- Chrome DevTools Performance panel: lets developers debug runtime behavior by recording frame-by-frame rendering, JavaScript execution, and layout shifts during live or throttled sessions.
Why do Core Web Vitals matter?
Core Web Vitals matter because they serve as a page-experience ranking signal in Google Search and as a driver of user engagement outcomes. The metrics shape how users perceive a website's loading speed, interactivity, and visual stability: poor scores mean slow-loading content, unresponsive interactions, and unexpected layout shifts, which raise bounce rates and depress conversion rates. The business stakes are measured: the Google-commissioned Deloitte study "Milliseconds Make Millions" found that a 0.1-second improvement in mobile site speed raised retail conversions by 8.4% and average order value by 9.2%. Strong Core Web Vitals scores support search rankings, reduce cart abandonment, and lift conversion rates, tying page performance directly to business results. Optimizing Core Web Vitals keeps a site competitive as Google keeps weighting user-centric web experiences, and the payoff shows up in engagement and conversions as much as in rankings.
How do Core Web Vitals affect Google Search visibility?
Core Web Vitals affect Google Search visibility by acting as a page-experience signal within Google's ranking algorithm, serving as a tie-breaker when relevance and quality are otherwise equal between competing pages. Core Web Vitals grant a competitive edge without overriding the primary ranking criteria of content relevance and quality; Google Search Central's guidance notes the metrics "align with what our core ranking systems seek to reward." The effect shows most in competitive search environments, where superior loading performance, interactivity, and visual stability decide which of two comparable pages ranks higher. Site owners should treat Core Web Vitals optimization as one component of a complete SEO strategy that balances technical performance with content quality and relevance.
Who needs Core Web Vitals?
Any site appearing in Google Search needs Core Web Vitals, since the metrics feed page-experience signals and shape search visibility. The stakeholders who need them most are listed below:
- Site owners and publishers: Core Web Vitals support search performance and user experience, keeping visibility competitive in search results.
- SEO teams: Core Web Vitals drive technical SEO prioritization, keeping indexed pages within performance benchmarks.
- Developers: the metrics pinpoint loading, interaction, and layout issues that affect real-user experiences.
- Product teams: the metrics guard key user flows, from landing pages and product detail pages to signup flows and checkout.
- E-commerce sites: large images, ad-like widgets, and layout shifts drag on performance and conversion, making optimization a revenue matter.
- Media and news sites: image-heavy content and late-loading page parts strain loading speed and stability.
- SaaS and app-like sites: JavaScript-heavy interfaces run into responsiveness problems, making Interaction to Next Paint (INP) the metric to watch.
- High-traffic sites: small performance gains multiply across many users and indexed URLs.
- Conversion-driven sites: strong Core Web Vitals support rankings, engagement, and conversion rates at once.
Monitoring must continue whenever site templates, third-party scripts, media assets, or front-end frameworks change, because the metrics track the real-user performance of the pages as they exist today.
How do Core Web Vitals support technical SEO?
Core Web Vitals support technical SEO by slotting into the broader technical-SEO framework alongside crawlability, rendering, and indexing, making user experience part of site health rather than a separate task. A technically sound website must be discoverable and correctly rendered, and it must meet Core Web Vitals thresholds for loading, interactivity, and visual stability.
Positioning Core Web Vitals within technical SEO multiplies the impact of other optimization work. Improving server response time helps Time to First Byte (TTFB) and Largest Contentful Paint (LCP) together, while optimizing JavaScript execution lifts Interaction to Next Paint (INP) and supports proper rendering. Resource optimization, including compression and efficient caching, improves page-experience signals and cuts server load during bot crawls.
Technical-SEO practitioners should treat Core Web Vitals as a continuous performance layer that validates and extends infrastructure improvements. Monitoring through tools like Google Search Console, combined with audits covering mobile-friendliness and structured data, keeps page-experience signals reinforcing content relevance and authority. Folding Core Web Vitals into routine technical-SEO workflows, from XML sitemap maintenance to robots.txt optimization, builds a foundation where user experience and search visibility advance together.
How should Core Web Vitals issues be prioritized?
Core Web Vitals issues should be prioritized by finding the weakest metric, weighting pages by traffic, and fixing in a deliberate order. The steps are laid out below.
Identify the Worst-Performing Metric Determine which of the three metrics, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), or Interaction to Next Paint (INP), performs worst. The weakest metric becomes the primary focus, since improving it moves page performance the most.
Weight URL Groups by Traffic Volume Fix the URL groups with the highest traffic first. High-traffic pages carry the greatest user-experience and SEO impact, so improvements there reach the largest number of users.
Apply a Deliberate Fix Order Across Metrics With the weakest metric and highest-traffic pages identified, work through a systematic fix order: start with LCP improvements such as faster server responses and compressed images, then address CLS by adding size attributes to images and reserving space for ads, and close with INP by trimming JavaScript execution time and optimizing event handlers. A fixed order keeps improvements in one area from creating regressions in another.
When should an SEO agency audit Core Web Vitals?
As an SEO agency, we audit Core Web Vitals in the situations listed below:
- Initial client onboarding: a baseline Core Web Vitals reading surfaces existing issues and sets our technical SEO priorities from day one.
- After major redesigns or migrations: architecture changes can degrade loading, interactivity, and stability, and our audit catches regressions before they hit rankings.
- When Google Search Console flags issues: alerts for URL groups falling into "Needs Improvement" or "Poor" call for our immediate diagnosis and remediation.
- Following traffic or conversion drops: unexplained declines in organic visibility, engagement, or conversions can trace back to Core Web Vitals degradation, so we re-measure first.
- Before high-traffic periods: we audit e-commerce sites and media publishers ahead of peak seasons so infrastructure holds under load.
- After implementing new third-party scripts: fresh analytics, ads, or embed scripts introduce render-blocking requests and interaction delays, and we re-measure after each one.
- On a quarterly or bi-annual schedule: our periodic full audits catch emerging patterns, validate ongoing improvements, and keep scores aligned with evolving thresholds and user expectations.
What commonly causes poor Core Web Vitals?
Poor Core Web Vitals scores commonly come from the technical causes listed below:
- Render-blocking CSS and JavaScript: stylesheets and scripts that block rendering delay the page, dragging down Largest Contentful Paint (LCP) and Interaction to Next Paint (INP).
- Large or unoptimized images: oversized or uncompressed images slow loading and depress LCP.
- Slow server response and Time to First Byte (TTFB): a delayed server response pushes back all content loading, hurting LCP.
- Heavy third-party scripts: analytics, ad, and social scripts add network requests and main-thread work, hitting LCP, INP, and Cumulative Layout Shift (CLS).
- Unsized page parts: images and ads without defined dimensions shift the layout and damage CLS.
- Late-injected content: content loading after the initial render disturbs the layout and adds CLS.
Each root cause traces back to a particular website resource, from images and fonts to CSS, JavaScript, and third-party embeds, which is where the fixes live.
Which website resources affect Core Web Vitals?
The website resources that affect Core Web Vitals are listed below:
- Images: large or unoptimized images slow loading and shift layouts; the fixes are modern formats, explicit dimensions, and lazy-loading.
- Fonts: late-loading web fonts trigger text reflow and hurt Cumulative Layout Shift (CLS); preloading and optimizing font files contains the damage.
- CSS: render-blocking stylesheets delay content display; trimming them improves Largest Contentful Paint (LCP) and CLS.
- JavaScript: long tasks and render-blocking scripts degrade Interaction to Next Paint (INP) and LCP; splitting tasks and deferring secondary scripts restores responsiveness.
- Third-party embeds: widgets and ads introduce delays and layout shifts; managing external scripts and dynamically injected content keeps scores stable.
Of the five resource classes, images carry the most weight, and how they shape the metrics comes next.
How do images affect Core Web Vitals?
Images affect Core Web Vitals through Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) above all, and image optimization runs through the practices listed below:
- Format: modern image formats like WebP and AVIF cut file sizes while holding quality, speeding up loading.
- Compression: right-sized compression shrinks images without visible quality loss, improving LCP.
- Explicit dimensions: width and height attributes in the HTML reserve layout space, preventing shifts and protecting CLS.
- Lazy-loading: deferring below-the-fold images conserves bandwidth and prioritizes the content users see first.
- Preloading LCP images: preloading key images such as hero banners lets the browser fetch them ahead of the render, sharpening the LCP metric.
An image pipeline built on those practices removes the most common performance drag and keeps the visual experience stable.
How do Core Web Vitals vary by website type?
Core Web Vitals risks vary by website type because content and interaction demands differ. The main patterns are laid out below.
Image-heavy E-commerce and Media Sites Image-heavy e-commerce and media sites struggle with Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). Product galleries, hero banners, and dynamic ads slow loading and shift layouts, so sizing and loading images efficiently decides their scores.
JavaScript-heavy Single Page Applications (SPAs) and SaaS Apps JavaScript-heavy SPAs and SaaS platforms run into Interaction to Next Paint (INP) trouble. Client-side rendering delays responsiveness when JavaScript execution goes unoptimized, so trimming long tasks and tuning script execution matters most for them.
Content-focused Blogs and Editorial Sites Content-focused blogs and editorial sites, with simpler layouts and fewer scripts, reach good scores across the metrics more easily, though image optimization and third-party embeds still need watching to prevent layout shifts and loading delays.
A site that knows its type knows which metric will fail first, which is where optimization should start.
How should Core Web Vitals be monitored?
Core Web Vitals should be monitored through a combination of real-user monitoring and synthetic testing. Real-user monitoring (RUM) collects field data from actual visitors via the Chrome User Experience Report (CrUX), capturing genuine conditions across devices and networks. Synthetic testing runs controlled lab checks with tools like Lighthouse to diagnose issues under repeatable conditions. Together the two views give a complete picture of page performance and point optimizations at the right targets.
Continuous tracking through the Search Console Core Web Vitals report keeps a site's performance visible over time. The report aggregates field data over a 28-day rolling window and highlights URL groups missing the Good thresholds at the 75th percentile, letting site owners prioritize fixes by real traffic impact. After each optimization, re-validation confirms the change delivered the expected gains in Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). The steady review loop matches what Core Web Vitals are: real-world page-experience metrics that hold a site to the standard search algorithms and visitors both expect.
