Chrome's two-week release cycle from September 2026 puts two majors in one CrUX window

Chrome shifts to a two-week Stable cadence

According to a post on dev.to, Google announced in March 2026 that Chrome will drop its four-week Stable schedule in favour of a two-week cycle, beginning with Chrome 153 Stable on 8 September 2026. Promotions to Beta and Stable will land every two weeks on desktop, Android and iOS, while Extended Stable keeps an eight-week rhythm for enterprises that need longer validation windows. The post lays out the compression with two milestones: Chrome 153 reaches the public Stable channel on 8 September 2026 and Chrome 154 follows on 22 September — slots that the old four-week schedule would have placed in late September and late October. It also points to community coverage indicating Firefox is running a comparable experiment around Firefox 155 from 1 September 2026.

What this does to 28-day field data

The article's central concern is the Chrome User Experience Report. CrUX — and the field panel in PageSpeed Insights — aggregates opted-in Chrome sessions into a rolling 28-day window, and the CrUX API exposes that span as a collection period with a start and end date. The window slides daily: the oldest day leaves, the newest arrives, and nothing flips the entire population onto the freshly shipped major on release day.

Under the old four-week cadence, a single window usually held one new Stable major plus lingering older versions. At two weeks, the same window can contain two adjacent majors — 152 and 153, for instance — while auto-update spreads through the installed base. Each major can alter paint timing, image decoding, lazy-loading heuristics or interaction scheduling on an unchanged page, so the published p75 for LCP, INP or CLS can move for reasons that never touch the origin.

Drift without a deploy

The post names three non-deploy causes that recur in agency work:

• Browser updates. Users who auto-update partway through the window contribute post-update sessions next to pre-update ones inside a single aggregate.
• Channel skew. Beta, Dev and Canary are thin slices for most retail sites, but Extended Stable cohorts can trail Stable by weeks, so a locked-down corporate audience may read a different field band than a consumer one on the same URL template.
• Traffic mix. Campaigns, geographic shifts or seasonality change which templates dominate sessions, moving origin-level LCP when a slower category listing gains share against the homepage — with no code change on either template.

The distinction the article draws is one of instruments: lab runs on a fixed URL tell you whether your deploy altered the critical path, while field CrUX tells you what Chrome users actually experienced across versions and journeys. Treating a field move as a deploy regression without first checking browser and traffic mix sends engineers digging through history for a change that was never made.

Practical guidance

The recommendations from the post are operational rather than technical. Annotate browser Stable and Beta dates on the same calendar used for application deploys, CDN rule changes and tag manager publishes. Set sample thresholds before slicing field data by exact Chrome major, because thin segments produce jumpy p75 lines that look like regressions every week. Keep unsegmented LCP, INP and CLS as the headline series in retainer reports, with browser-major slices relegated to appendix material for engineers. Compare like with like — same form factor, same URL or origin scope, same collection dates — and pair every segmented chart with an unsegmented line so leadership can see whether the whole population moved or only one slice. Scheduled lab runs act as same-week evidence that the origin itself did not change.

The post also cites performance consultant Harry Roberts, who argued in a Web-Perf Wednesday instalment that faster browser releases change the population a RUM average is drawn from, not merely the code on the server. Reporting per-major LCP figures without sample sizes, on this view, invites false alarms around each release date.

Why it matters

Faster majors are a net positive for security and platform progress, but they quietly redefine what field dashboards mean. A 28-day CrUX figure was never a same-day measurement; from September 2026 it becomes routine for that window to blend two browser generations with distinct rendering behaviour. Teams that annotate only their own releases will keep misreading population shifts as regressions, and teams slicing by Chrome major without sample thresholds will chase noise. Adding a browser-release row to the annotation calendar is a small change that pre-empts a recurring class of false alarms.