The browser release calendar changed this week, and it changed for everyone at once. Mozilla shipped Firefox 155 on 1 September, two weeks earlier than its original 15 September date, as the first release of a new two-week cadence. Google promoted Chrome 154 to the Beta channel on 2 September under its own new schedule, and Chrome 153 Stable lands on 8 September. Microsoft went first: Edge 152 on 27 August was its first two-week Stable release.
Since 2021 the three browsers that carry most of the world’s web traffic have each shipped a major version roughly every four weeks. From this month, that interval halves.
Who announced what, and when
None of this arrived unannounced, but the three announcements were spread across six months, which is why the combined effect has been easy to miss.
Google published the plan on the Chrome for Developers blog on 3 March. Starting with Chrome 153, a new Beta and a new Stable ship every two weeks on Desktop, Android and iOS. Dev and Canary channels do not change. Weekly security refreshes between milestones continue. Extended Stable, the channel most enterprise administrators pin their fleets to, stays on an eight-week cycle. The blog’s own table shows how far the calendar moved: Chrome 153 Stable was due on 22 September and now ships on 8 September; Chrome 154 moves from 20 October to 22 September.
Microsoft followed on 11 June. From Edge 152 on 27 August the Stable channel moves to two weeks, and the company was explicit about what that means in volume terms: each Stable release carries roughly half the changes of the old monthly one. Extended Stable keeps its eight-week rhythm and now picks up every fourth release, so 156, 160 and 164 are the next Extended Stable milestones. Microsoft’s advice to organisations is to pilot a group on Beta or Enterprise Preview so problems surface before Stable reaches production.
Mozilla was last, and the most cautious. Sylvestre Ledru, Mozilla’s Director of Engineering, told the dev-platform list in July that the company was “planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.” The Register reported the change on 17 July and noted that Mozilla describes it as an experiment it may reverse. The Mozilla Support Blog confirmed the dates on 19 August: Firefox 155 on 1 September as the first two-week release, with the explicit caveat that a faster cadence “doesn’t mean Firefox will ship twice as many features.” Firefox ESR, the annual long-support track, is not affected; The Register reports that Firefox 153 is the next ESR base.
What actually shipped this week
Firefox 155 is a useful test of whether “half the changes, twice as often” holds. Its release notes on 1 September list an expansion of the AI-assisted Smart Window to the USA, Canada and France, a tracker-blocking count in the address bar, container reordering in Settings, and fixes for background-audio interruptions and a long-standing Linux bug that stopped machines from sleeping after a browsing session.
The developer-facing changes recorded on MDN are the part that touches websites. The CSS attr() function now works in any property with typed values and fallbacks, not only in content. Two new CSS functions, progress() and alpha(), arrive alongside font-width as the new name for font-stretch. JavaScript gains Promise.allKeyed() and Promise.allSettledKeyed(). Failed module imports are no longer cached, so a script that failed on a flaky network can succeed on retry. On the network side, Firefox 155 implements Happy Eyeballs version 3 for IPv6 and IPv4 connection racing and negotiates QUIC version 2 for HTTP/3.
That is not dramatic, and that is the point. Google’s stated rationale is that “the smaller scope of these releases minimizes disruption and simplifies post-release debugging,” and Firefox 155 looks like exactly that kind of release: a handful of platform additions, a handful of fixes, out the door in two weeks.
Why all three moved in the same season
Google and Microsoft share the Chromium engine, so once Chrome’s schedule changed, Edge’s was going to follow. Mozilla’s reasoning, as The Register reports, was closer to home: finished features had been waiting weeks for the next train, and an unpredictable series of dot releases in between was harder to plan around than a fixed fortnightly rhythm.
Chrome moved from six-week to four-week releases in 2021 and added weekly security updates in 2023; two weeks is the next step in the same direction.
What it means for your business
Your site now meets a new browser engine roughly every fortnight. For most sites this is invisible, and it should stay invisible. Browser vendors run compatibility testing precisely so that a version bump does not break pages. If your site depends on a particular vendor-specific behaviour, a polyfill that sniffs version numbers, or an ageing third-party widget, the window between “a change lands in Beta” and “a change is in front of your customers” has shrunk from about four weeks to three.
The Beta channel is the early-warning system, and it is free. Chrome ships each Beta three weeks before the matching Stable. Microsoft’s advice to enterprises applies just as well to a marketing site: keep one machine, or one browser profile, on Beta and click through your checkout, your forms and your booking flow once a fortnight. That is cheaper than learning about a broken payment button from a customer.
Watch your analytics for a step, not a trend. If a browser update breaks something, it does so on a date. Segment conversion rate by browser and version in your analytics, and look for a sudden drop that starts on a release day and affects only one browser. That pattern is the fingerprint of a compatibility bug.
Keep your own dependencies current. The sites that struggle with fast browser cycles are usually the ones running a JavaScript framework, CMS or plugin several years behind. Vendors of those tools test against current browsers, not against their own product from several years ago. This is the maintenance rhythm we build into every website we deliver: a dependency review on a fixed schedule, not when something breaks.
Enterprise fleets are largely unaffected, and that matters if you sell to them. Both Chrome and Edge keep Extended Stable at eight weeks, and Firefox ESR stays annual. If your customers are corporate users on managed devices, they will see fewer engine changes than the general public, and features that ship in a two-week Stable release may take two months to reach them. Do not build a landing page around a brand-new CSS feature for an audience that will not see it until November.
Our reading is that this is good news for the web and mildly more work for the people who maintain sites on it. Smaller, more frequent releases are easier to debug and faster to fix. The cost is that the old habit of checking browser compatibility “every month or so” no longer lines up with reality. Put a fortnightly reminder in the calendar; that is most of the job.
