Browsernes udgivelseskalender ændrede sig i denne uge, og den ændrede sig for alle på én gang. Mozilla udsendte Firefox 155 den 1. september, to uger tidligere end den oprindelige dato 15. september, som den første udgivelse i en ny to-ugers kadence. Google rykkede Chrome 154 op i Beta-kanalen den 2. september efter sin egen nye tidsplan, og Chrome 153 Stable lander den 8. september. Microsoft var først: Edge 152 den 27. august var virksomhedens første Stable-udgivelse i to-ugers rytmen.
Siden 2021 har de tre browsere, der bærer størstedelen af verdens webtrafik, hver især udsendt en ny hovedversion cirka hver fjerde uge. Fra denne måned halveres det interval.
Hvem annoncerede hvad, og hvornår
Intet af dette kom uanmeldt, men de tre annonceringer var spredt over seks måneder, og derfor har den samlede effekt været nem at overse.
Google offentliggjorde planen på Chrome for Developers-bloggen den 3. marts. Fra og med Chrome 153 udkommer en ny Beta og en ny Stable hver anden uge på Desktop, Android og iOS. Dev- og Canary-kanalerne ændres ikke. De ugentlige sikkerhedsopdateringer mellem milepælene fortsætter. Extended Stable, den kanal de fleste virksomhedsadministratorer låser deres maskinparker til, bliver på en otte-ugers cyklus. Bloggens egen tabel viser, hvor meget kalenderen har rykket sig: Chrome 153 Stable skulle have været ude den 22. september og udkommer nu den 8. september; Chrome 154 flyttes fra den 20. oktober til den 22. september.
Microsoft fulgte efter den 11. juni. Fra Edge 152 den 27. august går Stable-kanalen over til to uger, og virksomheden var tydelig om, hvad det betyder i omfang: hver Stable-udgivelse indeholder cirka halvdelen af ændringerne i den gamle månedlige. Extended Stable beholder sin otte-ugers rytme og tager nu hver fjerde udgivelse med, så 156, 160 og 164 er de næste Extended Stable-milepæle. Microsofts råd til organisationer er at lade en pilotgruppe køre på Beta eller Enterprise Preview, så problemer viser sig, før Stable når produktionen.
Mozilla kom sidst og var mest forsigtig. Sylvestre Ledru, Mozillas Director of Engineering, skrev til dev-platform-listen i juli, at virksomheden var „planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.“ På dansk: i gang med at planlægge at flytte Firefox Desktop og Android fra en 4-ugers udgivelseskadence til en 2-ugers udgivelseskadence fra september 2026. The Register omtalte ændringen den 17. juli og bemærkede, at Mozilla beskriver den som et eksperiment, der kan blive rullet tilbage. Mozilla Support Blog bekræftede datoerne den 19. august: Firefox 155 den 1. september som den første to-ugers udgivelse, med det udtrykkelige forbehold, at en hurtigere kadence „doesn’t mean Firefox will ship twice as many features.“ På dansk: ikke betyder, at Firefox vil udsende dobbelt så mange funktioner. Firefox ESR, det årlige spor med lang support, berøres ikke; The Register oplyser, at Firefox 153 bliver næste ESR-basis.
Hvad der faktisk udkom i denne uge
Firefox 155 er en nyttig test af, om „halvdelen af ændringerne, dobbelt så ofte“ holder. Udgivelsesnoterne fra den 1. september nævner en udvidelse af det AI-assisterede Smart Window til USA, Canada og Frankrig, en tæller for blokerede trackere i adresselinjen, mulighed for at omarrangere containere i Indstillinger samt rettelser af afbrydelser i baggrundslyd og en langvarig Linux-fejl, der forhindrede maskiner i at gå i dvale efter en browsersession.
De udviklerrettede ændringer, som er dokumenteret på MDN, er den del, der rører ved websites. CSS-funktionen attr() virker nu i enhver egenskab med typede værdier og fallbacks, ikke kun i content. To nye CSS-funktioner, progress() og alpha(), ankommer sammen med font-width som det nye navn for font-stretch. JavaScript får Promise.allKeyed() og Promise.allSettledKeyed(). Mislykkede modulimporter caches ikke længere, så et script, der fejlede på et ustabilt netværk, kan lykkes ved næste forsøg. På netværkssiden implementerer Firefox 155 Happy Eyeballs version 3 til parallel forbindelsesopbygning over IPv6 og IPv4 og forhandler QUIC version 2 til HTTP/3.
Det er ikke dramatisk, og det er netop pointen. Googles erklærede begrundelse er, at „the smaller scope of these releases minimizes disruption and simplifies post-release debugging.“ På dansk: det mindre omfang af disse udgivelser minimerer forstyrrelser og forenkler fejlsøgning efter udgivelsen. Og Firefox 155 ligner præcis den slags udgivelse: en håndfuld platformstilføjelser, en håndfuld rettelser, ude af døren på to uger.
Hvorfor alle tre skiftede i samme sæson
Google og Microsoft deler Chromium-motoren, så da Chromes tidsplan ændrede sig, ville Edges følge med. Mozillas begrundelse var, som The Register beskriver den, mere hjemlig: færdige funktioner havde ventet i ugevis på det næste udgivelsestog, og en uforudsigelig række punktudgivelser ind imellem var sværere at planlægge efter end en fast 14-dages rytme.
Chrome gik fra seks-ugers til fire-ugers udgivelser i 2021 og tilføjede ugentlige sikkerhedsopdateringer i 2023; to uger er det næste skridt i samme retning.
Hvad det betyder for din forretning
Dit website møder nu en ny browsermotor cirka hver 14. dag. For de fleste websites er det usynligt, og sådan bør det forblive. Browserleverandørerne kører kompatibilitetstest netop for, at et versionsspring ikke ødelægger sider. Hvis dit website afhænger af en bestemt leverandørspecifik adfærd, en polyfill, der læser versionsnumre, eller en aldrende tredjeparts-widget, er vinduet mellem „en ændring lander i Beta“ og „en ændring er foran dine kunder“ skrumpet fra cirka fire uger til tre.
Beta-kanalen er det tidlige varslingssystem, og den er gratis. Chrome udsender hver Beta tre uger før den tilsvarende Stable. Microsofts råd til virksomheder gælder lige så godt for et marketingsite: hold én maskine, eller én browserprofil, på Beta, og klik dig igennem din checkout, dine formularer og dit bookingflow hver 14. dag. Det er billigere end at høre om en ødelagt betalingsknap fra en kunde.
Hold øje med et spring i dine analysedata, ikke en tendens. Hvis en browseropdatering ødelægger noget, sker det på en dato. Segmentér konverteringsraten efter browser og version i dit analyseværktøj, og kig efter et pludseligt fald, der begynder på en udgivelsesdag og kun rammer én browser. Det mønster er fingeraftrykket af en kompatibilitetsfejl.
Hold dine egne afhængigheder opdaterede. De websites, der kæmper med hurtige browsercyklusser, er som regel dem, der kører et JavaScript-framework, et CMS eller et plugin, som er flere år bagud. Leverandørerne af disse værktøjer tester mod aktuelle browsere, ikke mod deres eget produkt fra flere år tilbage. Det er den vedligeholdelsesrytme, vi bygger ind i hvert website, vi leverer: en gennemgang af afhængigheder efter en fast plan, ikke når noget går i stykker.
Virksomhedernes maskinparker er stort set upåvirkede, og det betyder noget, hvis du sælger til dem. Både Chrome og Edge beholder Extended Stable på otte uger, og Firefox ESR forbliver årlig. Hvis dine kunder er erhvervsbrugere på administrerede enheder, vil de se færre motorændringer end den brede offentlighed, og funktioner, der udkommer i en to-ugers Stable-udgivelse, kan være to måneder om at nå dem. Byg ikke en landingsside op omkring en helt ny CSS-funktion til et publikum, der først ser den i november.
Vores læsning er, at det er gode nyheder for webbet og en smule mere arbejde for dem, der vedligeholder websites på det. Mindre og hyppigere udgivelser er nemmere at fejlsøge og hurtigere at rette. Prisen er, at den gamle vane med at tjekke browserkompatibilitet „cirka en gang om måneden“ ikke længere passer til virkeligheden. Sæt en påmindelse hver 14. dag i kalenderen; det er det meste af arbejdet.
