You shipped the fix on Tuesday. Hero images are compressed, the heavy tag is gone from the homepage, and Lighthouse on mobile looks healthier than Monday's run. Someone pastes the PageSpeed Insights link into Slack with a green check. On Thursday the account manager forwards a Search Console screenshot: the URL group is still Needs improvement, or field LCP in PageSpeed Insights is still amber. The instinct is to assume the deployment failed or that Google is ignoring the work. In most cases the change is real. Chrome User Experience Report (CrUX) data has not finished rolling the old sessions out of its window yet.
We already covered why lab and field can disagree on the same URL in synthetic versus real user monitoring. The gap below is the timeline inside that split: how CrUX's 28-day rolling average updates, why third-party and CDN fixes take weeks to show, and what to monitor so the client sees proof before Search Console turns green. If you only remember one rule, remember that field screenshots trail lab verification by design.
How CrUX data updates: the 28-day rolling average
CrUX is Google's public dataset of real-user Core Web Vitals from opted-in Chrome sessions on eligible origins and URLs. It is not a lab run. It is not a snapshot taken on the day you ship. According to Chrome's CrUX API documentation, the numbers in PageSpeed Insights, the CrUX API, and related tools are a 28-day rolling average: at any moment you are looking at experiences collected across roughly the past four weeks, not "yesterday after the release."
That design smooths day-to-day traffic noise. A busy campaign Friday or a quiet Sunday no longer swings the published p75 on its own. The trade-off is latency. Sessions collected before your fix stay inside the window until they age out, so a green lab run on ship day can sit next to amber field bands for days or weeks. Google's CrUX versus RUM differences article is blunt: CrUX uses a 28-day sliding window and you cannot shorten it. First-party RUM can show smaller time ranges if you accept more noise.
PageSpeed Insights and the daily CrUX API refresh that rolling window roughly every day, with a short processing lag (Chrome's docs put the API about two days behind "today" in Pacific time). Search Console's Core Web Vitals report draws on the same CrUX base, so client screenshots lag for the same reason. Monthly BigQuery CrUX tables and the weekly History API still describe overlapping 28-day collection periods; they do not collapse the window into a single-day score. For metric definitions before you argue about timelines, start with our practical Core Web Vitals guide.
When does CrUX update after a Core Web Vitals fix?
There is no single calendar day when CrUX flips to your new numbers. Each daily refresh drops the oldest day and adds a newer one. The published p75 moves gradually as post-fix traffic replaces pre-fix traffic inside the window. Teams often expect a step change on day 29. What you usually get is a curve: modest movement in the first week if traffic is high and the fix is large, clearer separation after two to three weeks, and a cleaner field result once most of the window is post-fix sessions.
Traffic volume matters. A high-traffic homepage pushes more new experiences into the aggregate each day, so old sessions lose weight faster. A low-traffic landing page can keep sparse pre-fix samples in the mix longer, and some URLs never earn stable URL-level CrUX at all. Origin-level field data can look better or worse than a single template depending on which URLs dominate Chrome traffic. Eligibility rules, form factor splits (phone versus desktop), and thin samples still produce "no data" in PageSpeed Insights even when lab runs succeed every morning.
So "when does CrUX update?" has two answers at once. The dataset refreshes often (daily for the API and PageSpeed Insights field numbers). The value you care about is always a rolling average, so field proof for clients trails lab proof by design. When tools expose firstDate and endDate on the collection period, put those dates on the report. Without them, a screenshot looks like a live score when it is really a four-week blend.
Lab scores versus CrUX field data after a Core Web Vitals fix
Lab and field answer different questions on different clocks. A scheduled Lighthouse-style run through PageSpeed Insights measures a controlled load on a URL you choose, with a fixed device profile and network emulation, so you can compare Tuesday's ship to Monday's baseline under the same conditions. Field CrUX reports what real Chrome users experienced across devices, networks, cache states, and journeys over the rolling window. The short version for this lag: lab confirms the fix shipped; CrUX confirms enough real users have lived with it for the aggregate to move.
| Signal | Clock | Best use after a fix |
|---|---|---|
| Scheduled lab (PageSpeed Insights / Lighthouse) | Same day, every run | Prove the change on priority URLs before the client meeting |
| CrUX field (PageSpeed Insights, Search Console, CrUX API) | 28-day rolling average | SEO and page-experience reporting once traffic ages in |
| First-party RUM | Configurable windows | Segmented proof if a client already has a snippet |
Trouble starts when one PageSpeed Insights paste is treated as both engineering proof and Search Console status. Spot checks also fail to scale once you manage many clients; that gap is why PageSpeed Insights versus automated monitoring exists. Keep lab history on a schedule so you can show before/after without waiting for CrUX. Label field screenshots as lagging indicators, not same-day scorecards.
Why Core Web Vitals fixes take weeks to show in CrUX
Not every fix ages out of the rolling window at the same speed. Some lab improvements barely touch the field mix clients care about. The three cases below are the ones that show up most often in agency tickets after a "green" lab paste.
Third-party script removal and CrUX lag
Removing a heavy tag often improves lab Total Blocking Time and Interaction to Next Paint on a clean run the same day. Real users may still hit cached HTML, tag-manager containers that update later, or secondary templates where the tag remains. Old sessions with the heavy script stay in CrUX until they roll off. Lab green on the homepage is necessary; it is not enough until enough post-removal traffic fills the window.
CDN and cache-rule changes
CDN and cache-rule changes can cut Time to First Byte and Largest Contentful Paint in controlled tests within hours. Field users on different geographies, ISPs, and cache hit rates still contribute pre-change timings for weeks. Partial adoption of a new point of presence or a staggered purge means CrUX blends both eras. Expect Search Console origin status to move slowly even when synthetic runs look clear.
Theme, template, and image work
Theme, template, and image work (hero sizing, font loading, layout reserves for CLS) shows up cleanly in lab when you test the exact URL you changed. CrUX aggregates experiences across templates that share an origin. If only the blog template improved and the product listing still shifts, origin-level field bands can stay amber while your ticket looks closed. Align monitored URLs with the journeys that generate Chrome traffic, rather than the single page you edited in staging.
In our experience, the client conversation goes better when you separate three statements: (1) we verified the fix in lab on these URLs on these dates, (2) CrUX will keep including pre-fix sessions for up to about 28 days, and (3) we will watch field percentiles weekly without treating every daily wiggle as a regression. That framing prevents "the fix did not work" tickets in week one. It also gives account managers a shared script so engineering and SEO are not contradicting each other in the same thread.
How to monitor Core Web Vitals while CrUX data updates
Waiting passively for CrUX leaves a gap clients notice. They pay for confidence during the lag. A green Search Console badge later is not a substitute for that week. Set a monitoring plan that treats lab as the deploy gate and CrUX as the lagging SEO report.
- Baseline before you change. Capture lab LCP, INP, and CLS (plus supporting timings you report) on mobile and desktop for the URLs in scope. Store the run dates so the before/after is not a memory test.
- Keep a schedule after you ship. Daily or a few times per week on high-value pages, less often on long-tail templates, matching the priority model in how to schedule PageSpeed monitoring frequency.
- Set budgets and alerts on lab vitals. Use thresholds from a shared performance budget template so a regression during the CrUX wait still notifies someone, even if field data has not moved yet.
- Read field data once a week. Check PageSpeed Insights or Search Console, note the collection period, and compare direction of travel rather than day-to-day noise.
- Document the lag in client language. One sentence in the retainer report ("Field CrUX remains a 28-day rolling average; lab trends below are same-week verification") saves a meeting.
Apogee Watcher runs that split for multi-site teams: scheduled PageSpeed Insights-backed lab tests across many sites, CrUX field numbers when Google returns them beside the lab result, budgets and alerts while you wait, and multi-tenant organisations so agencies are not pasting PageSpeed Insights links into spreadsheets. We do not replace first-party RUM. We do not invent a faster CrUX. We give you a repeatable lab clock next to the field clock Google already publishes, layered onto the SEO and observability tools you already use.
What to tell clients when CrUX has not updated yet
Stakeholders rarely want a lecture on aggregation windows. They want to know whether the invoice bought a real improvement. Use a short script in email and in the monthly review. Do not put lab dates and field screenshots on the same slide without labels.
- What we fixed: name the change (script removed, image pipeline, CDN rule) and the URLs.
- What lab shows now: before/after on the same strategy (mobile/desktop), with dates.
- What field will do next: CrUX and Search Console update from a 28-day rolling average of real Chrome users; expect gradual movement over weeks, not an overnight flip.
- What we watch meanwhile: scheduled lab budgets and alerts so regressions do not hide behind the lag.
- What "done" means: lab stable in budget for several days, then field p75 entering Good (or the agreed band) on the URLs or origin in scope.
Avoid promising a specific Search Console colour by a calendar date unless traffic is huge and the fix is clear. Prefer ranges ("we expect clearer field movement after two to three weeks of post-fix traffic") and show the collection period when tools expose it. If origin status stays poor while one landing page is excellent in lab, explain template mix rather than declaring CrUX broken.
FAQ
When does CrUX update after I fix Core Web Vitals?
The CrUX views in PageSpeed Insights and the CrUX API refresh often (typically daily for the rolling window, with a short processing lag). The number you see is still an aggregate of about 28 days of Chrome experiences, so your fix enters the published p75 gradually as older sessions age out. Plan client expectations in weeks, not hours.
Why is CrUX different from my Lighthouse score after a deployment?
Lighthouse (lab) measures a controlled run you triggered. CrUX (field) averages real users over a sliding 28-day window. Both can be correct at once: lab proves the new code path, field still includes pre-fix traffic. For shorter windows and session segments, see how first-party RUM sits beside CrUX in synthetic versus real user monitoring.
Is Core Web Vitals in Search Console the same 28-day rolling average?
Search Console's Core Web Vitals report is based on CrUX field data, so it inherits the same rolling-window behaviour and eligibility limits. Treat it as a lagging SEO view, not a same-day deploy dashboard. Use scheduled lab monitoring for immediate verification.
How long until field data fully reflects my change?
A full replacement of the window takes on the order of 28 days of post-fix traffic in the aggregate, though large improvements on high-traffic URLs can show direction earlier. Low-traffic URLs may move slowly or lack URL-level CrUX entirely. Keep lab history so you are not blind during that period.
Should agencies wait for CrUX before closing a performance ticket?
Close the engineering ticket when lab verification and release criteria are met, then keep a separate field-watch item until CrUX or Search Console moves into the agreed band. Mixing those two definitions of "done" creates false reopenings in week one. Budgets and alerts on scheduled tests keep the watch honest without daily manual PageSpeed Insights checks.
On Monday, open the priority URL list for the account that shipped last week. Record lab LCP, INP, and CLS from the latest scheduled run beside CrUX or Search Console status, and note the collection period dates when they are available. One line per row is enough: lab improved, field still lagging, or field data missing. If you manage many client sites and need that history on a schedule, start a free trial of Apogee Watcher or run a free domain PageSpeed check on one money URL first. Set budgets on the pages that pay the bills, review field collection periods weekly, and keep the 28-day rolling-average sentence in the client report until the amber screenshot turns green.
Top comments (0)