How Long Does It Take Core Web Vitals to Update After You Fix Them?
Short answer: up to 28 days for the fix to fully show, with the first movement visible after 2–3 days. Your Core Web Vitals field data is a rolling 28-day average, so yesterday's fix has to gradually dilute four weeks of old, slow measurements before the assessment reflects reality.
If you shipped a fix last week, re-tested in PageSpeed Insights, and saw the same failing assessment, the fix isn't necessarily broken. You're just reading a report that is still mostly measuring the site you had before the fix.
TL;DR
- Core Web Vitals field data comes from CrUX, a rolling 28-day window updated daily around 04:00 UTC.
- After a fix, expect: first movement in 2–3 days, a visible trend by day 7, and a fully clean window at day 28.
- The pass/fail assessment can flip before day 28 if the improvement is big enough to drag the 75th percentile over the threshold.
- Search Console's "Validate fix" runs its own separate 28-day tracking session, starting from when you click it, not when you shipped.
- Don't wait a month to find out if a fix worked. Real-user monitoring shows the answer in about 24 hours.
Why the Delay Exists at All
The Core Web Vitals assessment in PageSpeed Insights and the report in Search Console are both built on CrUX, the Chrome User Experience Report, which aggregates real Chrome visitors' experiences on your site. (If the difference between this field data and your 0–100 lab score is fuzzy, read why your PageSpeed score and Core Web Vitals disagree first.)
CrUX doesn't report yesterday's performance. Every day it publishes the 75th percentile of the previous 28 days combined. Google uses the long window deliberately: it smooths out traffic spikes, slow news days, and one-off anomalies, so rankings aren't whipsawed by noise. The side effect: your fix enters that window one day at a time.
The Actual Timeline
Say you ship an LCP fix on day 0. Here's what the data does:
| When | What's in the 28-day window | What you see |
|---|---|---|
| Day 0 | 100% pre-fix data | Nothing. Failing assessment |
| Day 2–3 | First post-fix days enter the window | Metrics twitch slightly; assessment usually unchanged |
| Day 7 | ~25% post-fix data | A visible trend if you track daily; assessment may flip if the fix was large |
| Day 14 | ~50% post-fix data | The p75 has moved substantially; borderline pages often flip here |
| Day 28 | 100% post-fix data | The window is clean. This is your real, current performance |
The assessment can flip early. Passing isn't about the window being clean, it's about the 75th percentile crossing the threshold. If your fix took LCP from 4.5 s to 1.8 s, the blended p75 may drop below 2.5 s by day 10–14. A marginal improvement (4.5 s to 2.6 s) needs nearly the full window.
The window never "resets". It rolls forward daily. There's no event that flushes it, and no way to make Google re-measure faster. Anyone selling you an "instant CrUX refresh" is selling something that doesn't exist.
Search Console Adds Its Own Clock
The Core Web Vitals report in Search Console runs on the same CrUX data but groups URLs and adds the Validate fix button, which starts a separate 28-day monitoring session from the moment you click it.
Worst case: ship the fix, wait a couple of weeks, notice the report, click Validate fix, and now you're on a new 28-day clock on top of the time already elapsed. Practical advice: click Validate fix as soon as you ship, not when you get around to checking the report. A "Pending" state for two or three weeks is normal and not a signal the fix failed.
Different CrUX surfaces also update at different speeds: the daily API and PageSpeed Insights update every day; the CrUX History API publishes weekly snapshots; the BigQuery dataset is monthly. If two tools disagree, check which snapshot each reads.
How to Verify a Fix in Days, Not Weeks
- Instrument real-user monitoring before you ship. The free
web-vitalsJavaScript library is ~2 KB and feeds LCP, INP, and CLS from your actual visitors into GA4 or any endpoint. Within 24–48 hours you'll see whether the metric moved, same data source Google uses, without the 28-day averaging. - Confirm the mechanism in lab tools. Run Lighthouse before and after. If the fix was real (say, preloading the LCP image), the lab waterfall shows it immediately.
- Track the CrUX trend, not the snapshot. Query the daily CrUX API (or the History API's weekly series) and watch the p75 slide. A downward slope by day 7 means you can stop worrying.
- Then let the 28 days run. The assessment flip is a lagging confirmation of what your RUM data already told you.
Frequently Asked Questions
How long until Core Web Vitals update after a fix?
The first improvement appears in CrUX data within 2–3 days, and the full effect shows after 28 days, when the rolling window contains only post-fix data. The pass/fail assessment can flip earlier if the improvement is large.
Why is my Core Web Vitals report not updating at all?
Check three things: whether you're looking at URL-level or origin-level data (low-traffic pages fall back to the whole-domain aggregate), whether the fix actually shipped to the template in question, and whether your RUM or lab data confirms the metric improved. If real users aren't measurably faster, CrUX won't be either.
Does clicking "Validate fix" in Search Console speed anything up?
No. It doesn't re-crawl or re-measure anything. It starts a 28-day observation window and reports whether the issue stays gone. Click it immediately after shipping so the clock starts as early as possible.
Do Core Web Vitals affect rankings during the 28 days?
Google's page experience signal reads the same CrUX data, so the old performance lingers in ranking terms too, another reason to fix issues before they've sat in the window for months, and to verify with RUM instead of shipping blind.
Shipped the Fix and Still Failing After a Full Window?
Then the problem usually isn't the timeline, it's that the fix didn't move the metric for real users. Diagnosing that gap is what we do.
LinkedIn