Chrome streamt HTML jetzt standardmäßig außer der Reihe. Safari und Firefox ziehen beide mit.

Seit dem 30. Juni hat jeder Chrome-Nutzer auf Desktop, Android und ChromeOS eine neue HTML-Fähigkeit bekommen, ganz ohne Flag, ohne Opt-in, ohne Ankündigung, die die meisten von ihnen je zu Gesicht bekommen. Sie lässt eine Seite sofort alles anzeigen, was fertig ist, und den langsamen Teil später genau an der richtigen Stelle nachliefern, ohne eine einzige Zeile JavaScript. Interessant ist nicht die Funktion selbst. Interessant ist, dass Safari und Firefox beide signalisiert haben, sie ebenfalls unterstützen zu wollen — genau das entscheidet, ob aus einem Browser-Trick eine echte Plattformfähigkeit des Webs wird.

Das Problem, das damit wirklich gelöst wird

HTML wurde schon immer von oben nach unten geladen, in der Reihenfolge, in der es geschrieben wurde. Das funktioniert, solange kein Abschnitt langsam ist: eine Produktgalerie, die eine ungecachte API abfragt, ein Kommentarblock, der auf eine Datenbankabfrage wartet, irgendetwas, das der Server nicht sofort liefern kann. Im alten Modell blockiert dieser langsame Block den Dokumentfluss und hält alles auf, was danach geschrieben wurde, selbst Inhalte, die eine Sekunde nach Ladebeginn hätten angezeigt werden können.

Entwickler umgehen das seit Jahren mit JavaScript: die langsamen Daten separat abrufen und dann ins DOM einfügen, sobald sie da sind. Das funktioniert, bedeutet aber, für eine im Kern sehr einfache Idee von Hand Fetch-Logik, DOM-Manipulation und Ladezustände zu schreiben: zeigen, was fertig ist, und später nachbessern, was es noch nicht war.

Was tatsächlich ausgeliefert wurde

Chromes offizielle Ankündigung, veröffentlicht am 19. Mai 2026, mit den beiden unten beschriebenen API-Teilen.

Das Chrome-Engineering-Team nennt die Funktion Declarative Partial Updates, ausgeliefert in zwei Teilen.

Der erste Teil erlaubt es, HTML ganz ohne JavaScript außer der Reihe zu streamen. Man setzt einen Marker an die Stelle, an der der Inhalt irgendwann erscheinen soll, geschrieben als Processing Instruction: <?marker name="gallery">. Später im selben HTML-Stream, sobald der langsame Inhalt fertig ist, wird ein <template for="gallery"> mit dem echten Markup gesendet, und der Browser setzt es an die richtige Stelle. Es gibt auch eine Placeholder-Variante, <?start name="gallery">Lädt…<?end>, die einen Zwischeninhalt zeigt, bis das echte Template eintrifft. Nichts davon braucht ein Script-Tag. Der Browser liest Marker und Templates, während sie hereinströmen, und übernimmt das Einfügen selbst.

Der zweite Teil ist eine Reihe neuer JavaScript-Methoden für die Fälle, die wirklich ein Skript brauchen: setHTML(), appendHTML(), prependHTML(), beforeHTML(), afterHTML(), replaceWithHTML(), dazu Streaming-Varianten davon (streamHTML(), streamAppendHTML() und so weiter) für Inhalte, die schrittweise statt auf einmal eintreffen. Jede hat eine *Unsafe-Variante, die das HTML-Escaping überspringt, für Fälle, in denen der Inhalt bereits bereinigt wurde und die Kosten eines erneuten Escapings vermieden werden sollen.

Es läuft bereits, und genau das ist bemerkenswert

Die offiziellen Versionshinweise zu Chrome 150, die das stabile Datum vom 30. Juni 2026 bestätigen und Out-of-Order-Streaming unter den ausgelieferten DOM-/HTML-Änderungen auflisten.

Für die üblichen Zeitpläne von Browser-Standards ging das schnell. In Chrome 148, im Mai, erreichte es hinter einem Flag die Entwicklertests. In Chrome 150, das am 30. Juni stabil wurde, war es für alle aktiviert, ganz ohne Flag. Die offiziellen Versionshinweise zu Chrome 150 listen es direkt auf: Unterstützung für <template for> und die Processing-Instruction-Bereiche (<?marker>, <?start>, <?end>), die „bestehende Teile des Dokuments ohne JS aktualisieren”.

Dieses Tempo kam mit echter Testarbeit, nicht nur mit einem stillen Umschalten. Das Chromium-Team ließ die Änderung über einen 50-Prozent-Finch-Trial im Beta-Kanal laufen, bevor sie in den stabilen Kanal überging, und sie ist von der gemeinsamen Web-Platform-Test-Suite abgedeckt, mit der Browserhersteller die Kompatibilität zwischen den Engines prüfen. Ein echtes Risiko bekam in diesem Prozess gezielte Aufmerksamkeit: Processing Instructions sind eine alte, weitgehend ungenutzte Ecke von HTML, und sie für einen neuen Zweck wiederzubeleben barg das Risiko, mit seltenen Legacy-Inhalten zu kollidieren, die diese Syntax bereits nutzten. Die Gegenmaßnahmen: bestimmte Instruktionsnamen und Zeichen, von denen bekannt war, dass bestehende Inhalte sich darauf verließen, wurden ausgeschlossen.

Was wichtiger ist als das Release-Datum

