De releasekalender van de browsers is deze week veranderd, en voor iedereen tegelijk. Mozilla bracht Firefox 155 uit op 1 september, twee weken eerder dan de oorspronkelijke datum van 15 september, als eerste release in een nieuwe tweewekelijkse cadans. Google promoveerde Chrome 154 op 2 september naar het Beta-kanaal volgens zijn eigen nieuwe schema, en Chrome 153 Stable verschijnt op 8 september. Microsoft ging voorop: Edge 152 op 27 augustus was zijn eerste tweewekelijkse Stable-release.
Sinds 2021 brachten de drie browsers die het grootste deel van het wereldwijde webverkeer verwerken elk ongeveer om de vier weken een nieuwe hoofdversie uit. Vanaf deze maand wordt dat interval gehalveerd.
Wie kondigde wat aan, en wanneer
Niets hiervan kwam onaangekondigd, maar de drie aankondigingen waren verspreid over zes maanden, en daardoor was het gecombineerde effect makkelijk te missen.
Google publiceerde het plan op 3 maart op de Chrome for Developers-blog. Vanaf Chrome 153 verschijnen elke twee weken een nieuwe Beta en een nieuwe Stable op Desktop, Android en iOS. De kanalen Dev en Canary veranderen niet. De wekelijkse beveiligingsupdates tussen de mijlpalen door gaan gewoon door. Extended Stable, het kanaal waarop de meeste enterprise-beheerders hun vloot vastzetten, blijft op een cyclus van acht weken. De tabel in de blogpost zelf laat zien hoe ver de kalender is opgeschoven: Chrome 153 Stable stond gepland voor 22 september en verschijnt nu op 8 september; Chrome 154 verhuist van 20 oktober naar 22 september.
Microsoft volgde op 11 juni. Vanaf Edge 152 op 27 augustus gaat het Stable-kanaal over op twee weken, en het bedrijf was expliciet over wat dat qua omvang betekent: elke Stable-release bevat ongeveer de helft van de wijzigingen van de oude maandelijkse release. Extended Stable behoudt zijn ritme van acht weken en neemt voortaan elke vierde release over, zodat 156, 160 en 164 de volgende Extended Stable-mijlpalen zijn. Het advies van Microsoft aan organisaties is om een groep als pilot op Beta of Enterprise Preview te zetten, zodat problemen aan het licht komen voordat Stable de productie bereikt.
Mozilla was de laatste, en de voorzichtigste. Sylvestre Ledru, Director of Engineering bij Mozilla, schreef in juli op de dev-platform-lijst dat het bedrijf bezig was met “planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.” In het Nederlands: het plan om Firefox Desktop en Android vanaf september 2026 van een releasecadans van 4 weken naar een cadans van 2 weken te brengen. The Register berichtte op 17 juli over de wijziging en merkte op dat Mozilla het omschrijft als een experiment dat het kan terugdraaien. De Mozilla Support Blog bevestigde de data op 19 augustus: Firefox 155 op 1 september als eerste tweewekelijkse release, met de uitdrukkelijke kanttekening dat een hogere cadans “doesn’t mean Firefox will ship twice as many features.” In het Nederlands: niet betekent dat Firefox twee keer zoveel functies zal uitbrengen. Firefox ESR, het jaarlijkse kanaal met lange ondersteuning, blijft buiten schot; The Register meldt dat Firefox 153 de volgende ESR-basis wordt.
Wat er deze week daadwerkelijk is uitgebracht
Firefox 155 is een nuttige test of “de helft van de wijzigingen, twee keer zo vaak” standhoudt. De releasenotes van 1 september noemen een uitbreiding van het AI-ondersteunde Smart Window naar de VS, Canada en Frankrijk, een teller van geblokkeerde trackers in de adresbalk, het herschikken van containers in de Instellingen, en fixes voor onderbrekingen van achtergrondaudio en voor een hardnekkige Linux-bug die verhinderde dat machines na een browsersessie in slaapstand gingen.
De wijzigingen voor ontwikkelaars die op MDN zijn vastgelegd, zijn het deel dat websites raakt. De CSS-functie attr() werkt nu in elke eigenschap, met getypeerde waarden en fallbacks, niet alleen in content. Twee nieuwe CSS-functies, progress() en alpha(), komen samen met font-width als nieuwe naam voor font-stretch. JavaScript krijgt Promise.allKeyed() en Promise.allSettledKeyed(). Mislukte module-imports worden niet langer gecachet, zodat een script dat op een onbetrouwbaar netwerk faalde bij een nieuwe poging kan slagen. Aan de netwerkkant implementeert Firefox 155 Happy Eyeballs versie 3 voor het parallel opzetten van IPv6- en IPv4-verbindingen en onderhandelt het QUIC versie 2 voor HTTP/3.
Dat is niet spectaculair, en dat is precies het punt. De door Google opgegeven reden is dat “the smaller scope of these releases minimizes disruption and simplifies post-release debugging.” In het Nederlands: de kleinere omvang van deze releases beperkt verstoringen tot een minimum en vereenvoudigt het debuggen na de release. Firefox 155 ziet er precies uit als zo’n release: een handvol platformtoevoegingen, een handvol fixes, binnen twee weken de deur uit.
Waarom alle drie in hetzelfde seizoen overstapten
Google en Microsoft delen de Chromium-engine, dus zodra het schema van Chrome veranderde, zou dat van Edge volgen. De redenering van Mozilla lag, zoals The Register meldt, dichter bij huis: afgeronde functies wachtten wekenlang op de volgende trein, en een onvoorspelbare reeks tussentijdse puntreleases was lastiger in te plannen dan een vast tweewekelijks ritme.
Chrome ging in 2021 van releases om de zes weken naar om de vier weken en voegde in 2023 wekelijkse beveiligingsupdates toe; twee weken is de volgende stap in dezelfde richting.
Wat het betekent voor uw bedrijf
Uw site krijgt nu ongeveer elke twee weken met een nieuwe browserengine te maken. Voor de meeste sites is dat onzichtbaar, en dat hoort zo te blijven. Browserleveranciers doen compatibiliteitstests juist zodat een versiesprong geen pagina’s breekt. Als uw site afhankelijk is van een specifiek leveranciersgebonden gedrag, van een polyfill die versienummers uitleest of van een verouderde widget van derden, dan is de periode tussen “een wijziging landt in Beta” en “een wijziging staat voor uw klanten” gekrompen van ongeveer vier weken naar drie.
Het Beta-kanaal is het vroegtijdige waarschuwingssysteem, en het is gratis. Chrome brengt elke Beta drie weken vóór de bijbehorende Stable uit. Het advies van Microsoft aan ondernemingen geldt net zo goed voor een marketingsite: houd één machine, of één browserprofiel, op Beta en loop eens per twee weken uw checkout, uw formulieren en uw boekingsflow door. Dat is goedkoper dan van een klant horen dat de betaalknop niet werkt.
Let in uw analytics op een sprong, niet op een trend. Als een browserupdate iets breekt, gebeurt dat op een datum. Segmenteer de conversieratio in uw analytics per browser en versie, en zoek naar een plotselinge daling die op een releasedag begint en slechts één browser treft. Dat patroon is de vingerafdruk van een compatibiliteitsbug.
Houd uw eigen afhankelijkheden actueel. De sites die moeite hebben met snelle browsercycli zijn meestal de sites die draaien op een JavaScript-framework, CMS of plug-in van enkele jaren terug. De leveranciers van die tools testen tegen actuele browsers, niet tegen hun eigen product van enkele jaren geleden. Dit is het onderhoudsritme dat wij inbouwen in elke website die wij opleveren: een controle van de afhankelijkheden op een vast schema, niet pas wanneer er iets kapotgaat.
Enterprise-vloten blijven grotendeels buiten schot, en dat is van belang als u aan hen verkoopt. Zowel Chrome als Edge houden Extended Stable op acht weken, en Firefox ESR blijft jaarlijks. Als uw klanten zakelijke gebruikers op beheerde apparaten zijn, zien zij minder enginewijzigingen dan het grote publiek, en functies die in een tweewekelijkse Stable-release verschijnen kunnen er twee maanden over doen om hen te bereiken. Bouw geen landingspagina rond een gloednieuwe CSS-functie voor een publiek dat die pas in november te zien krijgt.
Onze lezing is dat dit goed nieuws is voor het web en iets meer werk voor de mensen die er sites op onderhouden. Kleinere, frequentere releases zijn makkelijker te debuggen en sneller te repareren. De prijs is dat de oude gewoonte om browsercompatibiliteit “ongeveer elke maand” te controleren niet meer strookt met de werkelijkheid. Zet een tweewekelijkse herinnering in de agenda; dat is het grootste deel van het werk.
