Build Not yet confirmed elsewhere 1 publisher2 min readPublished Aug 28, 2026, 12:36 AM PDT

Chrome's two-week release cycle will stack three browser majors inside one CrUX window

Chrome starts shipping Stable every fortnight in September 2026 while CrUX keeps averaging 28 days of sessions, so a field LCP move can be version mix rather than anything your team deployed. Label the browser.

The Engineer · Build desk

How we use AI Send a correction

Illustration accompanying Chrome's two-week release cycle will stack three browser majors inside one CrUX window — Generated illustration

What happened

Google said in March 2026 that Chrome will leave its four-week Stable cadence for a two-week one, beginning with Chrome 153 Stable on 8 September 2026 and promoting Beta and Stable fortnightly on Desktop, Android and iOS.
The published milestone table has Chrome 153 branching on 25 August 2026, reaching public Stable on 8 September, and Chrome 154 arriving on Stable on 22 September.
Extended Stable stays on an eight-week cycle for enterprises that need a longer validation window before a major reaches their fleet.
CrUX is unchanged: every figure in PageSpeed Insights field sections is a 28-day rolling average of opted-in Chrome sessions, returned with a collectionPeriod carrying firstDate and endDate.
Firefox is running a similar cadence experiment around Firefox 155 from 1 September 2026, according to community coverage linked from CSS Wizardry Web-Perf Wednesday 006.

Why it matters

decision Whoever owns the performance timeline now has to add browser rows next to app deploys, CDN config, tag manager edits and RUM changes, because the release clock is no longer slow enough to ignore.
cost An unlabelled browser release is paid for in engineering hours: someone bisects a month of commits looking for a regression that was never shipped.
constraint Per-version attribution is capped by sample size, so monthly reports will have to argue from a blended aggregate they cannot decompose into the majors that produced it.
precedent If Firefox's trial holds, fortnightly majors become the cross-engine norm and Chrome-only annotation stops covering the problem.

Fourteen days separate Chrome 153 Stable from Chrome 154 Stable ^[20]. Put that against the field window. CrUX advances one day at a time, oldest day out and newest day in, and there is no switch that flips the whole population onto the new major on release day ^[8]. The window has no opinion about your release calendar. Two release boundaries therefore fit inside 28 days, which means sessions from three consecutive majors can land in the same p75 ^[19]. The dev.to post that works this through describes the blend as two adjacent majors ^[1]; two is the floor, because people who auto-update mid-window contribute post-update sessions beside pre-update ones in one aggregate ^[9].

What a Stable release changes is the measurement path: paint timing, image decoding, lazy-loading heuristics, interaction scheduling, on a page nobody touched ^[9]. Change the version mix inside the window and the published p75 moves while your bundles are byte-identical to last month ^[10]. The same post reads an amber band after a quiet week as population mix first: who updated, which channel they run, how fast auto-update spread ^[18].

The instinct is to slice the data by exact Chrome major and settle the argument. The post says check sample thresholds before you do ^[15]. The arithmetic says why: at a fortnightly cadence each major owns 14 days of the window rather than 28, so the sessions attributable to a version halve before you have also split by device, country and template ^[23].

Eight weeks against two is four majors of drift ^[21], which is how a retail origin and a locked-down corporate fleet come to read different field bands on the same URL template ^[11].

Annotation alone will not close this. Origin-level field LCP also moves when the homepage's share of traffic falls and a slower category listing gains, with no code change on either template ^[12]. So the division of labour has to be explicit: a lab run on a fixed URL answers whether your deploy changed the critical path, and CrUX answers what Chrome users experienced across versions and journeys ^[13]. Scheduled runs in the same week are the evidence that the origin held still ^[16].

Chrome's branch cut for 153 lands 14 days before its public Stable ^[22], so the vendor's own validation window now equals its shipping interval. Smaller, more frequent releases remain the right call for security and platform velocity ^[2]. The compression just propagates outward to everyone whose reporting cycle is still monthly.

