Skip to content

4 min read807 wordsLast verified

How often does CrUX update?

CrUX (Chrome User Experience Report) updates once a month, typically on the second Tuesday. Each update covers a rolling 28-day window of Chrome user data. Knowing this cadence matters when you're trying to measure whether a fix actually worked.

The exact cadence

  • Monthly publish: Google publishes a fresh CrUX dataset roughly once a calendar month. The historical convention has been "the second Tuesday of the month," though it occasionally slips by a few days.
  • 28-day rolling window: each publish covers the most recent 28 days of measurements. There's about a 2-day lag between the end of the measurement window and the publish date.
  • No emergency publishes: there's no way to trigger an early update. If you shipped a fix yesterday, you won't see it in CrUX for weeks.

What the rolling window means in practice

Because every CrUX number is a 28-day average (at p75), a fix you shipped today will:

  • Day 0: new traffic starts hitting the new code. Zero data points in CrUX yet.
  • Day 7: new code accounts for ~25% of the trailing 28-day window. Old (broken) data dominates.
  • Day 14: roughly 50/50 old vs new. CrUX numbers start moving.
  • Day 28: the trailing window is entirely post-fix. New numbers are fully reflected.
  • Day 28 + publish lag: the next monthly publish includes the entire post-fix window. This is when you finally see "good" numbers.

The practical horizon for "did my fix work?" is 4–6 weeks. Anything sooner is partial data.

How to spot-check during the window

Don't sit blind for a month. You can:

  1. Run Lighthouse on the page — lab data updates immediately. If the lab score improved, the fix is working; CrUX just hasn't caught up.
  2. Use the Web Vitals JavaScript library — measures field data on your own users in real time. We use this on our own homepage; see Self-Vitals. RUM tools (SpeedCurve, DebugBear, Calibre, Sentry Performance) do the same at scale.
  3. Watch your own analytics — bounce rate, exit rate, and time-on-page often reflect performance changes faster than CrUX. If you fixed a slow LCP, bounce rate should drop within days.

When to re-check CrUX after a fix

  • Week 1: don't bother. Too noisy.
  • Week 2: glance at the trend, but expect mixed signal.
  • Week 4: real change should be visible.
  • Week 5–6: the next monthly CrUX publish will show clean post-fix numbers.

Re-check on this site weekly during the change window — we cache CrUX data for 30 days to match the publish cadence, so you'll see the new monthly numbers within hours of Google's publish.

What happens if Google delays a publish

Occasionally Google ships the monthly CrUX update a few days late. We've seen 3–5 day slips. The data is still correct when it lands; the window just covers a slightly different 28-day range.

Our cache holds the previous month's data until the new month is published. You'll never see partially-updated CrUX data on this site — it's either the old monthly snapshot or the new one, never a mix.

What CrUX doesn't tell you

A few things to remember about the cadence:

  • CrUX doesn't see one-off events. A single bad day caused by a regression is averaged into 28 days of normal traffic. You won't see a one-day spike.
  • CrUX is per-origin (or per-URL for big sites). A fix to one page won't move your overall origin number unless that page gets significant traffic share.
  • CrUX doesn't catch sub-100ms changes well. The p75 has natural variance of ±100ms or so for INP and LCP. A 50ms "improvement" is noise.
  • CrUX only sees Chrome users. Safari and Firefox traffic doesn't show up. If your audience skews Safari, your real performance picture is missing.

How our tool handles the monthly cadence

Each domain page on this site caches the latest CrUX snapshot. We use ISR with a 30-day revalidation window, which matches Google's monthly publish cadence almost exactly. In practice:

  • The first request after a CrUX publish triggers a background regeneration.
  • Subsequent requests serve the fresh data immediately.
  • The historical chart shows the last 12 monthly snapshots, so you can see trend over a year.

If a domain page seems stale, check the "Last verified" badge — that's the timestamp of our most recent CrUX fetch. We never show data older than ~30 days plus a small propagation delay.

TL;DR

CrUX updates monthly. After a fix, expect to wait 4–6 weeks to see clean post-fix numbers. In the meantime, use Lighthouse + RUM to verify the fix worked. The CrUX cadence is slow because field data has to accumulate; that slowness is also why CrUX is reliable — it can't be gamed by a single bad day.

By Paulo de Vries · Published

Check a site's vitals

Explore by industry

See how real-world sites in each vertical perform on Core Web Vitals.

Related guides

← All guides