The Core Web Vitals report in Search Console summarizes real-user loading, responsiveness, and visual-stability data for groups of similar indexed URLs.
It is a site-level prioritization report built from the Chrome User Experience Report (CrUX). It is not a live speed test, complete URL inventory, JavaScript profiler, or guarantee of Search ranking improvement.
The current Core Web Vitals are:
- Largest Contentful Paint (LCP) for loading performance.
- Interaction to Next Paint (INP) for responsiveness.
- Cumulative Layout Shift (CLS) for visual stability.
This guide reflects Google's documentation on July 18, 2026.
Current thresholds
Google evaluates whether a page or group meets the target at the 75th percentile, separately for mobile and desktop.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s |
> 2.5 s and ≤ 4 s |
> 4 s |
| INP | ≤ 200 ms |
> 200 ms and ≤ 500 ms |
> 500 ms |
| CLS | ≤ 0.1 |
> 0.1 and ≤ 0.25 |
> 0.25 |
A group is Good only when every reported metric is Good for that device type. Its overall status is the status of its worst metric.
For example, a mobile group with Good LCP, Good INP, and Poor CLS is classified as Poor on mobile.
What each metric represents
Largest Contentful Paint
LCP measures when the largest image, video poster, or text block visible in the initial viewport finishes rendering relative to navigation start.
It answers:
How quickly does the page appear to deliver its main visible content?
Common contributors include:
- Slow server response and redirects.
- Render-blocking CSS.
- Late-discovered hero images or fonts.
- Oversized or poorly delivered images.
- Client-side rendering that delays the main content.
- Competing network requests.
The LCP element can differ by viewport, page state, and user. Do not assume the desktop hero element is also the mobile LCP element.
Interaction to Next Paint
INP evaluates responsiveness by observing click, tap, and keyboard interactions throughout a page visit. It reflects the longest representative interaction latency while excluding outliers according to the metric definition.
An interaction includes:
- Input delay while the main thread is busy.
- Event-handler processing.
- The rendering delay until the next frame is presented.
Common contributors include:
- Long JavaScript tasks.
- Heavy event handlers.
- Large DOM updates.
- Excessive synchronous work.
- Third-party scripts competing for the main thread.
- Hydration or rendering work triggered by interaction.
A page can load quickly and still have poor INP after the user opens a menu, types in a field, or interacts with a complex component.
Cumulative Layout Shift
CLS measures unexpected movement of visible content over the page's lifespan using layout-shift session windows.
Common contributors include:
- Images, ads, embeds, and iframes without reserved dimensions.
- Banners inserted above existing content.
- Font swaps that change text geometry.
- Components that expand without reserved space.
- Animations that change layout-affecting properties.
Expected movement caused promptly by a user interaction is treated differently from unexpected instability. Reproduce real page states rather than judging CLS from a static screenshot.
The 75th percentile is not an average
At the 75th percentile, 75% of measured experiences were at or better than the reported value and 25% were worse.
If mobile LCP is 2.6 seconds at the 75th percentile, the group is not Good even if its average LCP is much faster. The threshold is designed to cover most visits, including less capable devices and networks.
Do not report:
- “75% of users failed” when the 75th-percentile value misses the target.
- The field value as the experience of every user.
- A mean from internal telemetry as equivalent to CrUX's percentile.
Preserve the aggregation method whenever comparing sources.
The report uses real-user field data
Search Console receives anonymized field measurements from CrUX. These reflect eligible Chrome users, actual devices, networks, page states, and geographic mixes.
Field data differs from a controlled lab run:
| Field data | Lab data |
|---|---|
| Historical real-user experiences | One or more synthetic runs |
| Mixed devices and networks | Chosen test device and throttling |
| Captures real interactions for INP | Often provides a proxy or no real INP |
| Useful for status and trend | Useful for diagnosis and iteration |
| Changes as the user population changes | Changes with test configuration and page implementation |
Use the Search Console report to identify affected groups and business scope. Use PageSpeed Insights, Chrome DevTools, Lighthouse, and real-user monitoring to reproduce and diagnose causes.
A fast lab run does not invalidate poor field data. Poor field data does not prove every current lab run will be slow.
The data window is historical
The group values in Search Console summarize the preceding 28 days of CrUX experience data.
That rolling window means:
- A production fix is not reflected immediately.
- Old experiences remain in the window until they age out.
- New traffic gradually contributes to the distribution.
- A status can change without a deployment if the user, device, network, or geographic mix changes.
- A short outage or third-party regression can influence the window after the incident is over.
Use lab tools and real-user monitoring for immediate release verification. Use Search Console to confirm that the population-level field result improves over time.
Report scope and omissions
Only indexed URLs can appear in the report, but the report is not a complete list of indexed URLs.
A URL or property can be absent because:
- It lacks enough CrUX data for the selected device type.
- Its group lacks the minimum reporting data.
- The URL is not indexed.
- The Search Console property is new and existing CrUX data is still being processed.
- The site's eligible traffic is too low.
Google states that a group without threshold data for both LCP and CLS is omitted. “No data available” does not mean Good, Poor, blocked, or unindexed.
Do not calculate sitewide pass rates by dividing displayed Good URLs by a CMS URL count. The numerator and denominator represent different populations.
Data is assigned to the actual URL
Unlike many Search Console performance reports, Core Web Vitals data is assigned to the actual visited URL, not consolidated onto Google's selected canonical.
This matters for:
- Redirecting URLs.
- Parameterized URLs.
- Alternate protocol or hostname variants.
- Duplicate pages.
- Campaign and application states represented in the URL.
The Core Web Vitals report includes parameters when distinguishing URLs. PageSpeed Insights strips parameter data and assigns results to the bare URL, so the two views can differ even before considering grouping.
Do not assume canonical Performance-report attribution explains the URL shown in Core Web Vitals.
URL groups are the unit of diagnosis
Search Console groups URLs that Google considers likely to provide similar experiences and share a common framework.
One example URL represents a group. The displayed LCP, INP, or CLS value describes the group's aggregated experience, not necessarily that example URL's individual field result.
This design helps find template-level problems:
- Product pages sharing the same gallery and recommendation widgets.
- Article pages sharing advertising and typography.
- Category pages sharing filters and grids.
- Application routes using the same JavaScript shell.
An example URL can be faster or slower than its group. Test several representative members, including high-traffic and edge-case pages, before deciding on the root cause.
Origin fallback groups
When a specific URL group lacks enough data, Search Console can create a higher-level origin group using the same protocol://host:port.
An origin group:
- Can contain data from every URL under that origin.
- Treats HTTP and HTTPS as different origins.
- Can contain data outside the current Search Console property scope.
- Shows example URLs only from within the current property.
- Is omitted if the origin also lacks enough data.
An origin-level result is broad evidence. Do not claim that one directory or template caused it without narrower field or diagnostic data.
Mobile and desktop are separate
Search Console reports mobile and desktop independently. A group can be Good on desktop and Poor on mobile.
Differences can come from:
- Device processing power.
- Viewport-specific markup or media.
- Mobile network conditions.
- Responsive image selection.
- Different navigation and interaction patterns.
- Mobile-only ads, banners, and components.
- Differences in the measured population.
Do not average mobile and desktop into a single score. Prioritize the population important to users and the business while addressing Poor issues in both.
Read the chart and table correctly
The chart counts each URL once under its worst status. The issue table counts every applicable status-and-metric issue.
A URL with Poor CLS and Needs improvement LCP:
- Is counted once as Poor in the chart.
- Can appear in both the Poor CLS row and the Needs improvement LCP row in the table.
Therefore table issue counts can exceed chart URL counts. This is expected, not a data error.
The issue-details table:
- Shows example URLs, not every affected URL.
- Limits the table to 200 rows.
- Associates each example with a larger similar-URL group.
- Orders group members by Search impressions.
- Shows the metric relevant to the selected issue.
Fix the shared cause across the group rather than patching only the visible examples.
A reliable report workflow
1. Separate mobile and desktop
Open each device report and record Good, Needs improvement, and Poor URL counts.
2. Prioritize Poor issues
Google recommends addressing Poor groups before Needs improvement groups. Within a status, balance:
- Number of affected URLs.
- Search impressions.
- Revenue or task importance.
- Severity and distance from the threshold.
- Whether one shared component affects many templates.
3. Open one status-and-metric issue
Record the device, metric, field value, URL count, validation state, and representative group URL.
4. Identify the template or origin scope
Inspect multiple group members. Determine whether they share layout, components, assets, rendering architecture, advertising, consent tooling, or third-party scripts.
5. Reproduce with diagnostic tools
Use PageSpeed Insights and DevTools on representative URLs under realistic device and network conditions. Add real-user monitoring when the site needs URL-, country-, release-, or component-level evidence that CrUX cannot provide directly.
6. Fix the shared cause
Prefer changes that improve the entire affected template or component. Verify that fixes do not regress other metrics or business behavior.
7. Validate immediately and historically
Use lab and real-user telemetry after deployment. When the full affected group is fixed, start Search Console tracking and monitor the 28-day validation window.
Diagnose by metric, not by generic “speed”
An LCP issue, INP issue, and CLS issue need different evidence.
For LCP
Identify the LCP element and break the time into server response, resource discovery, resource loading, and rendering delay. Check whether the element and bottleneck change between mobile, desktop, templates, and page states.
For INP
Identify slow interactions and divide latency into input delay, processing, and presentation delay. Inspect long tasks, event handlers, rendering work, and third-party contention across the visit—not only initial load.
For CLS
Record layout-shift entries and affected elements throughout the page lifecycle. Test delayed ads, fonts, consent interfaces, navigation, lazy content, and interactive states.
“Improve page speed” is not a sufficient engineering ticket. State the metric, population, template, evidence, and suspected mechanism.
Why status can change without a release
Core Web Vitals are population measurements over a rolling window. Status can move when:
- More users arrive on slower or faster devices.
- Traffic shifts between countries or networks.
- A browser version changes behavior.
- A CDN, image, font, ad, tag, or API changes.
- A group near a threshold moves slightly.
- Different URLs enter the measured group.
- The rolling window includes or removes an incident.
Compare CrUX trends, traffic mix, RUM, release history, infrastructure, and third-party monitoring before attributing the change to Search Console itself.
Core Web Vitals and rankings
Google says Core Web Vitals are used by its ranking systems, but there is no single page-experience signal and good scores do not guarantee top rankings.
Relevance remains central. A more relevant page can rank above a faster page. Page experience includes more than Core Web Vitals, and optimizing a number purely for SEO can be a poor use of resources when users experience other serious problems.
Use Core Web Vitals to improve real user experience and reduce performance-related disadvantage. Do not forecast a fixed ranking or traffic gain from crossing one threshold.
Validation is monitoring, not recrawling
After fixing an issue for all affected URLs, Start Tracking begins a 28-day Search Console monitoring session.
It does not:
- Trigger recrawling.
- Request indexing.
- Run Lighthouse.
- Generate new user traffic.
- Clear the issue immediately.
One remaining affected URL can cause issue validation to fail, although Search Console continues evaluating individual URLs through the monitoring period.
Validation states include Not started, Started, Looking good, Passed, N/A, and Failed. The dedicated validation guide explains how to interpret and troubleshoot each state.
Export and automation boundaries
The aggregate Core Web Vitals report is available in Search Console's interface and can be exported. Google does not provide a dedicated Search Console API for reproducing its URL groups and validation workflow.
Automation can use:
- CrUX API or History API for eligible URL and origin field data.
- CrUX BigQuery datasets for historical origin-level and segmented analysis.
- PageSpeed Insights API for field data when available plus lab diagnostics.
- The
web-vitalsJavaScript library for site-owned real-user monitoring. - Lighthouse and browser automation for controlled regression testing.
These sources do not recreate Search Console's exact group membership, example selection, or validation status.
When exporting Search Console, note that ~ or - values become zero in the downloaded data. Preserve the fact that the interface value meant unavailable or not a number; do not silently interpret the exported zero as a measured zero.
Common mistakes
- Treating the report as a live test.
- Calling its URL counts a complete indexed inventory.
- Treating “No data” as Good.
- Confusing a group value with the example URL's individual value.
- Ignoring origin fallback aggregation.
- Combining mobile and desktop.
- Using an average instead of the 75th percentile.
- Expecting canonical attribution as in Performance reports.
- Comparing parameterized Search Console URLs with stripped PageSpeed Insights URLs without adjustment.
- Adding table rows and expecting them to equal chart URLs.
- Fixing only the displayed examples.
- Declaring a fix failed before the rolling field window updates.
- Assuming Start Tracking triggers a recrawl.
- Promising a ranking increase from a Good status.
- Optimizing a lab score while real interactions remain slow or unstable.
Review checklist
- LCP, INP, and CLS thresholds are current.
- The 75th percentile is distinguished from an average.
- Mobile and desktop are separate.
- The 28-day field window is understood.
- Missing data is not assigned a performance status.
- Indexed coverage is not treated as comprehensive.
- Actual-URL attribution is distinguished from canonical attribution.
- URL groups and origin fallback groups are identified.
- Chart URL counts are distinguished from table issue counts.
- Multiple representative group members are tested.
- Field evidence selects the problem; lab and RUM evidence diagnose it.
- Poor groups are prioritized by user and business impact.
- Validation is started only after the full affected scope is fixed.
- Ranking claims remain qualified.
Related content
- CrUX vs PageSpeed Insights
- Validate a Core Web Vitals fix
- HTTPS report: complete guide
- Mobile vs desktop performance gaps
- GSC UI vs API vs BigQuery