Core Web Vitals report

The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data). 

OPEN REPORT

Understand the report

The Core Web Vitals report shows URL performance grouped by status (Poor, Need improvement, Good), metric type (CLS, INP, and LCP), and URL group (groups of similar web pages).

The report is based on three metrics as measured by actual user data: LCP, INP, and CLS. Once a URL group has a threshold amount of data for both LCP and CLS, the URL group's status is its most poorly performing metric. So, for example, if a URL group has poor CLS but good INP, the URL status is "poor."

If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report.

Only indexed URLs can appear in this report. Data is assigned to the actual URL, not the canonical URL, as it is in most other reports).

Remember that data is combined for all requests from all locations. If you have a substantial amount of traffic from a country with, say, slow internet connections, then your performance in general will go down. You can break down your performance by country using BigQuery if you suspect this might be a cause for low performance.

Navigating the report

For each platform (mobile or desktop), the report shows a table of URLs that have Poor or Need improvement issues (Why URLs aren't considered good), and another table of URLs with all Good scores for LCP, INP, and CLS (View data about good URLs).

1. See a chart of general trends for all platforms on the landing page.
2. Drill down by platform (mobile or desktop) by clicking Open report next to one of the charts.
3. To see how URLs on your site perform, based on historical user data, toggle the Poor, Need improvement, or Good tabs on the performance chart.
4. View the list of performance issues in the Why URLs aren't considered good table. Each URL shown is a representative of a different URL group.
5. Click a URL in the Examples table of the issue details page to see more information about that URL group.

Report data sources

The data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.

Group status: Poor, Need improvement, Good

The labels Poor, Need improvement, and Good are applied to a URL group for that specific device type. A URL group without threshold data for both LCP and CLS will not be on the report (for example, if the URL only has threshold data for LCP but not CLS, it won't be shown).

The status for a URL group defaults to the slowest status assigned to it for that device type. For example, 

• A URL on mobile with Poor CLS but Need improvement LCP is labeled Poor on mobile.
• A URL on mobile with Need improvement LCP but Good CLS is labeled Need improvement on mobile.
• A URL with Good LCP, INP, and CLS on mobile and Need improvement LCP, INP, and CLS on desktop is Good on mobile and Need improvement on desktop.

Status definitions

Here are the performance ranges for each status:

• LCP (largest contentful paint): The amount of time to render the largest content element visible in the viewport, from when the user requests the URL. The largest element is typically an image or video, or perhaps a large block-level text element. This metric is important because it indicates how quickly a visitor sees that the URL is actually loading.
  • Group LCP shown in the report is the time it takes for 75% of the visits to a URL in the group to reach the LCP state.
• INP (interaction to next paint): A metric that assesses a page's overall responsiveness to user interactions by observing the time that it takes for the page to respond to all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers. 
  • Group INP shown in the report means that 75% of visits to a URL in this group had this value or better.
• CLS (Cumulative Layout Shift): CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. The score is zero to any positive number, where zero means no shifting and the larger the number, the more layout shift on the page. This is important because having pages elements shift while a user is trying to interact with it is a bad user experience. If you can't seem to find the reason for a high value, try interacting with the page to see how that affects the score.
  • Group CLS shown in the report is the lowest common CLS for 75% of visits to a URL in the group.

You can find recommendations on fixing these issues by running an external test.

URL groups

URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown. It is assumed that these groups have a common framework and the reasons for any poor behavior of the group will likely be caused by the same underlying reasons.

In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn't have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report. This origin group contains data for all URLs in the same protocol://host:port group. For example, if the URL https://m.example.com/a/b/c.html is part of a group that doesn't have enough data to show, then Search Console will create the origin group https://m.example.com. This origin group contains data for all URLs under https://m.example.com, whether or not the URL also belongs to a group with sufficient data.

A few notes:

• The origin group definition includes the protocol; thus http://m.il.example.com and https://m.il.example.com are separate origin groups.
• The origin group contains data for all URLs below that origin, whether or not a URL is part of another group shown in the report.
• If the origin group doesn't have enough data, then it won't be shown (and, by extension, the site won't have enough data to show in this report, unless there are multiple origin groups).
• You can view data for the origin group whether or not the group is within the current property. However you can view only example URLs that are within the current property.
• Search Console lists group members ordered by impressions, in descending order.

Fix issues

My site status changed, but I didn't change anything

If you didn't make any changes in your site, but you see a big change in status for a lot of pages, it's possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge: for example, your site traffic dramatically increased or the service that serves your image files experienced a latency change, either of which could slow your site down. A small, but site-wide, change might have been just enough to push a bunch of borderline Good pages into the Need improvement category, or from Need improvement to Poor.

Another possible, though less likely, reason is a large-scale change in clients. For example, a widely-adopted browser version update, or an influx of users over a slower network. Remember that performance is measured by actual usage data. You can check your logs to see if any browser, device, or location changes coincide with site status changes.

Check your site traffic data during this period for any big swings, and also drill down into specific issues and look at the group LCP/INP/CLS numbers for affected pages. If these numbers are just at the border for Poor/Need improvement/Good, it's possible that a small change has nudged them into a new status.

Validate fixes

When you've fixed a specific issue in all of your URLs, you can confirm whether you fixed the issue for all URLs. Click Start Tracking to start a 28-day monitoring session to check for instances of this issue in your site. If this issue is not present in any URLs on your site during the 28-day window, the issue is considered fixed. The presence of that issue in any URL is enough to mark the issue as not fixed; however the status of individual URLs continue to be evaluated for the entire 28 days, regardless of issue status.

• To see the validation details for an in-progress validation request or for a request that has failed:
  • Click See details in the validation status section of the issue details page.
• To restart the validation tracking period at any time:
  • Open the validation details page and click Start new validation.
• If validation fails:
  1. Try again to fix your issues.
  2. Restart the tracking period by opening the validation details page, and clicking Start new validation.

Issue validation status

This is the status of the entire validation request, shown for each issue on the summary page, as well as the issue details page.

The following validation statuses are possible:

• Not started: There are one or more URLs with an instance of this issue that have never been in a validation request.
• Started: You have begun a validation attempt and no remaining instances of the issue have been found yet.
• Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed.
• Passed: All URLs are in Passed state. You must have clicked Validate fix to get to this state (if instances disappeared without you requesting validation, state would change to N/A)
• N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt.
• Failed: One or more URLs are in Failed state after a validation attempt.

URL validation status

This is the validation status of each URL in the validation progress page. Pending/Passed/Failed are visible during an active validation period; Failed is the only status visible once the period has ended (fixed items are removed from the list after the period has ended).

• Pending: Google is awaiting enough data to determine whether or not this URL is still affected.
• Passed: The URL seems not to be affected by this issue any more.
• Failed: The URL is still affected by the listed issue.

The Passed and Failed URL statuses can be reached only during a validation tracking period. If the issue appeared and then vanished for a URL outside of a validation request, the URL would simply vanish from the list without a status.

Any URLs that have been removed from the web and have no data in the last 28 days will no longer appear in the validation history or the report.