Core Web Vitals Report Not Updating? How the 28-Day CrUX Window Works

If you fixed your site and the Core Web Vitals report still looks stuck, you are not imagining it — and in most cases you have not done anything wrong. The report in Search Console is built on real-user field data, not on a fresh lab test, so it moves slowly by design. Understanding that lag is the difference between panicking, undoing good work, and making the next useful check.

Start with the distinction that explains almost every confusing report: field data describes what real visitors experienced over time, while lab data describes what one simulated test did at one moment. If you need the wider picture first, read the WordPress Core Web Vitals guide. This guide explains a core web vitals report not updating after a fix, in plain terms.

Why does the Core Web Vitals report look stuck?

Search Console and the Chrome User Experience Report, known as CrUX, are field-data sources. They collect measurements from real Chrome users visiting real pages, on real devices and connections. PageSpeed Insights also shows field data when enough visits are available, but its lab score is different: it is a single simulated run in controlled conditions. That is why a lab score can jump the day after a fix while the field report barely moves.

A report can also look stuck for reasons that have nothing to do with whether your fix was good:

• Low traffic or insufficient field data: with few eligible visits, the window fills slowly and a group may stay without a clear new verdict for longer.
• URL grouping: Search Console groups similar URLs. A fix on one page does not automatically change the group if other pages in the same group are still slow.
• A partial fix: the change may be live on one template, post type, or device type, but not on all the affected templates.
• A regression during the window: a new plugin, script, image, or layout change can add slow visits that offset the improvement.
• Lab improvement, field lag: your simulated test improved, but real users have not yet produced enough post-fix visits to shift the field distribution.

None of that means the field report is broken. It means it is answering a different question from a lab test: not “how fast is this page right now in a test,” but “how did real users experience this group of pages over the recent period?”

How does the 28-day CrUX window work?

The 28-day CrUX window is a rolling 28-day period. Each day, the oldest day drops out and the newest day is added, so the window keeps moving forward rather than resetting all at once. That rolling behavior is the key to the whole delay: yesterday’s fix does not replace the previous 27 days of visits.

Core Web Vitals field assessments are also based on the 75th percentile of real-user experiences, not on a single average or on your fastest visit. In plain terms, the reported value has to reflect the experience at the slower end of the distribution, so a handful of very fast visits cannot instantly rescue a group that still contains many slow ones.

Think of it this way. If most of the window still contains pre-fix visits, those visits keep weighing on the result even as new, faster visits arrive. As slow days roll out and are replaced by post-fix days, the picture can improve gradually — but a single fast day does not flip a failing URL group, and the change is not linear day by day. That is also why you should not promise, or expect, a specific date on which a report will turn green: the timing depends on traffic volume, the mix of pages in the group, and whether the fix stays live and stable.

This is especially important for slow interactions and layout shifts, where the problem may be concentrated on particular templates or user journeys. If you are working through interaction problems, the INP guide for WordPress explains how to find the slow interaction first, rather than guessing. For shifting layouts, see how to fix CLS in WordPress, and for a slow server response, see high TTFB in WordPress.

What to check while you wait for field data to update?

Waiting is not the same as doing nothing. While the field window rolls forward, use lab and diagnostic checks to confirm that the fix is real, complete, and stable — and to catch a regression early.

• Retest the same pages in the lab: run the same URLs, on the same type of test, before and after the change. A one-off good score on a different page proves very little.
• Check PageSpeed field data where available: where a page or origin has enough field data, compare the field section with the lab section instead of treating the lab score as the whole story. For a structured testing routine, see the best WordPress speed test tools.
• Inspect Search Console URL groups: note which group is failing, which metric is failing, and whether the affected URLs share a template. A group verdict is not a verdict on one page alone.
• Confirm the fix is live everywhere it matters: check the affected templates, not just the homepage or one example post. Cache, staging leftovers, and template-specific scripts are common reasons a fix looks complete in testing but is partial in the wild.
• Watch for new regressions: retest after every plugin, theme, or content change during the window, because a new slow element can quietly refill the window with poor visits.

Also be careful with rumors about sudden CrUX changes. A new claim about thresholds, metrics, or timelines should be checked against what the report itself shows for your URLs, not accepted because it is widely shared. The Core Web Vitals 2026 myth-bust is a useful reminder to separate a verified change from a rumor before you rebuild a site around it.

If lab scores stay good, the fix is live on all affected templates, and no new regression appears, the most useful action is usually to keep monitoring rather than to keep changing things. Constantly swapping optimizations during the window makes it harder to know which change helped, and can even introduce new problems that slow users actually experience.

Next step: request a free speed audit from ProSpeedGuy and mention that your Core Web Vitals report is not updating, so the review can focus on field data, URL groups, and the templates behind them.

Common Questions

Frequently Asked Questions

Clear, honest answers about field data, the 28-day window, and what to check while you wait.