Ab dem 8. September 2026 führt Chrome 153 einen neuen Veröffentlichungsrhythmus ein: eine stabile Version alle zwei Wochen statt alle vier. Die im März von Google angekündigte Änderung betrifft Desktop, Android und iOS und mischt den Testkalender der Web-Teams neu.
Was sich am 8. September ändert
Chrome 153 markiert den Wechsel zu einem Zwei-Wochen-Zyklus. Version 154 folgt am 22. September, 155 am 6. Oktober und so weiter: rund sechsundzwanzig stabile Versionen pro Jahr statt der dreizehn des Monatsrhythmus. Der Beta-Kanal zieht mit, jede Beta erscheint drei Wochen vor der zugehörigen Stable. Der Kanal Extended Stable behält seinen Acht-Wochen-Zyklus für Parks, die Stabilität über Aktualität stellen.
| Version | Kanal | Datum |
|---|---|---|
| Chrome 153 | Stable | 8. September 2026 |
| Chrome 154 | Stable | 22. September 2026 |
| Chrome 155 | Stable | 6. Oktober 2026 |
| Extended Stable | Verwaltete Parks | Acht-Wochen-Zyklus bleibt |
Warum Google das Tempo erhöht
Die Logik ist die kleiner Lose. Engere Releases transportieren jeweils weniger Änderungen, was die Regressionsfläche bei jedem Schritt verringert und die Zeit zwischen der Entwicklung einer Funktion und ihrer Verfügbarkeit verkürzt. Sicherheitskorrekturen, Leistungsgewinne und neue APIs kommen früher, ohne den „großes Update“-Effekt des Monatszyklus. Der Schritt setzt einen 2023 mit wöchentlichen Sicherheitsupdates begonnenen Weg fort.
Den Code an eine Chrome-Versionsnummer zu binden, war nie eine gute Idee; bei sechsundzwanzig Releases pro Jahr wird es untragbar.
Feature-Erkennung wird zur einzig tragfähigen Strategie
Die Verdopplung der Versionen macht das Auslesen der Versionsnummer (Version Sniffing) noch anfälliger, als es ohnehin war. Die gute Praxis besteht darin, die tatsächliche Verfügbarkeit einer API oder einer Eigenschaft zu prüfen statt der Engine-Version. Dieselben Reflexe, die für die Einführung von Container Queries oder die Migration zu htmx 4.0 gelten, greifen hier: die Fähigkeit testen, einen Rückfall vorsehen, nie eine Nummer voraussetzen.
// Détecter la capacité, pas la version du navigateur
if (CSS.supports('container-type: inline-size')) {
document.documentElement.classList.add('has-container-queries');
}
if ('URLPattern' in globalThis) {
const route = new URLPattern({ pathname: '/articles/:id' });
// routage côté client sans dépendance
}
// Anti-pattern : ne jamais faire ceci
// const version = navigator.userAgent.match(/Chrome\/(\d+)/);
// if (Number(version?.[1]) >= 153) { /* ... */ }Monitoring und Tests anpassen
Für Teams geht es nicht darum, jeder Version zu folgen, sondern eine Routine einzurichten. Tests im Beta-Kanal verschaffen drei Wochen Vorlauf, um eine Verhaltensänderung zu erkennen, bevor sie die Nutzer erreicht. Das Verfolgen von Funktionen läuft über die Chrome Status Roadmap und das Chromium-Dashboard, die Änderungen Schritt für Schritt ankündigen. Die vom Browser gelieferten Sicherheits-Header, etwa die im Leitfaden zur Content-Security-Policy beschriebenen, entwickeln sich ebenfalls von Version zu Version: sie fortlaufend zu prüfen erspart böse Überraschungen.
Achtung. Über Extended Stable verwaltete Unternehmensparks bleiben bei einem Acht-Wochen-Zyklus: eine nur auf der öffentlichen Stable getestete Website kann sich bei diesen Nutzern anders verhalten. Für die betroffenen Zielgruppen sollte mindestens eine Testumgebung an Extended Stable ausgerichtet bleiben.
Das Wichtigste in Kürze
Chrome veröffentlicht ab dem 8. September alle zwei Wochen eine stabile Version, rund sechsundzwanzig pro Jahr, wobei die Beta drei Wochen vorausläuft und Extended Stable seinen Acht-Wochen-Rhythmus behält. Die praktische Folge passt in einen Satz: Feature-Erkennung und Tests im Beta-Kanal ersetzen das manuelle Verfolgen der Versionsnummern endgültig.
In der Praxis sehe ich noch viel Code, der „vorsichtshalber“ eine Versionsnummer prüft. Dieser Wechsel auf zwei Wochen ist die Gelegenheit, diese toten Zweige ein für alle Mal auszuräumen: sie haben nie etwas geschützt und altern jetzt doppelt so schnell. Meine einzige echte Gewohnheit seit Jahren ist eine an die CI angebundene Beta-Umgebung, die Regressionen vor den Nutzern sichtbar macht. Sie kostet wenig und verändert alles. Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im Chrome-for-Developers-Blog, Get features faster with Chrome’s two-week release cycle.
