In short and in plain language
Google shows a report on the speed of your website in Search Console. It is called the Core Web Vitals report. The values come from real visitors.
The report puts similar pages into groups. One group might be all pages with products. The list only shows one page as an example.
Behind a group there is usually a template. A template is the frame for many pages. A fix there helps all of these pages at once.
There are separate parts for phones and for computers. After a fix, you can start a check. Google then checks for four weeks. Only then is the result clear.
We help you read the report. We find the cause and improve the template.
For many site owners, the Core Web Vitals report is the first place where Google tells them their pages are too slow. It shows bars in three status colours, a table of issues and a handful of example URLs. If you read it as a list of individual pages, you will soon optimise in the wrong place: on the one address shown as an example instead of the template behind many similar pages. And if you click “Start Tracking” after a fix, you will often wait longer than expected and mistake the slow validation for failure. This article explains how the report groups URLs, which figure sits behind a group value, why mobile and desktop are reported separately, what “No data available” means and how to turn the report into a concrete work order for your team.
Key takeaways
- The report groups by status, metric and URL group. Per device type, a group takes the status of its worst metric: a poor CLS makes it “Poor” even when LCP and INP are good (Search Console Help).
- The group value is not an average: it states the value that 75 percent (Search Console Help) of page views over the last 28 days reached or beat. Individual outlier URLs can be better or worse.
- An example URL stands for a group of similar pages that most likely share a common framework. The template gets fixed, not the single address; group members are sorted by impressions.
- Mobile and desktop have separate reports with their own status. Mobile usually fares worse: 48 percent versus 56 percent of websites passed all three Core Web Vitals in 2025 (Web Almanac 2025).
- After “Start Tracking”, Search Console monitors for 28 days (Search Console Help) whether the issue still appears on any URL. A single affected URL is enough to make the validation fail.
- For the work order: first every issue with status “Poor”, then the groups with the most or most important URLs. In the export, unavailable values appear as zero – they are unmeasured, not good.
What the report shows and what it does not
The report relies on actual usage data, meaning measurements from real visitors rather than a test run. The data comes from the Chrome UX Report (CrUX), which collects anonymised metrics from Chrome users who visit your pages (Search Console Help). This leads to several properties worth knowing before you draw conclusions from a colour. Anyone who wants to judge the Core Web Vitals of their site needs all of them.
- Indexed URLs only: Only indexed addresses can appear in the report. Pages blocked by noindex or that do not respond successfully after redirects already drop out of CrUX, which applies the same criteria as search engines (Chrome for Developers).
- A sample: The report is not a complete list of all indexed URLs but a selection that helps you judge the performance of the site (Search Console Help).
- The address visited counts: Data is assigned to the actual URL, not the canonical one. The report takes URL parameters into account when telling pages apart, whereas PageSpeed Insights strips them (Search Console Help).
- All locations combined: Traffic from all countries is combined. Many visits from regions with slow connections pull the values down, even when your server responds quickly (Search Console Help).
- Not every browser counts: CrUX includes Chrome on desktop and Chrome on Android. Chrome on iOS, Android apps using WebView and other Chromium browsers do not contribute data (Chrome for Developers).
That makes the report an early warning system for patterns, not a measuring device for single pages. The help page says so itself: reporting the status of individual URLs is not the primary purpose of the report; it is meant to make the performance of the site as a whole transparent and to surface issues that affect several pages (Search Console Help). For a specific address, an external test such as PageSpeed Insights is the intended tool.
Why a careful look pays off: Google recommends that site owners achieve good Core Web Vitals for success in Google Search and for a good user experience in general (Google Search Central). Search Console, PageSpeed Insights and web.dev use the same thresholds: an LCP of up to 2.5 seconds, an INP of up to 200 milliseconds and a CLS of up to 0.1 count as good. The report translates these limits into three colours – and that translation contains the rules you need to know.
Scope
The group logic: status, metric, URL group
The report places every recorded address on three axes: by status (Poor, Need improvement, Good), by metric type (CLS, INP and LCP) and by URL group, meaning groups of similar pages (Search Console Help). Keep that in mind and every row of the overview table makes sense: it stands for a combination of status and issue, such as an LCP issue on mobile, and shows how many URLs currently fall into that combination.
The decisive rule is the one for group status. Per device type, a URL group is assigned its worst status (Search Console Help). If a group has a poor CLS on mobile and an LCP that needs improvement, it is labelled Poor on mobile. A group with good LCP and INP can therefore fail on layout shifts alone. To appear in the report at all, a group needs enough data for both LCP and CLS; if only one of the two metrics has enough data, it is not shown (Search Console Help).
| Metric | Good | Need improvement | Poor |
|---|---|---|---|
| LCP (loading) | up to 2.5 s | up to 4 s | over 4 s |
| INP (responsiveness) | up to 200 ms | up to 500 ms | over 500 ms |
| CLS (stability) | up to 0.1 | up to 0.25 | over 0.25 |
Besides the status, the details page shows a group value per group, such as “Group LCP”. It is not a mean. It states that 75 percent (Search Console Help) of page requests in the last 28 days reached at most this value. The 75th percentile is the usual yardstick: web.dev recommends measuring the thresholds at the 75th percentile (web.dev) of page loads, segmented across mobile and desktop. A quarter of visits may therefore be worse without the group losing its status. Conversely, it is not enough for half of the visits to be fast: if the group LCP sits just above 2.5 seconds, enough of the slower page views have to drop below the threshold that no more than a quarter remain above it. Speeding up the typical visit further does not achieve that.
A frequent source of confusion is the totals. The chart counts each URL only once, under its slowest issue; the table lists it in every row whose issue it has (Search Console Help). Row totals are therefore higher than the figure in the chart. The tabs above the chart also show the number of URLs, not the number of URL groups (Search Console Help). Many slow URLs can be a single group – and therefore a single problem.
FID is history
Example URL versus template
Click a row in the overview and the details page opens with a table of example URLs. Each row of this table stands for a group of similar URLs (Search Console Help), and the table holds at most 200 rows (Search Console Help). This is where the most expensive reading mistake happens: the example URL is taken for the sick page. A developer shrinks the image on exactly that product page, tests it in PageSpeed Insights, sees an improvement – and the group stays red because the other product pages share the same weakness.
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 plain terms: behind a URL group there is usually a template. In a shop these are the category page, product page, search results, cart and guides; on a company website the service page, location page and blog article. A large hero image that the template loads without priority, a review block loaded later without reserved height or a heavy filter script affects every page built on that template. The fix therefore belongs in the template, in the shared CSS or in the script every page of the group loads – which is the core of any frontend optimisation that is meant to show up in the report.
Clicking the example URL shows which pages belong to a group: Search Console lists further pages of the group, along with the values of the group members if they have enough data (Search Console Help). The members are sorted by impressions in descending order. The URLs listed first therefore have the greatest influence on the group status. If a group sits close to a threshold, however, a few URLs at the bottom of the list can tip the balance (Search Console Help).
- Open several members of the group and note which template in your system they are built on.
- Check whether all members use the same template. If a group mixes two templates, for instance product pages with and without variant selection, both belong in the investigation.
- Examine one typical page per template in the lab, with throttled network and throttled CPU, and look for the cause of the weak metric – for instance in a Lighthouse audit.
- Implement the fix in the template and verify it on several members of the group, not just on the example URL.
A word on PageSpeed Insights: the tool normally shows field data for the individual URL. That figure can differ from the group result, because individual URLs can be outliers within their group (Search Console Help). If the single page has too little data, PageSpeed Insights falls back to the origin, meaning all visits to all pages of the site (PageSpeed Insights documentation). If you see a good figure for an example URL and still find the group in red, you are not measuring wrongly – you are measuring something else.
Smaller sites often see a special row: the origin group. If there is not enough data for a URL group, Search Console builds a parent group from all URLs with the same protocol, host and port, for example https://www.example.com (Search Console Help). http and https count as separate origins. Such a row says: across all templates, the site falls short. The way forward then runs through the most visited templates, one after the other. In shops built on Shopware, these templates usually live in the theme; how we work there is described on the Shopware performance page.
Reading mobile and desktop separately
The overview page shows two charts, one for mobile and one for desktop. Status and issues are assigned per device type (Search Console Help): the same group can be Good on mobile and Need improvement on desktop – or the other way round. The web.dev recommendation also explicitly segments the 75th percentile across mobile and desktop (web.dev). An average across both device types would hide the weaker side.
Across the web, the mobile version fares worse on most metrics. In 2025, 48 percent (Web Almanac 2025) of websites recorded on mobile in the Chrome UX Report passed all three Core Web Vitals, compared with 56 percent (Web Almanac 2025) on desktop. For LCP, 62 percent of mobile pages reach a good value versus 74 percent on desktop (Web Almanac 2025). The gap is widest for responsiveness: 77 percent (Web Almanac 2025) of websites achieve a good INP on mobile, compared with 97 percent (Web Almanac 2025) on desktop.
In practice this means the mobile report is usually the stricter one and the one to tackle first. It only reflects Chrome users, though, because Chrome on iOS does not contribute data to CrUX (Chrome for Developers). A shop with many iPhone customers therefore sees only part of its mobile audience in the report. To know how the other visitors are doing, you need your own measurements from real visitors that cover every browser.
The desktop report still deserves attention, above all for layout. In 2025, 72 percent of desktop pages achieved a good CLS, compared with 81 percent on mobile (Web Almanac 2025). Wide layouts with sidebars, late-loading banners and ad slots offer more opportunities for shifts than a narrow column. If the desktop report looks worse than mobile on CLS, the article Avoid layout shift in your shop is the next stop.
“No data” and too little data
Not every site gets a complete report. If Search Console shows “No data available”, there are two possible reasons: either the property is new, or the CrUX report does not hold enough data for that device type (Search Console Help). For a new property it can take a few days until existing CrUX data is processed and shown; the data itself is collected whether or not a property exists.
The second reason is more common than many expect. CrUX only includes a page or origin once it reaches a minimum number of visitors; Google does not disclose the exact number (Chrome for Developers). For privacy reasons, URL groups also need a minimum amount of data to appear in the report (Search Console Help). On smaller sites this can lead to a patchy picture: the desktop report is missing entirely, mobile only shows the origin group, and individual templates stay invisible.
“Not enough data” does not mean “no problem”. It only means the report cannot say anything about it. Three routes help:
- PageSpeed Insights for the origin: if a single page lacks data, the tool shows the values for the whole origin, provided it has enough data (PageSpeed Insights documentation).
- Your own field data: a lean measurement from real visitors provides values per template and also covers Safari and Firefox. How to set this up with minimal data is shown in Performance measurement without consent.
- Lab tests per template: a throttled test run per template does not replace field data, but it shows where the causes lie and which template needs attention first.
Important for the analysis: if only INP lacks data, a group still stays in the report as long as LCP and CLS have enough. In that case PageSpeed Insights assesses LCP and CLS only; if LCP or CLS lacks data, no assessment is possible (PageSpeed Insights documentation). A green group without an INP value is therefore unchecked on responsiveness – especially on pages with filters, configurators and forms.
Validation: why “Start Tracking” takes four weeks
Once an issue is fixed, the details page offers the “Start Tracking” button. From then on, Search Console monitors for 28 days (Search Console Help) whether the issue still appears anywhere on the site. If it no longer appears on any URL during that time, it counts as fixed; if it appears on even a single URL, it counts as not fixed (Search Console Help). Search Console keeps evaluating the status of individual URLs for the entire period.
The button does not trigger re-indexing or any other action by Google. It merely starts a monitoring period of CrUX data lasting four weeks (Search Console Help). This matches the nature of the data: the field data in PageSpeed Insights and the CrUX dataset each represent a trailing period of 28 days (PageSpeed Insights documentation). A value improved today mixes day by day with the old, slow visits. Only once those have dropped out of the window does the group value fully reflect the new state.
- Started: validation is running and no remaining instances of the issue have been found.
- Looking good: all instances checked so far are fixed; the period is still running.
- Passed: all URLs have the status Passed; it can only be reached through a validation you started.
- Failed: one or more URLs are still affected after validation.
- N/A: the issue has disappeared from all URLs without a validation having been started (Search Console Help).
Do not start too early
Sometimes the status changes without you doing anything. The help page names borderline pages that a site-wide event pushed over the edge: a sharp rise in traffic or a change in latency of the service that delivers your images (Search Console Help). How to deliver images more leanly is covered under image optimisation. Less likely causes, according to the help page, are a widely rolled-out browser update or more visitors on slower networks. If you see group values close to 2.5 seconds or 0.1 in the report, plan for a margin instead of just scraping past the threshold.
Turning the report into a work order
The report tells you where visitors wait. It does not tell you why. Turning red bars into a finished task requires a translation into templates, causes and order. Google sets the order: first fix everything labelled Poor, then prioritise by issues that affect the most URLs or the most important ones; Need improvement is less urgent (Search Console Help).
- Export: the export contains chart and table data. Values shown in the report as “~” (not available) or “-” (not a number) appear as zero in the file (Search Console Help). A zero in the export is a missing value, not a perfect one.
- Map groups to templates: note the template behind the example URL for each row and keep mobile and desktop separate.
- Prioritise: Poor first, then by number and importance of affected URLs. A category template with many entrances outweighs a rarely visited guide.
- Find the cause in the lab: one test run or browser recording per template. How to weigh the findings of a lab run is covered in Reading a Lighthouse report.
- Implement the fix in the template, ship it and verify it on several group members.
- Watch your own field data until the effect is confirmed, and only then click “Start Tracking”.
- Record the outcome: release date, affected template, expected metric value and start of validation.
| Row in the report | Common cause in the template | First check |
|---|---|---|
| LCP over 4 s (mobile) | large image without priority, slow server response, render-blocking CSS | identify the LCP element and its four loading phases in the lab |
| INP over 500 ms | heavy event handlers, filter or variant scripts, third-party code | record the interaction and look for long tasks |
| CLS over 0.25 | late-loading banners, images without dimensions, font swaps | make layout shifts visible in the browser |
For LCP it pays to split it into its subparts, described in Analyse LCP subparts; if the cause lies in the server response, it belongs in server optimisation. For non-technical readers, the help page also gives rules of thumb: less than 500 KB (Search Console Help) for a page including all its resources and no more than 50 resources (Search Console Help) for pages on mobile. They are a good conversation starter but do not replace a search for causes per template – a light page weight helps little if a single script slows the response to every click.
The reading rule in one sentence
What a correctly read report saves
The Core Web Vitals report is not a report card for individual pages but a map of templates. Read that way, it lets you work in a few places with large effect: on the template behind many addresses, on the device type with the weaker value and on the metric that drags the group status down. Read as a list of pages, it has you polishing example URLs and waiting four weeks for a result that cannot arrive that way.
In a performance analysis we read the report together with you, map every group to its template and measure the causes in the lab and with real visitors. The implementation follows where it reaches every page of a group, and we only start validation in Search Console once our own measurements show success. An overview of all building blocks is available under Services.
Sources
Related Articles
RUM vs. CrUX: Using Field Data Right for Speed
Lighthouse lab scores do not affect ranking. Google rates Core Web Vitals via CrUX field data at the 75th percentile. How to use RUM, CrUX and budgets.
What Does PageSpeed Optimization Cost? Planning the Effort
PageSpeed optimization costs depend on templates, shop system, scripts, server and images. How to plan analysis, fixed price, monitoring and a 2027 budget.
Adding Black Week Promo Banners Without Layout Shift
Add Black Week notice bars, countdowns, pop-ups and badges without anything jumping: reserve space, deliver from the server and keep CLS at 0.1 or below.