A team ships a performance fix on Monday. By Friday the Core Web Vitals report in Search Console looks the same, and someone asks whether the fix worked. The answer is almost always that it is too early to tell, and Google’s documentation explains why. This article summarises what the Core Web Vitals report help page says, and what we think follows for teams that release frequently.
The report shows field data, not a test result
Google describes the report as showing how pages perform based on real-world usage data, sometimes called field data. It is built on three metrics measured from actual users: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. That differs from a lab test, which loads a page once under fixed conditions and reports immediately. Google’s page notes that PageSpeed Insights shows both live test data and field data, and that the figures there can differ from the report.
The practical point is that two different tools can both be right. A lab test shows what a page does now; the report shows what real visitors experienced across the recent past.
The 28-day window
The group figures in the report are defined over a trailing period. Google’s page states, for each metric, that 75% of page requests took this amount of time or less in the last 28 days, or in the case of layout shift, had this score or less. Two consequences follow from that definition. A fix released this week affects only a fraction of the days in the window, and the 75th-percentile measure means the figure reflects the experience just beyond the typical visitor, not the average one.
None of this is a defect. It is a design that favours stable figures over quick ones, and it is why a report can lag a release by weeks.
How a URL group gets its status
The report groups similar URLs and shows them by status: Poor, Need improvement or Good. Google says that once a group has a threshold amount of data for both LCP and CLS, the group’s status is its most poorly performing metric. A group with good INP but poor CLS is therefore Poor. If a group lacks the minimum data for both LCP and CLS, it is omitted altogether.
Three further limits are worth knowing. Only indexed URLs can appear. The report is a sample of pages, not a list of every indexed URL. And data is assigned to the actual URL, not the canonical one, which differs from most other Search Console reports. Google also says data is combined across all locations, so a large audience on slow connections can pull the figures down.
Reading the charts and tables correctly
Two display details cause confusion after a release. Google explains that the chart counts each URL once, for the slowest issue affecting it, while the table counts every issue associated with a URL, so a page with one Poor and one Need improvement issue appears once in the chart and in both rows of the table. The totals therefore differ without any error. And because the data is combined for all requests from all locations, Google suggests breaking performance down by country, using BigQuery, if you suspect an audience on slow connections is dragging the figures down.
Both points matter when someone compares the report before and after a change and sees numbers that do not match their expectations.
What validate fix does, and does not do
When you have fixed an issue across your URLs, the report offers a way to confirm it. Google says that Start Tracking starts a 28-day monitoring session to look for instances of the issue. If the issue is not present in any URL during the window, it is considered fixed, and its presence in any single URL is enough to mark it as not fixed. Google is explicit that Start Tracking does not trigger re-indexing or any other active behaviour; it restarts the clock on a four-week monitoring period of the field data. If a validation fails, you can fix further issues and start a new one.
For release planning that is the most useful sentence in the documentation. Validation is a monitoring period, not a request to Google to look again.
A routine that fits the documentation
The documentation does not prescribe a process, but its design suggests one. Use lab tests such as PageSpeed Insights or Lighthouse to confirm immediately that a change did what the engineer intended. Treat the report as the slower confirmation that real users have noticed. Start tracking after a fix has shipped to the whole site, because a partial fix leaves the issue in some URLs for the full window. And when a group shows no data, the help page says it is either a new property or too little data in the Chrome UX Report for that device type, so absence of data is not evidence of a problem.
It also helps to keep expectations in proportion. Our article on page experience summarises what Google says is and is not used in ranking, and these metrics are part of that picture, not a switch. The report exists to show real users’ experience, and the sensible response to a poor status is to find the cause, not to chase the status.
Where this fits at Cultured Digital: releases and performance
Cultured Digital’s ongoing development work covers technical SEO implementation, performance and scalability, and ongoing technical development, and the web development page describes performance as budgeted, not hoped for. The implementation and QA guide covers checking releases before and after launch, which is where a lab test belongs. After a release changes traffic, our notes on what to check after a site move or release cover the wider diagnosis. We do not promise rankings or traffic numbers, and the report is not one either.