What to watch

Whether the published dates hold, or Chrome 153 Stable slips from 8 September 2026 and resets the interval arithmetic.
Whether Firefox's experiment around 155 becomes its standing cadence after 1 September 2026 or is rolled back.
Whether enterprise fleets actually stay on the eight-week Extended Stable cycle once Stable ships twice as often.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence58
Adoption25
Hype gap+20
Incentives60
Confidence55

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
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.
ReportedSupported2 sources— create a free account to open them View cited source
[2]
Smaller, more frequent browser releases are good for security and platform velocity, but 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 the origin.
ReportedSupported2 sources— create a free account to open them View cited source
[3]
CrUX data is always a 28-day rolling average of real Chrome sessions.
ReportedSupportedView cited source
[4]
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, with Beta and Stable promotions arriving every two weeks on Desktop, Android and iOS.
ReportedSupportedView cited source
[5]
Extended Stable keeps an eight-week cycle for enterprises that need longer validation windows.
ReportedSupportedView cited source
[6]
Under the new table in Google's post, Chrome 153 Stable cuts on 25 August 2026 with public Stable on 8 September 2026, while Chrome 154 Stable follows on 22 September 2026.
ReportedSupportedView cited source
[7]
At any query, PageSpeed Insights and the CrUX API return a collectionPeriod with firstDate and endDate covering the blended window, according to the CrUX API documentation.
ReportedSupportedView cited source
[8]
The CrUX window advances daily: the oldest day drops and the newest day enters. There is no switch that flips the entire population to only Chrome 153 sessions on Stable release day.
ReportedSupportedView cited source
[9]
A new Stable or Extended Stable release changes paint timing, image decoding, lazy-loading heuristics or interaction scheduling for the same page, and users who auto-update mid-window contribute post-update sessions beside pre-update sessions in one aggregate.
ReportedSupportedView cited source
[10]
If the mix of Chrome versions, devices, networks and journeys inside the window changes, the published p75 can move even when HTML, CSS and JavaScript bundles are byte-identical to last month.
ReportedSupportedView cited source
[11]
Enterprise Extended Stable cohorts can lag Stable by weeks, so a retail origin and a locked-down corporate audience can read different field bands on the same URL template.
ReportedSupportedView cited source
[12]
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.
ReportedSupportedView cited source
[13]
Lab runs on a fixed URL answer whether a deploy changed the critical path; field CrUX answers what Chrome users actually experienced across versions and journeys.
ReportedSupportedView cited source
[14]
The post recommends release annotations kept on the same calendar as app, CDN, tag manager and RUM changes.
ReportedSupportedView cited source
[15]
The post recommends checking sample thresholds before slicing field data by exact Chrome major.
ReportedSupportedView cited source
[16]
The post recommends scheduled lab runs as same-week proof that the origin did not change.
ReportedSupportedView cited source
[17]
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.
ReportedSupportedView cited source
[18]
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.
ReportedSupportedView cited source
[19]
A 28-day window at a 14-day release interval contains two release boundaries, so sessions from three consecutive Chrome majors can appear in one aggregate.
DerivedSupported2 sources— create a free account to open them
[20]
Consecutive Stable majors 153 and 154 are 14 days apart.
DerivedSupported1 source— create a free account to open them
[21]
An eight-week Extended Stable cycle against a two-week Stable cadence is four Stable majors of drift.
DerivedSupported1 source— create a free account to open them
[22]
Chrome 153's branch cut is 14 days before its public Stable date.
DerivedSupported1 source— create a free account to open them
[23]
Each major's exclusive share of the field window halves, from 28 days to 14, so per-version session counts fall by half for the same traffic.
DerivedSupported1 source— create a free account to open them
[24]
Firefox is running a similar experiment around Firefox 155 from 1 September 2026, per community coverage linked from CSS Wizardry Web-Perf Wednesday 006.
ReportedInsufficientView cited source
[25]
Performance teams that only annotated application releases in 2025 will need browser rows on the same calendar in 2026.
ReportedInsufficientView cited source