Dass ein einzelner Browser eine Funktion hinzufügt, ist Routine und für sich genommen keine Nachricht. Was diese Funktion unterscheidet, ist, wer sonst noch dahintersteht. WebKit, die Engine hinter Safari, hat seine Unterstützung für Out-of-Order-Streaming erklärt. Mozillas Gecko-Team hat ebenfalls eine offene, positiv formulierte Standardposition dazu, als „vorgeschlagene Unterstützung” formuliert statt als feste Zusage, aber ohne die Ablehnung, an der die meisten Chromium-Vorschläge sonst scheitern, bevor sie irgendwohin führen. Drei unabhängige Browser-Engines, die auf demselben Mechanismus konvergieren, das macht aus einem Chrome-Trick ein dauerhaftes Stück der Web-Plattform — der Unterschied zwischen einer Fähigkeit, auf die Entwickler das nächste Jahrzehnt bauen können, und einer, die still verschwindet, sobald das Chrome-Team zur nächsten Idee weiterzieht.

Wem das wirklich hilft

Der ehrliche Vorbehalt, der in einer Feature-Ankündigung am leichtesten unter den Tisch fällt: Das hilft nur Seiten, bei denen der Server manche Abschnitte fertig rendern kann, bevor andere fertig sind. Eine klassische serverseitig gerenderte Seite, bei der ein Framework jede Dateneinheit im Voraus abruft und dann eine vollständige Seite auf einmal rendert, hat nichts, was sich verspätet nachliefern ließe. Es gibt keinen langsamen, vom Rest isolierten Block, weil bereits alles abgerufen wurde, bevor das HTML überhaupt zu entstehen begann.

Der Nutzen konzentriert sich auf komponentenorientierte Architekturen: React Server Components, Streaming-SSR im Next.js-Stil oder jedes Setup, in dem unabhängige Seitenabschnitte sich jeweils in ihrem eigenen Tempo auflösen können. Chromes eigene Beispiele gehen in dieselbe Richtung: Seiten im Island-Architektur-Muster, bei denen ein Widget langsamer ist als der Rest, Inhalte, die vom Abschluss eines Datenbankaufrufs abhängen, Priorisierung des HTML oberhalb der Bildschirmkante, während ein sekundärer Block hinterherhinkt, Navigationsaktualisierungen im Single-Page-App-Stil ohne ein Routing-Framework mitzuliefern, das Einfügen gemeinsam genutzter Elemente wie einer Fußzeile, nachdem der Hauptinhalt bereits gerendert wurde.

Was das für dich bedeutet

Nichts davon erfordert eine sofortige Entscheidung. Wenn dein Stack bereits HTML in unabhängigen, asynchron auflösenden Teilen erzeugt, lohnt es sich, das jetzt zu testen, die Syntax ist schlank genug für einen Prototyp an einem Nachmittag, und der Fallback für Browser ohne Unterstützung besteht einfach darin, es nicht zu verwenden. Wenn dein Stack eine klassische, serverseitig gerenderte Seite ist, die eine Seite aus einem einzigen Datenabruf zusammensetzt, besteht keine Dringlichkeit: Die Funktion hat dieser Architektur nichts zu bieten, und das ändert sich erst, wenn sich die Architektur selbst ändert.

FAQ

Muss ich in Chrome ein Flag aktivieren, um das zu nutzen? Nein. Es ist seit Chrome 150 standardmäßig aktiviert, das am 30. Juni 2026 in den stabilen Kanal ging. Die Flag-Version war nur während der Entwicklertestphase in Chrome 148 nötig.

Funktioniert das schon in Safari und Firefox? Noch nicht in stabiler, ausgelieferter Form, aber beide Engines haben positive Standardpositionen eingenommen. WebKit hat seine Unterstützung für Out-of-Order-Streaming erklärt, und Mozillas Gecko-Team hat eine offene, wohlwollende Position dazu. Behandle es als Fähigkeit mit echter Cross-Browser-Dynamik, nicht als Chrome-exklusives Feature, aber prüfe die tatsächliche Unterstützung jeder Engine, bevor du dich in Produktion darauf verlässt.

Brauche ich JavaScript, um das zu nutzen? Für den Grundfall nicht. Das Duo <?marker>/<template for> für Out-of-Order-Streaming funktioniert mit reinem HTML. JavaScript ist nur für die neueren dynamischen Einfüge-Methoden nötig, etwa setHTML() oder streamAppendHTML(), die Fälle wie das Aktualisieren von Inhalten nach dem initialen Laden ohne vollständige Navigation abdecken.

Wird das Frameworks wie React oder htmx für diese Art von Aufgabe ersetzen? Nicht sofort und nicht vollständig. Es ersetzt einen Teil der manuellen Verdrahtung, die Entwickler heute von Hand schreiben oder an eine Bibliothek delegieren, aber Frameworks bringen Datenabruf, State-Management und Komponentenmodelle mit, die diese Funktion nicht zu lösen versucht. Es ist ein Plattform-Baustein, auf dem Frameworks aufbauen können, kein Framework-Ersatz.

Gibt es einen echten Performance-Gewinn, oder ist das vor allem Komfort für Entwickler? Beides. Der Komfort ist real: keine handgeschriebene Fetch-dann-Einfügen-Logik in JavaScript mehr für den Grundfall. Der Performance-Gewinn ist ebenfalls real, hängt aber von der Architektur ab: Er hilft nur, wenn eine Seite echte unabhängige Abschnitte hat, die sich unterschiedlich schnell auflösen, was in komponentenorientierten Frameworks üblich und im klassischen serverseitigen Rendering mit einem einzigen Datenabruf weitgehend abwesend ist.