Was sich am 8. September 2026 ändert
Google hat die Umstellung am 3. März 2026 angekündigt. Der Kern in einem Satz: Ab September 2026 wechselt Chrome vom bisherigen Vier-Wochen-Takt auf einen Zwei-Wochen-Takt (Chrome for Developers). Konkret erscheinen ab der Stable-Veröffentlichung von Chrome 153 am 8. September alle zwei Wochen eine neue Beta- und eine neue Stable-Version, und zwar auf allen Plattformen - Desktop, Android und iOS (Chrome for Developers). Chrome 153 ist ausdrücklich als erste Version des neuen Takts markiert (Chrome for Developers). Die Chromium-Dokumentation ist bereits umgeschrieben und formuliert den neuen Rhythmus nicht als Plan, sondern als Zustand: Chrome liefert alle zwei Wochen eine neue Hauptversion an den Stable-Kanal (Chromium Docs).
Rechnerisch bedeutet das rund 26 statt 13 Hauptversionen im Jahr. Der Sprung fällt größer aus, als die Zahl vermuten lässt, denn er verdoppelt nicht nur die Anzahl, er verschiebt auch alle Termine: Chrome 154 wäre nach dem alten Plan am 20. Oktober 2026 erschienen, nach dem neuen kommt die Version schon am 22. September (Chrome for Developers). Wer feste Testtermine im Kalender stehen hat, findet sie ab dem Herbst an der falschen Stelle. Und wer den Aufwand für eine Prüfrunde bisher mit dreizehn Runden im Jahr kalkuliert hat, rechnet ab September mit sechsundzwanzig.
- Start: Chrome 153 geht am 8. September 2026 in den Stable-Kanal und ist die erste Version im neuen Takt (Chrome for Developers).
- Plattformen: Der Zwei-Wochen-Takt gilt für Desktop, Android und iOS gleichermaßen (Chrome for Developers).
- Beta: Eine Beta erscheint drei Wochen vor der zugehörigen Stable-Version, und Google empfiehlt ausdrücklich, damit zu testen (Chrome for Developers).
- Ohne Änderung: An den Kanälen Dev und Canary ändert sich nichts (Chrome for Developers).
- Extended Stable: Der verlängerte Kanal für verwaltete Umgebungen und für Chromium-Einbetter behält seinen Acht-Wochen-Takt (Chrome for Developers).
Die Umstellung kommt nicht allein. Chrome hat für dieselbe Zeitachse bereits eine zweite Verschärfung angekündigt, nämlich die schrittweise Warnung vor unverschlüsselten Verbindungen; wie dieser Zeitplan aussieht, steht im Beitrag zur HTTPS-Pflicht in Chrome ab Oktober 2026. Beides zusammen heißt: Im Herbst 2026 kommen sowohl mehr Versionen als auch strengere Voreinstellungen auf Websites zu, und beide Effekte treffen dieselben Seiten.
Vom Sechs-Wochen-Takt zum Zwei-Wochen-Takt
Der Abstand zwischen zwei Chrome-Versionen ist in fünfzehn Jahren dreimal kürzer geworden. Bis 2021 galt: Chrome liefert seit mehr als einem Jahrzehnt alle sechs Wochen einen neuen Meilenstein (Chromium Blog). Im März 2021 kündigte das Chromium-Team an, mit Chrome 94 im dritten Quartal 2021 auf einen Vier-Wochen-Takt zu wechseln (Chromium Blog). Im selben Zug entstand der Extended-Stable-Kanal mit Aktualisierungen alle acht Wochen (Chromium Blog). 2023 kam eine wöchentliche Sicherheitsaktualisierung hinzu, um den Abstand zwischen Lücke und Korrektur zu verkleinern, dazu eine frühe Stable-Veröffentlichung zur Verbesserung der Veröffentlichungsqualität (Chrome for Developers). Der Schritt auf zwei Wochen ist damit keine Kehrtwende, sondern der vierte Schritt in dieselbe Richtung.
| Zeitraum | Takt der Hauptversionen | Hauptversionen pro Jahr | Fenster zwischen zwei Versionen |
|---|---|---|---|
| 2010 bis 2021 | sechs Wochen | rund 9 | sechs Wochen |
| Chrome 94 bis Chrome 152 | vier Wochen | rund 13 | vier Wochen |
| ab Chrome 153, ab 8. September 2026 | zwei Wochen | rund 26 | zwei Wochen |
| Extended Stable, parallel seit 2021 | acht Wochen | rund 6 | acht Wochen |
Zwei Punkte fallen an dieser Reihe auf. Erstens ist die Verkürzung kein Ausrutscher, sondern eine Richtung: Von sechs über vier auf zwei Wochen hat sich der Abstand innerhalb von fünf Jahren gedrittelt. Zweitens wandert der Aufwand dabei vom Browser zur Website. Google sichert die eigene Qualität über den Beta-Kanal, einen gestaffelten Rollout und wöchentliche Auffrischungen des Stable-Kanals ab (Chromium Docs). Was auf der eigenen Seite passiert, prüft dagegen niemand mit. Wie sich diese Prüfung als wiederholbarer Lauf statt als Sichtkontrolle aufsetzen lässt, beschreibt der Beitrag zu synthetischen Checks im Browser-Monitoring.
Was gleich bleibt: Dev, Canary und Extended Stable
Chrome hat fünf Kanäle: Stable, Extended Stable, Beta, Dev und Canary (Chrome Enterprise Help). Von der Umstellung betroffen sind davon nur zwei. An Dev und Canary ändert sich nichts (Chrome for Developers) - wer dort testet, arbeitet mit demselben Vorlauf weiter wie bisher. Und der Extended-Stable-Kanal, 2021 für Administratoren in Unternehmen und für Chromium-Einbetter eingeführt, die zusätzliche Zeit für die Verwaltung von Aktualisierungen brauchen, behält seinen Acht-Wochen-Takt (Chrome for Developers). Diese Unterscheidung wird in der Praxis gern überlesen, weil die Ankündigung als „Chrome wird schneller" zusammengefasst wird.
Technisch entsteht Extended Stable dadurch, dass jeder vierte Meilenstein-Zweig sechs zusätzliche Wochen gepflegt wird: Wichtige Sicherheitskorrekturen werden dorthin zurückportiert, sodass alle acht Wochen ein neuer Meilenstein erscheint (Chromium Docs). Der Kanal steht allerdings nur Unternehmen unter Windows und macOS zur Verfügung und wird über Unternehmensrichtlinien aktiviert (Chromium Docs). Für eine öffentliche Website ist er damit keine Entlastung, sondern eher eine Falle: Die eigene verwaltete Flotte sieht eine Änderung im Acht-Wochen-Raster, das Publikum draußen im Zwei-Wochen-Raster. Ein Fehler, der auf den Arbeitsplatzrechnern erst in sieben Wochen ankommt, steht bei Besuchern schon in der ersten Woche auf dem Bildschirm.
Wer eine verwaltete Flotte betreibt, gewinnt mit Extended Stable Zeit - acht Wochen statt zwei (Chromium Docs). Für die eigene Website gilt das nicht: Deren Besucher kommen ganz überwiegend über den Stable-Kanal, der ab September alle zwei Wochen wechselt (Chrome for Developers). In Deutschland entfielen im Juli 2026 rund 58 Prozent der Seitenaufrufe auf Chrome (Statcounter Global Stats, Juli 2026), gefolgt von Safari mit 16,33 Prozent und Firefox mit 8,85 Prozent (Statcounter Global Stats, Juli 2026). Der Takt dieses einen Browsers bestimmt damit den größten Einzelanteil am Risiko, und die interne Testflotte ist genau der falsche Ort, um ihn zu messen.
Warum das Testfenster schrumpft
Das eigentliche Thema ist nicht der Takt, sondern die Zeitspanne zwischen zwei Gelegenheiten, an denen jemand fragt: Läuft die Seite in der aktuellen Chrome-Version noch so, wie sie soll? Diese Spanne war bisher vier Wochen lang, ab September ist sie zwei Wochen lang. Wer von Hand prüft, hat damit zwei Möglichkeiten. Entweder er halbiert das Prüfintervall und verdoppelt den Aufwand. Oder er lässt das Intervall, wie es ist, und nimmt in Kauf, dass in dieselbe Prüflücke ab Herbst zwei Versionswechsel fallen statt einem. Die Fehlerdauer bleibt in diesem zweiten Fall gleich, die Wahrscheinlichkeit eines unentdeckten Fehlers verdoppelt sich.
Die Vorwarnzeit fällt dabei nicht weg, sie wird nur enger. Eine Chrome-Beta erscheint drei Wochen vor der zugehörigen Stable-Version, und Google empfiehlt ausdrücklich, mit der Beta zu testen, um über anstehende Änderungen auf dem Laufenden zu bleiben, die eigene Seiten und Anwendungen betreffen könnten (Chrome for Developers). Drei Wochen klingen komfortabel. Im neuen Takt überlappen sich die Fenster aber: Während Meilenstein N in der Beta steht, ist N minus 1 gerade in Stable angekommen und N minus 2 noch im Rollout. Der Meilenstein verbringt insgesamt zwei Wochen im Beta-Kanal, während er stabilisiert wird (Chromium Docs). Wer Beta-Tests bisher als gelegentliche Kür behandelt hat, braucht dafür ab September einen festen Platz im Ablauf.
Nicht die Zahl der Versionen ist das Problem, sondern das Produkt aus Prüfabstand und Trefferwahrscheinlichkeit. Bei vier Wochen Takt und monatlicher Sichtprüfung fällt in jede Prüflücke im Mittel ein Versionswechsel. Bei zwei Wochen Takt und unverändertem Prüfabstand fallen zwei hinein. Der Prüfaufwand bleibt derselbe, die Zahl der ungeprüften Anlässe verdoppelt sich. Genau deshalb ist die richtige Antwort auf einen kürzeren Takt selten eine höhere Frequenz von Hand, sondern eine Prüfung, deren Kosten nicht mit der Häufigkeit steigen.
Was in einer einzelnen Version tatsächlich passieren kann, zeigt Chrome 153 selbst. Die Version stellt die XML-Verarbeitung für mehrere übliche Fälle auf eine speichersichere Rust-Implementierung um (Chrome for Developers). Sie entfernt außerdem drei Dinge: ein nicht standardisiertes Navigationsziel, die Methode document.requestStorageAccessFor und Related Website Sets, nachdem Chrome die bisherige Behandlung von Cookies aus Drittkontext beibehält (Chrome for Developers). Jede dieser Entfernungen ist für sich gut begründet und betrifft wenige Seiten. Wer betroffen ist, merkt es aber nicht an einer Meldung, sondern an einem Formular, das nicht mehr absendet, oder an einer eingebetteten Ansicht, die leer bleibt. Solche Ausfälle hinterlassen fast ausnahmslos eine Spur in der Konsole, die sich einsammeln lässt - der Weg dorthin steht im Beitrag zum Monitoring von JavaScript-Fehlern.
Der gestaffelte Rollout verwischt den Zeitpunkt
Ein zweiter Umstand macht die Sichtprüfung unzuverlässig: Eine neue Version erreicht nicht alle Nutzer am selben Tag. Die Auslieferung ist über die Zeit gestaffelt, damit früh auftretende Probleme behoben werden können, bevor sie alle Nutzer erreichen; in der Regel erreicht eine neue Version alle Nutzer innerhalb von ein bis zwei Wochen, sofern keine größeren Probleme auftreten (Chromium Docs). Im Vier-Wochen-Takt war das eine Randnotiz, weil zwischen Rollout-Ende und nächster Version noch Luft blieb. Im Zwei-Wochen-Takt bedeutet es, dass der Rollout der einen Version noch läuft, während die nächste bereits startet.
Für die Fehlersuche hat das eine unangenehme Folge. Ein Rendering-Fehler tritt nicht bei allen Besuchern gleichzeitig auf, sondern zuerst bei einem kleinen Anteil. Wer die Seite daraufhin selbst öffnet, sieht möglicherweise noch die vorherige Version und hält die Meldung für einen Einzelfall. Erst wenn der Rollout durchgelaufen ist, wird das Muster sichtbar - und dann sind Tage vergangen. Hinzu kommt, dass Stable und Extended Stable wöchentlich aufgefrischt werden und diese Auffrischungen wichtige Sicherheitskorrekturen sowie dringende Regressionskorrekturen enthalten können (Chromium Docs). Eine Änderung im Verhalten muss also nicht einmal an einem Meilensteinwechsel hängen. Wer an dieser Stelle den Zwischenspeicher in Verdacht hat, findet die Abgrenzung im Beitrag zu veralteten Inhalten nach dem Deploy.
Der Zeitplan selbst ist kein Geheimnis. Für Chrome 153 lag der Zweigpunkt am 17. August 2026, die früheste Beta am 19. August, die frühe Stable-Veröffentlichung am 26. August und der Stable-Start am 8. September (Chromium Dash). Drei Wochen nach dem Zweigpunkt geht ein Meilenstein erstmals in den Stable-Kanal (Chromium Docs). Wer diese Daten in den eigenen Kalender übernimmt, hat den Vorlauf schriftlich und kann Prüfungen an den Zweigpunkt hängen statt an ein Bauchgefühl. Die Vorbedingung dafür ist eine belastbare Liste der Seiten, die überhaupt geprüft werden sollen; wie sich diese Liste gegen das eigene Inventar abgleichen lässt, zeigt der Beitrag zur Monitoring-Abdeckung über das URL-Inventar.
Was Sie jetzt umstellen sollten
Die Umstellung verlangt keine neue Technik, sondern eine andere Aufteilung des vorhandenen Aufwands. Vier Schritte tragen dabei den Großteil der Wirkung, und drei davon lassen sich einmalig einrichten statt alle zwei Wochen neu abzuarbeiten.
Feste Kalendertage passen ab September nicht mehr. Drei Wochen nach dem Zweigpunkt geht der Meilenstein erstmals in Stable (Chromium Docs) - das ist der verlässliche Anker. Wer den Zweigpunkt als Auslöser nimmt, prüft im richtigen Abstand, ohne die Termine jedes Quartal nachzuziehen.
Eine Beta erscheint drei Wochen vor der Stable-Version, und die Empfehlung, damit zu testen, ist ausdrücklich Teil der Ankündigung (Chrome for Developers). In verwalteten Umgebungen ist der übliche Ansatz, fünf Prozent der Nutzer auf dem Beta-Kanal zu halten, um eine Vorschau auf die kommende Stable-Version zu bekommen (Chrome Enterprise Help).
Ein Mensch übersieht eine um zwölf Pixel verrutschte Schaltfläche, ein Bildvergleich nicht. Wie sich zwei Stände derselben Seite maschinell gegeneinander halten lassen und welche Bereiche man dabei ausblendet, beschreibt der Beitrag zu Website-Änderungen per Bildvergleich.
Startseite und Impressum überstehen fast jeden Versionswechsel. Anmeldung, Warenkorb und Formularversand sind die Stellen, an denen ein geändertes Browserverhalten wehtut. Wie sich solche Wege einmal aufzeichnen und danach automatisch nachfahren lassen, steht im Beitrag zu aufgezeichneten Browser-Flows.
Wichtig ist dabei die Reihenfolge. Zuerst steht die Liste der Seiten und Wege, die geprüft werden sollen, dann der automatische Lauf, dann die Meldung. Wer mit der Meldung anfängt, bekommt Alarme ohne Bezugspunkt. Für die Nachvollziehbarkeit über mehrere Zyklen hinweg lohnt sich außerdem eine fortlaufende Aufzeichnung der Unterschiede: Ein Screenshot- und Changelog-Verlauf macht aus einzelnen Befunden eine Zeitreihe, in der sich ein schleichender Effekt über mehrere Versionen hinweg überhaupt erst erkennen lässt. Wie ein solcher Verlauf aufgebaut ist, beschreibt der Beitrag zum automatischen Website-Changelog.
Ein Testplan für den Zwei-Wochen-Takt
Aus den vier Bausteinen ergibt sich ein Ablauf, der sich an den Zyklus hängt statt an den Kalender. Er ist bewusst knapp gehalten: Was in jedem Zyklus wiederholt wird, muss in Minuten erledigt sein, sonst hält es sechsundzwanzig Runden im Jahr nicht durch.
| Schritt | Zeitpunkt im Zyklus | Was dabei geprüft wird |
|---|---|---|
| Vorschau | Zweigpunkt, rund drei Wochen vor Stable | Änderungs- und Entfernungshinweise der kommenden Version sichten |
| Beta-Lauf | Beta-Start, drei Wochen vor Stable | Anmeldung, Formularversand und Bezahlweg in der Beta durchlaufen |
| Stable-Tag | Tag des Stable-Starts | Bildvergleich der wichtigsten Seiten, Konsolenfehler einsammeln |
| Rollout-Mitte | rund eine Woche nach Stable | Fehlerraten und Formularabbrüche gegen die Vorwoche halten |
| Abschluss | ein bis zwei Wochen nach Stable | Befunde festhalten; der nächste Zyklus läuft zu diesem Zeitpunkt bereits |
Der letzte Punkt ist der ungewohnte: Im Zwei-Wochen-Takt gibt es keinen ruhigen Moment zwischen zwei Zyklen mehr. Der Abschluss des einen fällt mit dem Beta-Start des nächsten zusammen. Das ist kein Argument gegen den Plan, aber ein Argument dafür, jede Runde so schmal wie möglich zu halten. Ein Nebeneffekt lohnt sich dabei besonders: Wer ohnehin in jedem Zyklus die Antwortkopfzeilen mitliest, sieht auch, welche Versionsangaben eine Seite nach außen gibt - warum das eine eigene Betrachtung wert ist, steht im Beitrag zu Versionsbannern in Server-Kopfzeilen.
Grenzen: Was der neue Takt nicht erklärt
Ein kürzerer Browsertakt erklärt nicht jeden Fehler, der zeitlich in seine Nähe fällt. Die häufigste Fehldiagnose besteht darin, eine Abweichung dem Versionswechsel zuzuschreiben, obwohl an demselben Tag ein eigener Deploy lief, ein Zwischenspeicher ablief oder ein eingebundener Fremdinhalt seine Fassung wechselte. Vier Einschränkungen gehören deshalb zur ehrlichen Einordnung.
- Der Takt betrifft Chrome, nicht die Verfügbarkeit von Funktionen im Web. Eine Funktion gilt erst dann als neu verfügbar, wenn sie von allen Kernbrowsern unterstützt wird und damit interoperabel ist (web.dev). Als breit verfügbar gilt sie 30 Monate nach diesem Datum (web.dev). Schnellere Chrome-Versionen verkürzen diese Wartezeit nicht.
- Andere Browser haben eigene Zeitpläne. In Deutschland kamen im Juli 2026 rund 16,33 Prozent der Seitenaufrufe von Safari (Statcounter Global Stats, Juli 2026). Ein Test gegen Chrome allein deckt einen großen, aber nicht den gesamten Teil des Publikums ab.
- Der gestaffelte Rollout verwischt die Zuordnung. Solange eine neue Version erst einen Teil der Nutzer erreicht hat (Chromium Docs), sagt ein einzelner nachgestellter Aufruf wenig darüber aus, was die Mehrheit gerade sieht.
- Monitoring zeigt das Ergebnis, nicht die Ursache. Ein Bildvergleich meldet, dass sich etwas verändert hat. Ob die Ursache im Browser, im eigenen Deploy oder bei einem eingebundenen Anbieter liegt, entscheidet erst der Abgleich mit dem eigenen Änderungsprotokoll.
Diese Grenzen sprechen nicht gegen die Automatisierung, sie bestimmen nur, was man von ihr erwarten darf. Ein Lauf, der alle zwei Wochen dieselben Wege in einem echten Browser nachfährt und den Bildstand mit dem vorherigen vergleicht, liefert die Beobachtung. Die Zuordnung bleibt Handarbeit, dauert aber Minuten statt Tage, wenn Zeitpunkt und Umfang der Abweichung feststehen. Wer das ausprobieren möchte, richtet den ersten Flow im kostenlosen Test ein oder lässt sich in einer persönlichen Demo zeigen, wie Bildvergleich, Konsolenfehler und Meldung in einem Lauf zusammenkommen.
Dieser Artikel basiert auf Daten von Chrome for Developers, dem Chromium Blog, den Chromium Docs und Statcounter Global Stats. Die genannten Zahlen beziehen sich auf den Stand der jeweiligen Veröffentlichung.