Der Release-Kalender der Browser hat sich diese Woche geändert, und zwar für alle gleichzeitig. Mozilla hat Firefox 155 am 1. September veröffentlicht, zwei Wochen früher als ursprünglich für den 15. September geplant, als erste Version eines neuen Zweiwochenrhythmus. Google hat Chrome 154 am 2. September nach seinem eigenen neuen Zeitplan in den Beta-Kanal befördert, und Chrome 153 Stable erscheint am 8. September. Microsoft war als Erstes dran: Edge 152 am 27. August war die erste Stable-Version im Zweiwochentakt.
Seit 2021 haben die drei Browser, über die der größte Teil des weltweiten Webverkehrs läuft, jeweils etwa alle vier Wochen eine neue Hauptversion ausgeliefert. Ab diesem Monat halbiert sich dieser Abstand.
Wer was wann angekündigt hat
Nichts davon kam unangekündigt, aber die drei Ankündigungen verteilten sich über sechs Monate, weshalb der Gesamteffekt leicht zu übersehen war.
Google hat den Plan am 3. März im Chrome for Developers blog veröffentlicht. Ab Chrome 153 erscheinen alle zwei Wochen eine neue Beta und ein neues Stable für Desktop, Android und iOS. Die Kanäle Dev und Canary ändern sich nicht. Die wöchentlichen Sicherheitsaktualisierungen zwischen den Meilensteinen laufen weiter. Extended Stable, der Kanal, an den die meisten Unternehmensadministratoren ihre Geräteflotten binden, bleibt im Achtwochenzyklus. Die Tabelle im Blogbeitrag zeigt, wie weit sich der Kalender verschoben hat: Chrome 153 Stable war für den 22. September vorgesehen und erscheint nun am 8. September; Chrome 154 rückt vom 20. Oktober auf den 22. September vor.
Microsoft folgte am 11. Juni. Ab Edge 152 am 27. August wechselt der Stable-Kanal auf zwei Wochen, und das Unternehmen hat klar benannt, was das für den Umfang bedeutet: Jede Stable-Version enthält etwa halb so viele Änderungen wie die bisherige monatliche. Extended Stable behält seinen Achtwochenrhythmus und übernimmt nun jede vierte Version, sodass 156, 160 und 164 die nächsten Extended-Stable-Meilensteine sind. Organisationen rät Microsoft, eine Pilotgruppe auf Beta oder Enterprise Preview zu setzen, damit Probleme auffallen, bevor Stable in der Produktion ankommt.
Mozilla war als Letztes dran und am vorsichtigsten. Sylvestre Ledru, Director of Engineering bei Mozilla, teilte der dev-platform-Liste im Juli mit, das Unternehmen sei „planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026.“ Auf Deutsch: Man plane, Firefox Desktop und Android ab September 2026 von einem Vierwochen- auf einen Zweiwochenrhythmus umzustellen. The Register berichtete am 17. Juli über die Änderung und merkte an, dass Mozilla sie als Experiment bezeichnet, das wieder zurückgenommen werden könnte. Der Mozilla Support Blog bestätigte die Termine am 19. August: Firefox 155 am 1. September als erste Zweiwochenversion, mit dem ausdrücklichen Hinweis, dass ein schnellerer Rhythmus „doesn’t mean Firefox will ship twice as many features.“ Auf Deutsch: nicht bedeutet, dass Firefox doppelt so viele Funktionen ausliefert. Firefox ESR, die jährliche Langzeitschiene, ist nicht betroffen; laut The Register ist Firefox 153 die nächste ESR-Basis.
Was diese Woche tatsächlich erschienen ist
Firefox 155 ist ein brauchbarer Test dafür, ob „halb so viele Änderungen, doppelt so oft“ aufgeht. Die Versionshinweise vom 1. September nennen die Ausweitung des KI-gestützten Smart Window auf die USA, Kanada und Frankreich, einen Zähler für blockierte Tracker in der Adressleiste, das Umsortieren von Containern in den Einstellungen sowie Korrekturen für Unterbrechungen bei Hintergrund-Audio und einen lange bestehenden Linux-Fehler, der Rechner nach einer Browsersitzung nicht mehr in den Ruhezustand gehen ließ.
Die auf MDN dokumentierten Änderungen für Entwickler sind der Teil, der Websites berührt. Die CSS-Funktion attr() funktioniert jetzt in jeder Eigenschaft mit typisierten Werten und Fallbacks, nicht mehr nur in content. Zwei neue CSS-Funktionen, progress() und alpha(), kommen zusammen mit font-width als neuem Namen für font-stretch. JavaScript erhält Promise.allKeyed() und Promise.allSettledKeyed(). Fehlgeschlagene Modulimporte werden nicht mehr zwischengespeichert, sodass ein Skript, das in einem instabilen Netz gescheitert ist, beim erneuten Versuch gelingen kann. Auf Netzwerkseite implementiert Firefox 155 Happy Eyeballs Version 3 für das parallele Aufbauen von IPv6- und IPv4-Verbindungen und handelt QUIC Version 2 für HTTP/3 aus.
Das ist nicht spektakulär, und genau darum geht es. Googles erklärte Begründung lautet, „the smaller scope of these releases minimizes disruption and simplifies post-release debugging.“ Auf Deutsch: Der kleinere Umfang dieser Versionen minimiert Störungen und vereinfacht die Fehlersuche nach der Veröffentlichung. Firefox 155 sieht genau nach so einer Version aus: eine Handvoll Plattformergänzungen, eine Handvoll Korrekturen, in zwei Wochen ausgeliefert.
Warum alle drei in derselben Saison umgestellt haben
Google und Microsoft teilen sich die Chromium-Engine; sobald sich Chromes Zeitplan geändert hatte, würde Edge nachziehen. Mozillas Begründung lag, wie The Register berichtet, näher am eigenen Haus: Fertige Funktionen warteten wochenlang auf den nächsten Zug, und eine unvorhersehbare Reihe von Punktversionen dazwischen ließ sich schlechter planen als ein fester Zweiwochenrhythmus.
Chrome wechselte 2021 von Sechs- auf Vierwochenversionen und ergänzte 2023 wöchentliche Sicherheitsupdates; zwei Wochen sind der nächste Schritt in dieselbe Richtung.
Was das für Ihr Unternehmen bedeutet
Ihre Website trifft jetzt etwa alle zwei Wochen auf eine neue Browser-Engine. Für die meisten Websites ist das unsichtbar, und so sollte es bleiben. Browserhersteller betreiben Kompatibilitätstests gerade deshalb, damit ein Versionssprung keine Seiten kaputtmacht. Wenn Ihre Website von einem bestimmten herstellerspezifischen Verhalten abhängt, von einem Polyfill, das Versionsnummern abfragt, oder von einem in die Jahre gekommenen Drittanbieter-Widget, ist das Zeitfenster zwischen „eine Änderung landet in Beta“ und „eine Änderung steht vor Ihren Kunden“ von rund vier Wochen auf drei geschrumpft.
Der Beta-Kanal ist das Frühwarnsystem, und er ist kostenlos. Chrome liefert jede Beta drei Wochen vor dem zugehörigen Stable aus. Microsofts Rat an Unternehmen gilt ebenso für eine Marketing-Website: Halten Sie einen Rechner oder ein Browserprofil auf Beta und klicken Sie sich alle zwei Wochen durch Ihren Checkout, Ihre Formulare und Ihre Buchungsstrecke. Das ist günstiger, als von einem Kunden von einem defekten Bezahlbutton zu erfahren.
Achten Sie in Ihren Analytics auf eine Stufe, nicht auf einen Trend. Wenn ein Browserupdate etwas kaputtmacht, tut es das an einem bestimmten Datum. Segmentieren Sie die Conversion-Rate in Ihren Analytics nach Browser und Version und suchen Sie nach einem plötzlichen Einbruch, der an einem Release-Tag beginnt und nur einen Browser betrifft. Dieses Muster ist der Fingerabdruck eines Kompatibilitätsfehlers.
Halten Sie Ihre eigenen Abhängigkeiten aktuell. Die Websites, die mit schnellen Browserzyklen zu kämpfen haben, sind meist diejenigen, deren JavaScript-Framework, CMS oder Plugin mehrere Jahre hinterherhinkt. Die Anbieter dieser Werkzeuge testen gegen aktuelle Browser, nicht gegen ihr eigenes Produkt von vor einigen Jahren. Das ist der Wartungsrhythmus, den wir in jede Website einbauen, die wir liefern: eine Prüfung der Abhängigkeiten nach festem Zeitplan, nicht erst, wenn etwas kaputtgeht.
Unternehmensflotten sind weitgehend nicht betroffen, und das zählt, wenn Sie an sie verkaufen. Chrome und Edge belassen Extended Stable bei acht Wochen, und Firefox ESR bleibt jährlich. Wenn Ihre Kunden Firmennutzer auf verwalteten Geräten sind, sehen sie weniger Engine-Änderungen als die breite Öffentlichkeit, und Funktionen aus einer Zweiwochen-Stable-Version können zwei Monate brauchen, bis sie dort ankommen. Bauen Sie keine Landingpage um eine brandneue CSS-Funktion herum für ein Publikum, das sie erst im November zu sehen bekommt.
Unsere Lesart: Das ist eine gute Nachricht für das Web und etwas mehr Arbeit für diejenigen, die Websites darauf betreiben. Kleinere, häufigere Versionen sind leichter zu debuggen und schneller zu korrigieren. Der Preis dafür ist, dass die alte Gewohnheit, die Browserkompatibilität „ungefähr einmal im Monat“ zu prüfen, nicht mehr zur Realität passt. Setzen Sie eine zweiwöchentliche Erinnerung in den Kalender; das ist der größte Teil der Arbeit.
