Field Largest Contentful Paint in PageSpeed Insights can move while your release calendar stays empty.
Chrome User Experience Report (CrUX) data is always a 28-day rolling average of real Chrome sessions.
From Chrome 153 Stable on 8 September 2026, Chrome also moves to a two-week release cycle, so that same window can include more than one browser major with different paint and interaction behaviour.
An amber field band after a quiet week is often population mix (who updated Chrome, which channel they use, how fast auto-update spreads), not proof that engineering shipped a regression on Tuesday.
We already separated pipeline lag from rolling-window lag in CrUX pipeline delays and late field data and explained why a verified fix can sit inside a green lab run and an amber field band in why your Core Web Vitals fix is not in CrUX yet.
The gap here is the third clock agencies rarely label: browser release cadence inside the field window.
When nobody deployed but field LCP drifts, you need release annotations on the same calendar as app, CDN, tag manager, and RUM changes, sample thresholds before you slice by exact Chrome major, and scheduled lab runs as same-week proof that the origin did not change.
Why field LCP can move when nobody deployed CrUX and PageSpeed Insights field sections describe what real Chrome users experienced over roughly the past 28 days, not what your staging build measured yesterday.
If the mix of Chrome versions, devices, networks, and journeys inside that window changes, the published p75 can move even when your HTML, CSS, and JavaScript bundles are byte-identical to last month.
Three non-deploy causes show up often in agency tickets: Browser updates.
A new Stable or Extended Stable channel release changes paint timing, image decoding, lazy-loading heuristics, or interaction scheduling for the same page.
Users who auto-update mid-window contribute post-update sessions beside pre-update sessions in one aggregate.
Channel skew.
Beta, Dev, and Canary users are a thin slice for most retail sites, but enterprise Extended Stable cohorts can lag Stable by weeks.
A retail origin and a locked-down corporate audience can read different field bands on the same URL template.
Traffic mix.
Campaign traffic, geography shifts, or seasonality change which templates dominate Chrome sessions.
Origin-level field LCP can move when the homepage share of traffic falls while a slower category listing gains share, with no code change on either template.
Lab runs on a fixed URL answer whether your deploy changed the critical path.
Field CrUX answers what Chrome users actually experienced across versions and journeys.
Treating a field move as a deploy regression without checking browser and traffic mix sends engineering on a hunt for a commit that does not exist.
Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153 Google announced in March 2026 that Chrome will move from a four-week Stable cadence to a two-week cycle, starting with Chrome 153 Stable on 8 September 2026 (Chrome two-week release blog).
Beta and Stable promotions arrive every two weeks on Desktop, Android, and iOS.
Extended Stable keeps an eight-week cycle for enterprises that need longer validation windows (Chrome Enterprise Extended Stable).
The schedule compresses milestones quickly.
Under the new table in Google's post, Chrome 153 Stable cuts on 25 August 2026 with public Stable on 8 September, while Chrome 154 Stable follows on 22 September.
Firefox is running a similar experiment around Firefox 155 from 1 September 2026 (see community coverage linked from CSS Wizardry Web-Perf Wednesday 006).
Performance teams that only annotated application releases in 2025 will need browser rows on the same calendar in
2026.
Release Old four-week Stable (illustrative) New two-week Stable (from Google table) Chrome 153 Tue 22 Sep 2026 **Tue 8 Sep 2026** Chrome 154 Tue 20 Oct 2026 **Tue 22 Sep 2026** Smaller, more frequent browser releases are good for security and platform velocity.
For field reporting they mean more opportunities for a 28-day CrUX window to span two majors with different Web Vitals behaviour, without any change on your origin.
How a 28-day CrUX window can span multiple browser majors CrUX aggregates opted-in Chrome sessions into a rolling 28-day window.
At any query, PageSpeed Insights and the CrUX API return a with and covering that blend (CrUX API documentation).
The window advances daily: oldest day drops, newest day enters.
There is no switch that flips the entire population to "only Chrome 153 sessions" on Stable release day.
Under a four-week browser cadence, one 28-day field window often covered one new Stable major plus tail versions.
Under a two-week cadence, the same window can include two adjacent majors (for example 152 and 153) while auto-update propagates.
Each major can shift LCP, INP, or CLS for the same URL because the browser pipeline changed, not because your LCP element or server timing changed.
Clock What moves Typical agency mistake 28-day CrUX window Rolling average of Chrome sessions Treating field p75 as "yesterday's score" Chrome Stable cadence Browser majors entering the window Ignoring browser rows on the release calendar App / CDN deploy Origin HTML, assets, cache rules Blaming deploys for browser-driven field drift Lab schedule Controlled PageSpeed Insights / Lighthouse runs Expecting lab to explain field without dates For metric definitions and why field percentiles behave differently from lab medians, start with our practical Core Web Vitals guide.
For why lab and field are different instruments on the same URL, see synthetic versus real user monitoring.
Browser version in RUM: population mix vs a site regression First-party Real User Monitoring (RUM) and CrUX answer different questions.
CrUX is a public, privacy-thresholded view of Chrome traffic Google already collected.
RUM is yours: you choose segments, retention, and alert rules.
When practitioners search browser version RUM, they usually need to know whether a field shift is segment noise before they open a regression ticket.
Population mix means the aggregate changed because the audience composition changed: more sessions on Chrome 153, fewer on 152, a higher share of mobile on a slower network, or a campaign that sent traffic to a heavier template.
Site regression means the same browser version and similar journey on the same URL got worse after your change (or after a third-party or CDN change you control).
Before you slice field data by exact Chrome major, set sample thresholds.
Thin segments produce volatile p75 lines that look like regressions every week.
Rules we use in client work: Do not report URL-level p75 for a single Chrome major until you have enough sessions to trust the segment (exact cut-offs depend on traffic; treat very small counts as directional only).
Prefer unsegmented LCP, INP, and CLS as the headline series in retainer reports; use browser-major slices in appendix slides for engineers.
Compare like with like: same form factor, same URL or origin scope, same collection period dates.
Pair every segmented chart with an unsegmented line so leadership sees whether the whole population moved or only one slice.
Harry Roberts framed the risk clearly in Web-Perf Wednesday 006: faster browser releases change the RUM population you are averaging, not just the code on your server.
Agencies that report "Chrome 152 LCP" and "Chrome 153 LCP" without sample sizes invite false escalations every Stable Tuesday.
Put Chrome Stable on the same calendar as deploys and CDN changes Performance regressions are easier to debug when every graph annotation uses the same calendar.
Most teams already mark application deploys, CDN cache rule changes, tag manager publishes, and major marketing releases.
Browser Stable and Beta dates belong on that same timeline from September 2026 onward.
Checklist we ask account and engineering leads to maintain: Chrome Stable and Early Stable d