Core Web Vitals are three metrics that measure real-user experience for loading performance, interaction responsiveness and visual stability. The current metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. A page passes the Core Web Vitals assessment when all three metrics meet their recommended thresholds at the 75th percentile of eligible user experiences.
Check real-user LCP, INP and CLS with the Novaverb Core Web Vitals Checker. Use the PageSpeed Checker when you need a live Lighthouse test and technical diagnostics.
What Do Core Web Vitals Measure?
Core Web Vitals measure whether the main content appears promptly, whether interactions receive timely visual feedback and whether the layout remains visually stable. They focus on user-observable outcomes rather than assigning a general technical-quality score to the entire website.
Does the main visible content become available quickly enough for the visitor to understand that the page is useful?
When the visitor clicks, taps or types, does the interface provide the next visual update without a noticeable delay?
Do page elements remain in their expected positions instead of moving unexpectedly while the visitor is reading or acting?
The metrics do not directly measure every aspect of page experience. They do not determine whether the content is accurate, whether navigation is understandable, whether a form works correctly or whether the page satisfies search intent.
What Is Largest Contentful Paint?
Largest Contentful Paint measures the time from navigation until the largest eligible image, text block or video poster visible in the viewport finishes rendering. LCP is intended to represent when the page’s primary visible content becomes available to the user.
Common LCP elements
- Hero images
- Large headline or text blocks
- Poster images for video elements
- Background images loaded through CSS
- Large content images near the top of the page
Common LCP delays
- Slow server response or high TTFB
- Render-blocking CSS
- Late discovery of the hero image
- Oversized or poorly compressed images
- Client-side rendering delays
- Web-font loading that delays text rendering
The LCP element can differ between mobile and desktop layouts because viewport size, responsive images and page structure change which element is the largest visible candidate.
Use the Server Response Time Checker when TTFB appears to delay the loading chain. Then inspect the actual LCP element with PageSpeed Insights or Chrome DevTools.
What Is Interaction to Next Paint?
Interaction to Next Paint measures the latency of user interactions throughout the page visit and reports a representative value from the slowest interactions. It evaluates how long users wait for visual feedback after clicking, tapping or pressing a key.
The time between the user interaction and the browser beginning to run the associated event handlers.
The time required to execute event handlers and related JavaScript work.
The time the browser needs to render and display the next visual update.
Common causes of poor INP
- Long JavaScript tasks on the main thread
- Large client-side rendering updates
- Complex DOM structures
- Third-party scripts
- Heavy event handlers
- Excessive synchronous work
Typical improvement directions
- Break long tasks into smaller work units
- Reduce unnecessary JavaScript execution
- Delay nonessential third-party scripts
- Optimize rendering updates
- Reduce DOM and component complexity
- Provide immediate visual feedback where appropriate
What Is Cumulative Layout Shift?
Cumulative Layout Shift measures the largest burst of unexpected layout movement during a page visit. A layout shift occurs when a visible element changes position between rendered frames without being caused by a recent user interaction.
Common causes of CLS
- Images without reserved dimensions
- Ads or embeds inserted without allocated space
- Cookie banners pushing content downward
- Late-loading web fonts
- Dynamically inserted content above existing content
- Animations that change layout properties
Typical improvement directions
- Set width and height or aspect ratio for media
- Reserve stable slots for ads and embeds
- Use overlays carefully instead of pushing content
- Preload critical fonts and use suitable fallbacks
- Insert new content below the current viewport
- Animate transforms instead of layout-changing properties
CLS is unitless. It is calculated from the affected viewport area and the distance that unstable elements move. A shift that causes a visitor to click the wrong button can be harmful even when the page loads quickly.
What Are the Core Web Vitals Thresholds?
A page has good Core Web Vitals when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less at the 75th percentile. The assessment is performed separately for mobile and desktop user experiences.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | Above 2.5 and up to 4 seconds | Above 4 seconds |
| INP | 200 milliseconds or less | Above 200 and up to 500 milliseconds | Above 500 milliseconds |
| CLS | 0.1 or less | Above 0.1 and up to 0.25 | Above 0.25 |
Why Does Google Use the 75th Percentile?
The 75th percentile represents the experience at which 75% of measured page visits performed at least as well and 25% performed worse. This prevents a fast average from concealing a meaningful group of visitors who experience slow loading, delayed interactions or unstable layouts.
The fastest quarter of measured visits.
Faster-than-median user experiences.
The range approaching the assessment point.
The slowest quarter of measured experiences.
Suppose 75% of eligible mobile visits record an LCP of 2.4 seconds or less. The mobile LCP can be classified as good. If the 75th-percentile value is 3.1 seconds, the page needs improvement even when many faster users see the content sooner.
What Is the Difference Between Field Data and Lab Data?
Field data measures experiences from real visitors, while lab data measures a controlled page load in a simulated or specified environment. Field data determines the public Core Web Vitals assessment; lab data helps reproduce and diagnose technical causes.
| Dimension | Field data | Lab data |
|---|---|---|
| Source | Real visitor experiences from supported browsers or first-party monitoring. | A controlled test performed by Lighthouse, DevTools or another testing environment. |
| Devices and networks | Includes the real variation experienced by eligible users. | Uses the device, network and throttling conditions selected by the test. |
| Time period | Public CrUX reporting commonly represents a rolling 28-day period. | Represents the test performed at that moment. |
| Interaction coverage | Can measure real interaction latency throughout visits. | A default Lighthouse load may not reproduce real INP interactions. |
| Best use | Determine whether real users pass or fail. | Reproduce problems and identify technical causes. |
| Main limitation | May have insufficient data for low-traffic URLs. | One run cannot represent every real user. |
Run the Core Web Vitals Checker for available Chrome field data, then use the PageSpeed Checker for a live laboratory audit.
Why Can PageSpeed Insights Show Different Results?
PageSpeed Insights can show different field and laboratory results because the two datasets measure different users, time periods and conditions. A page can pass real-user Core Web Vitals while one simulated test is slow, or fail field data even when a laboratory run appears fast.
Visitors use different processors, memory levels, operating systems and browser states.
Real users may connect through slow mobile networks, distant regions or unstable connections.
Some visitors receive cached resources while others experience a cold load.
Consent tools, ads, experiments, logins and recommendations can change the rendered page.
Field data can still reflect visits that occurred before a recent deployment.
Laboratory results can change with server load, third-party services and network conditions.
How Do Core Web Vitals Affect SEO?
Google uses Core Web Vitals within its ranking systems, but the metrics are only one part of overall page experience and do not override relevance or content quality. Passing Core Web Vitals can support a better experience, but it does not guarantee crawling, indexing, traffic or top rankings.
What good Core Web Vitals can support
- Faster access to primary content
- More responsive forms and interfaces
- Fewer accidental clicks caused by movement
- More usable mobile experiences
- Page-experience signals aligned with Google’s guidance
What they cannot prove
- That the content satisfies search intent
- That Google will index the page
- That rankings will increase after a fix
- That users will convert
- That every page on the domain performs equally
Google explains that there is no single page-experience signal and that strong report scores do not guarantee top rankings. Review the official page-experience guidance.
Are Core Web Vitals Evaluated Per Page or Per Website?
Core Web Vitals data can be reported for an individual URL, a group of similar URLs or an entire origin, depending on the tool and available traffic. A fast homepage does not prove that product, article or checkout templates provide the same experience.
Represents eligible experiences associated with one specific page URL when sufficient data exists.
Combines eligible experiences across an origin and may be used when URL-level data is unavailable.
Search Console groups pages with similar experience patterns to make sitewide problems easier to manage.
Always check the reporting scope shown by the tool. An origin-level result can hide a slow template, while one problematic URL should not automatically be reported as proof that every page on the domain fails.
Why Is Core Web Vitals Data Sometimes Unavailable?
Public Core Web Vitals data may be unavailable when a URL or origin does not have enough eligible Chrome user experiences in the reporting period. Missing data is not a passing score, a failing score or proof that no users visited the page.
The URL may not receive enough eligible visits for reliable public reporting.
The public dataset may not yet contain a sufficient rolling history.
A page may lack enough qualifying user interactions to report INP.
URL-level data may be unavailable even when origin-level data exists.
Not every browser visit contributes to the public Chrome User Experience Report.
Public reporting applies eligibility and privacy thresholds before exposing aggregated results.
How Should You Diagnose Core Web Vitals Problems?
Diagnose Core Web Vitals by starting with the failing field metric, identifying the affected template or user segment and locating the specific element or interaction responsible. Do not begin by applying a generic performance checklist to every page.
- Confirm the reporting scope. Record whether the result represents a URL, origin, mobile segment, desktop segment or Search Console URL group.
- Identify the failing metric. Separate LCP, INP and CLS rather than treating them as one speed problem.
- Inspect the distribution. Review the 75th-percentile value and the proportion of visits classified as good, needs improvement or poor.
- Find the affected template. Determine whether the issue belongs to the homepage, article, product, category, checkout or application interface.
- Locate the diagnostic target. Identify the LCP element, slow interaction or layout-shift source.
- Form one hypothesis. State which implementation condition causes the observed metric and what change should improve it.
- Test the change. Use laboratory tools, development environments and functional QA before deployment.
- Measure real users again. Confirm that field data improves after sufficient new visits enter the reporting window.
Which Core Web Vital Should You Fix First?
Fix the metric with the largest verified user impact, widest template coverage and clearest implementation cause. A severe INP failure on a checkout flow may deserve priority over a small LCP miss on a low-traffic article, even when both pages technically fail.
| Priority factor | Higher-priority evidence | Lower-priority evidence |
|---|---|---|
| User impact | Visitors cannot see, interact with or reliably use the main task. | The metric narrowly misses the threshold with no observed functional harm. |
| Traffic and business role | The issue affects major landing, product, lead or checkout templates. | The issue affects a rarely visited utility page. |
| Template coverage | One shared component affects hundreds or thousands of URLs. | The cause is isolated to one low-value page. |
| Severity | The 75th-percentile result is well inside the poor range. | The value is close to the good threshold. |
| Fix confidence | The responsible element, script or layout shift is identified. | The proposed fix is speculative and may remove useful functionality. |
| Regression risk | The change is testable with clear functional guardrails. | The change could damage accessibility, tracking or conversion flows. |
Common Core Web Vitals Myths
Core Web Vitals are frequently misinterpreted as a universal speed score, a direct ranking formula or a guarantee of better traffic. These assumptions can cause teams to optimize the wrong data or remove useful page features.
Frequently Asked Questions About Core Web Vitals
What are Core Web Vitals?
What is a good LCP score?
What is a good INP score?
What is a good CLS score?
Are Core Web Vitals a Google ranking factor?
Is PageSpeed score the same as Core Web Vitals?
Is TTFB a Core Web Vital?
Why is INP missing from my report?
Why does mobile fail while desktop passes?
How long does it take for Core Web Vitals data to update?
Should I remove scripts to improve Core Web Vitals?
How can I check Core Web Vitals for free?
Measure LCP, INP and CLS With Real Evidence
Begin with the data source that answers your question. Use real-user field data to determine whether visitors pass Core Web Vitals. Use a live Lighthouse test and browser diagnostics to identify the loading chain, JavaScript task or unstable element that should be fixed.
Do not report one PageSpeed score as proof of every user’s experience. Preserve the tested URL, data scope, device segment, metric values, test date and diagnostic evidence before prioritizing development work.
Novaverb keeps field data, laboratory tests and diagnostic metrics separate so teams can distinguish real-user outcomes from simulated evidence and implementation hypotheses.