Sources

1 independent publisher whose own reporting we read for this story.

dev.to
1 article · August 27, 2026
When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For anyone who owns the front end, the useful part is mechanical and checkable today: CrUX blends 28 days of sessions and advances a day at a time, so the fortnightly Stable channel Google set out for 8 September 2026 puts two adjacent majors — arguably three, once you count both release boundaries — inside a single published number. The practical consequence the dev.to author draws out is that per-version slices halve in size, which is what turns a version breakdown from a diagnosis into a noise generator. What no one here supplies is the magnitude: not one measured LCP or INP delta between two Chrome majors appears in this reporting, so you can label the browser but you cannot yet say how much it is worth.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence58: 0100
Documented plumbing, single messenger
Two very different grades of evidence sit in the same post. The CrUX side is verifiable against public documentation — the 28-day rolling window, the daily advance, the collectionPeriod dates any caller can read back — and it does the real analytical work. The Chrome side is a faithful-looking but unchecked summary of Google's March 2026 announcement, and the Firefox parallel is a single clause pointing at community coverage of a newsletter. Nowhere does this reporting measure what it warns about: no version-over-version Web Vitals delta, no worked field example, and the promised per-major sample cut-off trails off mid-sentence.
Adoption25: 0100
Calendar set, nothing landed yet
The only hard adoption signal is a schedule. Chrome's fortnightly Stable had not shipped when this was published in late August 2026, so no field window yet spans the new cadence and no published p75 has moved for the reason described. On the practice side there is nothing at all: not one team is shown adding browser rows to its release calendar or setting a per-version sample floor. What raises this above zero is the reach of the trigger — an auto-updating browser calendar applies to every Chrome origin whether or not anyone prepares for it.
Hype gap+20: −100 understated0 aligned+100 overstated
Headline runs ahead of the body
The mechanism is real and modestly stated inside the post — 'the same window can include two adjacent majors' — but the framing around it promises three stacked majors as a settled outcome, which is arithmetic on the fortnightly interval rather than anything Google or the body says. Add a certainty of tense ('will stack') for an effect that had not yet appeared in any field data, and no bound on how large the version-to-version difference actually is, and the packaging leans harder than the reporting. Not inflation so much as rounding up in the author's own favour.
Incentives60: 0100
Agency post with a service attached
The author is transparent about the commercial position and that transparency is the point to note: the piece speaks of 'agency tickets' and 'rules we use in client work', and routes readers to the same shop's Core Web Vitals and synthetic-versus-RUM guides. Its argument also happens to favour first-party RUM — yours, with your segments and alert rules — over the public Chrome dataset, which is exactly the sort of instrumentation work a performance consultancy sells. None of that makes the mechanism wrong; the documented parts stand on their own. It does mean the urgency, and the choice to leave the per-version sample cut-off unpublished, should be read as coming from someone with billable follow-up.
Confidence55: 0100
Sure of the mechanism, silent on the size
We can be fairly confident that a fortnightly Stable channel and a 28-day rolling average interact the way this describes — the two inputs are documented and the consequence is close to arithmetic. Confidence drops on everything a reader would act on: how far a field number actually moves between majors, whether Google adjusts the window in response, and whether any of the recommended annotation discipline is being adopted. One publisher, one voice, one unverified summary of the schedule.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Core Web Vitals field dataFollow
Browser release cadenceFollow
Web Performance MeasurementFollow
Observability and Alert DesignFollow

Entities

Google Chrome Follow
Chrome User Experience ReportFollow
PageSpeed Insights Follow
Google Follow
Chrome Extended StableFollow
Core Web Vitals Follow
Firefox Follow
CSS WizardryFollow