Deklarative partielle Updates

Barry Pollard

Noam Rosenthal

Veröffentlicht: 19. Mai 2026, zuletzt aktualisiert: 8. September 2026

Das Web hat sich längst von dem statischen, dokumentbasierten Medium entfernt, als das es begann. Moderne, umfangreiche Web-Apps werden von allen aus vielen Gründen verwendet, z. B. zur Kommunikation, zum Kauf von Produkten, zum Konsum von Rich Content und zur Verwaltung unseres komplexen Lebens.

HTML wird trotz aller Fortschritte immer noch von oben nach unten ausgeliefert, ohne Rücksicht darauf, wann Inhalte bereit sind oder wann der Nutzer sie aufruft. Mit CSS können Sie die Reihenfolge von Inhalten ändern, was jedoch oft erhebliche Auswirkungen auf die Barrierefreiheit hat. Mit JavaScript können Sie das DOM über verschiedene APIs bearbeiten, um sich etwas von dieser Einschränkung zu befreien. Dazu ist jedoch oft eine ausführliche Syntax oder die Erstellung von DOM-Bäumen erforderlich, die in HTML eingefügt werden müssen.

Die Leistung ist im Web aufgrund der Client-Server-Architektur des Mediums von entscheidender Bedeutung. Um dies zu umgehen, werden jedoch häufig suboptimale Entscheidungen getroffen, was die Leistung verlangsamt. Dazu gehört, dass Sie warten, bis die gesamte Seite bereit ist, oder ein umfangreiches Framework verwenden, um Komponenten asynchron bereitzustellen. Die Beliebtheit von JavaScript-Frameworks zeigt, dass Webentwickler ein komponentenbasiertes Modell dem starren Dokumentmodell des Webs vorziehen.

Das Chrome-Team hat sich dieses Problems angenommen und entwickelt unter dem Namen Declarative Partial Updates (Deklarative partielle Updates) neue Ergänzungen für die Webplattform.

Die ersten beiden neuen API-Sets erleichtern die Bereitstellung von HTML auf weniger lineare Weise, entweder in beliebiger Reihenfolge im HTML-Dokument selbst oder durch einfachere Möglichkeiten, HTML dynamisch in bestehende Dokumente einzufügen, indem neue JavaScript-APIs verwendet werden. Es sind auch Polyfills verfügbar, mit denen Sie diese neuen APIs sofort verwenden können, auch in Browsern, die sie noch nicht unterstützen.

Streaming in beliebiger Reihenfolge

Die erste Gruppe von Änderungen umfasst neue Streaming-APIs für Daten, die nicht in der richtigen Reihenfolge eingehen, die Platzhalter für Verarbeitungsanweisungen und das HTML-Element <template> mit dem Attribut for verwenden. Beispiel:

<div>
  <?marker name="placeholder">
</div>

...

<template for="placeholder">
  Here is some <em>HTML content</em>!
</template>

Verarbeitungsanweisungen gibt es in XML schon lange, in HTML wurden sie jedoch als Kommentare behandelt und ignoriert. Mit dieser neuen API ändert sich das und es werden Verarbeitungsanweisungen in HTML eingeführt. Wenn der Browser beispielsweise die <?marker name="placeholder">-Verarbeitungsanweisung sieht, passiert nicht sofort etwas – wie bisher –, aber sie kann später referenziert werden.

Das <template>-Element mit dem for-Attribut sucht nach den entsprechenden Verarbeitungsanweisungen mit einem name-Attribut und ersetzt den Inhalt. In diesem Fall sieht das DOM nach dem Parsen so aus (einige Unterschiede bei den Leerzeichen werden ignoriert):

<div>
  Here is some <em>HTML content</em>!
</div>

Neben dem Attribut <?marker> für Ersetzungen gibt es auch die Bereichsmarkierungen <?start> und <?end>, mit denen temporäre Platzhalterinhalte angezeigt werden können, bevor die Vorlage verarbeitet wird:

<div>
  <?start name="another-placeholder">
  Loading…
  <?end>
</div>

...

<template for="another-placeholder">
  Here is some <em>HTML content</em>!
</template>

In diesem Fall wird ein Loading…-String angezeigt, bis das <template> zu sehen ist. Dann wird der String durch den neuen Inhalt ersetzt.

Es ist auch möglich, Verarbeitungsanweisungen in Vorlagen einzufügen, um mehrere Aktualisierungen zu ermöglichen:

<ul id="results">
  <?start name="results">
  Loading…
  <?end>
</ul>

...

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>

...

<template for="results">
  <li>Result Two</li>
  <?marker name="results">
</template>

...

Nach dem Parsen und Verarbeiten sieht das HTML so aus:

<ul id="results">
  <li>Result One</li>
  <li>Result Two</li>
  <?marker name="results">
</ul>

Mit der abschließenden Verarbeitungsanweisung am Ende für den Fall, dass dem Dokument später weitere <template for="results">-Platzhalter hinzugefügt werden.

Warum Verarbeitungsanweisungen anstelle von Standard-HTML-Elementen?

Dies ist eine häufige Frage für Nutzer, die diese API zum ersten Mal verwenden. Es wird empfohlen, <slot>- oder sogar <template>-Elemente zu verwenden. In einer ersten Version dieses Vorschlags wurden Standard-HTML-Elemente verwendet. Im Laufe der Designentwicklung wurde jedoch auf Verarbeitungsanweisungen umgestellt. Mit Verarbeitungsanweisungen kann das Patchen erfolgen, ohne dass sich dies auf das DOM auswirkt. So kann es im <head> verwendet werden, z. B. für <title>-Aktualisierungen, oder sogar in anderen Elementen wie <table>, um beispielsweise optionale zusätzliche Zeilen hinzuzufügen.

Obwohl die Syntax vielen Webentwicklern nicht vertraut ist, bieten Verarbeitungsanweisungen eine viel größere Flexibilität und es besteht eine geringere Wahrscheinlichkeit von Problemen mit der Abwärtskompatibilität. Sie werden bereits in XML verwendet und sind dank dieses Vorschlags nun Teil des HTML-Standards.

Demo

In diesem Video wird eine einfache Fotoalbumanwendung mit Streaming-HTML implementiert:

Sowohl der Status als auch die Fotos werden nach dem ersten Layout in den HTML-Code gestreamt.

Anwendungsfälle

Es gibt viele Anwendungsfälle für dieses HTML-Patching außerhalb der Reihenfolge in Verbindung mit Streaming-HTML:

• Inselarchitektur: Ein gängiges Muster, das durch Frameworks wie Astro bekannt wurde, ist die Inselarchitektur, bei der Komponenten unabhängig voneinander auf statischem HTML gerendert werden. Mit der <template for> API können statische Inhalte direkt in HTML auf ähnliche Weise verarbeitet werden. JavaScript-Frameworks können dies auch für interaktivere Islands oder zum Verarbeiten von Komponenten verwenden.
• Inhalte bereitstellen, sobald sie fertig sind. Dank dieser Inselarchitektur können Inhalte gestreamt werden, sobald sie bereit sind, anstatt auf Inhalte zu warten, die eine zusätzliche Verarbeitung erfordern, z. B. eine Datenbanksuche. Viele Plattformen ermöglichen zwar das Streamen von HTML, aber die sequenzielle Natur von HTML führt dazu, dass Inhalte oft zurückgehalten werden oder komplexe JavaScript-DOM-Manipulationen erforderlich sind. Sie können jetzt die statischen Inhalte während des Wartens ausliefern und dann am Ende des HTML-Streams teurere und dynamische Inhalte einfügen.
• HTML kann in der optimalen Reihenfolge für die Seitenaufbauleistung bereitgestellt werden. Sie können die Bestellung sogar noch ändern, wenn sie bereits abgeschlossen ist. Megamenüs sind beispielsweise ein häufiges Navigationsfeature, das viel HTML enthält, das der Nutzer erst sieht, wenn die Seite interaktiv wird. Dieser große HTML-Abschnitt kann später im HTML-Dokument bereitgestellt werden, um wichtigeres HTML zu priorisieren, das für den anfänglichen Seitenaufbau erforderlich ist. Die Reihenfolge ist bei HTML kein Hindernis mehr.

Dies sind nur einige Anwendungsfälle. Wir sind gespannt, wofür Entwickler diese neue API verwenden werden.

Einschränkungen und Besonderheiten

Für die API gelten einige Einschränkungen und Besonderheiten, die Sie beachten sollten:

• Aus Sicherheitsgründen kann <template for> Verarbeitungsanweisungen nur innerhalb desselben übergeordneten Elements aktualisieren. Wenn Sie <template for> direkt dem <body>-Element hinzufügen, hat es Zugriff auf das gesamte Dokument (einschließlich des <head>).
• Die Verarbeitungsanweisung <?end> ist optional. Wenn sie fehlt, wird der Inhalt zwischen dem <?start>-Element und dem Ende des enthaltenden Elements ersetzt.
• Wenn Sie Verarbeitungsanweisungen verschieben, nachdem ein <template for> mit dem Streaming begonnen hat, kann das auch unerwartete Folgen haben, da der neue Inhalt weiterhin an den alten Speicherort gestreamt wird.
• Wenn Sie <template for> dynamisch mit einer Methode wie setHTML oder der Eigenschaft innerHTML einfügen, ist das „übergeordnete Element“ der Vorlage beim Parsen ein Zwischenfragment des Dokuments. Das bedeutet, dass durch das Einfügen von HTML mit diesen Methoden kein vorhandenes DOM geändert werden kann und das Patchen „in place“ innerhalb des Fragments erfolgt. Beim Streamen mit Methoden wie streamHTMLUnsafe (wird gleich behandelt) gibt es jedoch kein Zwischenfragment, sodass die Vorlagen vorhandene Inhalte ersetzen können.

Standardisierungsstatus

Das Attribut <template for> ist Teil des HTML-Standards, wird aber noch nicht von allen Browsern unterstützt.

Mögliche zukünftige Ergänzungen

Folgende potenzielle Ergänzungen werden derzeit in Betracht gezogen:

• Clientseitige Includes: Beispiel: <template for="footer" src="/partials/footer.html"> oder auch ohne Patching <template src="/partials/footer.html">. Weitere Informationen Diese Funktion ist hinter dem Flag chrome://flags/#enable-experimental-web-platform-features verfügbar.
• Überschreiben von Inhalten verhindern, die sich nicht ändern: Dies könnte durch eine Inhaltsrevisionsnummer oder Versionsverwaltung erreicht werden. So kann der Status zwischen Routenänderungen oder anderen Aktualisierungen beibehalten werden, anstatt den Inhalt zurückzusetzen.
• Bereinigen beim Patchen: z. B. <template for=icon safe><svg id="from-untrusted-source">...</svg></template>.

Polyfill

Das Chrome-Team hat eine template-for-polyfill auf npm veröffentlicht, damit Websites diese neue Funktion sofort nutzen können, noch bevor sie in anderen Browsern verfügbar ist.

Es gibt einige Einschränkungen, da die HTML-Parser des Browsers nicht direkt aktualisiert werden können. Die häufigsten Anwendungsfälle werden jedoch abgedeckt. Websites sollten weiterhin in anderen Browsern getestet werden.

Erneuerte HTML-Einfüge- und Streamingmethoden

Nicht alle Inhalte können als HTML bereitgestellt werden. Ein zweiter Teil der Arbeit, die in Chrome in diesem Bereich geleistet wurde, zielt darauf ab, das Aktualisieren von Inhalten mit JavaScript zu vereinfachen.

Es gibt bereits mehrere Möglichkeiten, HTML mithilfe von JavaScript dynamisch in ein vorhandenes Dokument einzufügen:

• setHTML
• setHTMLUnsafe
• innerHTML und outerHTML
• createContextualFragment
• insertAdjacentHTML

Sie funktionieren jedoch alle etwas anders und es gibt Feinheiten und Unterschiede, die Entwickler möglicherweise nicht immer berücksichtigen:

• Werden die neuen Inhalte überschrieben oder angehängt?
• Wird potenziell gefährliches HTML bereinigt, z. B. durch Escaping von <script>-Tags?
• Wenn nicht, sollte <script> ausgeführt werden?
• Wie funktionieren sie mit Trusted Types?

Nur wenige Entwickler konnten sich diese APIs ansehen und die Fragen für jede von ihnen mit Gewissheit beantworten.

Eine große Einschränkung besteht darin, dass sie nur für einen vollständigen Satz von HTML-Code verwendet werden können, der im Voraus bekannt ist, wenn Aufrufe erfolgt sind, um HTML-Streaming zu ermöglichen. In der Praxis bedeutet das, dass Sie die gesamten Inhalte herunterladen müssen, bevor Sie sie einfügen können. Einer der großen Vorteile von HTML ist jedoch, dass Inhalte sofort gestreamt werden können. Dies kann in begrenztem Umfang umgangen werden, indem Nutzlasten aufgeteilt oder veraltete Methoden wie document.write verwendet werden. Diese Methoden haben jedoch ihre eigenen Probleme.

Neue APIs für statische und Streaming-Daten

Chrome hat an einer Reihe neuer APIs und Erweiterungen für die vorhandenen setHTML und setHTMLUnsafe gearbeitet, um dies zu bereinigen und Streamingfunktionen einzuführen.

Sie können ab Chrome 148 mit dem Flag chrome://flags/#enable-experimental-web-platform-features von Entwicklern getestet werden und sollen in Chrome 155 eingeführt werden.

Es gibt Methoden zum Festlegen oder Ersetzen sowie zum Einfügen von Inhalten vor oder nach vorhandenem HTML-Code. Für jede Methode gibt es Stream-Entsprechungen:

Es gibt auch Unsafe-Versionen, die in Kürze behandelt werden. Auch wenn es viele davon gibt, insbesondere wenn Sie die Unsafe-Entsprechungen hinzufügen, macht die einheitliche Namenskonvention deutlicher, was die einzelnen Methoden im Vergleich zu den zuvor erwähnten, nicht verwandten Methoden bewirken.

Die statischen Versionen akzeptieren neues HTML als DOM-String-Argument sowie optionale Optionen:

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTML(newHTML);

Die Streaming-Versionen funktionieren mit der Streams API, z. B. mit einem getWriter():

const contentElement = document.querySelector('#content-to-update');
const writer = contentElement.streamHTMLUnsafe().getWriter();

// Example stream of updating content
while (true) {
  await writer.write(`<p>${++i}</p>`);
  await new Promise((resolve) => setTimeout(resolve, 1000));
}

writer.close();

Alternativ können Sie auch eine Fetch-Antwort mit Pipe-Chains verwenden:

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

textStream() Bequemlichkeitsmethode

Außerdem wurde eine textStream-Hilfsmethode hinzugefügt, mit der Sie direkt streamen können, ohne den Zwischenschritt TextDecoderStream() zu benötigen:

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.textStream().pipeTo(contentElement.streamHTMLUnsafe());

options

Mit dem Argument options können Sie eine benutzerdefinierte sanitizer angeben, die standardmäßig auf default festgelegt ist. Das bedeutet die Standardkonfiguration für die Bereinigung. So wird sie verwendet:

const newHTML = '<p>This is a new paragraph</p>';
const contentElement = document.querySelector('#content-to-update');

// Only allows basic formatting
const basicFormattingSanitzer = new Sanitizer({ elements: ['em', 'i', 'b', 'strong'] });

contentElement.setHTML(newHTML, {sanitizer: basicFormattingSanitzer});

„Unsichere“ Methoden

Es gibt auch „unsichere“ Versionen der einzelnen APIs:

Bei diesen „unsicheren“ Methoden wird der Sanitizer standardmäßig deaktiviert. Sie können aber einen benutzerdefinierten Sanitizer angeben. Mit diesen Methoden können Skripts auch mit der optionalen Option runScripts ausgeführt werden, die standardmäßig auf false festgelegt ist.

Wie setHTML ist setHTMLUnsafe eine vorhandene Methode. Der Parameter runScripts wurde jedoch hinzugefügt, damit die Methode für die Skriptausführung verwendet werden kann:

const newHTML = `<p>This is a new paragraph</p>
                 <script src=script.js></script>`;
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTMLUnsafe(newHTML, {runScripts: true});

Die Formulierung „unsicher“ in der Methode soll Entwickler an das potenzielle Risiko erinnern und darauf hinweisen, dass sie Skripts bereinigen oder einschränken sollten. Sie bedeutet nicht, dass diese Methoden nicht verwendet werden sollten.

Wie „unsicher“ das ist, hängt davon ab, wie vertrauenswürdig die Eingaben sind. Die statischen Unsafe-Methoden funktionieren alle sowohl mit DOM-Strings als auch mit TrustedHTML als html-Argumente und ermöglichen auch die Verwendung von Sanitizern. Bei runScript ist es jedoch das Ziel, Scripts zuzulassen. Daher wird standardmäßig kein Sanitizer verwendet.

Anwendungsfälle

Mit diesen neuen APIs können Entwickler einfacher HTML zu bestehenden Seiten hinzufügen. Außerdem werden neue APIs mit einheitlichen Namen und Optionen eingeführt. Die Streaming-APIs bieten den Leistungsvorteil, dass nicht gewartet werden muss, bis alle neuen Inhalte auf der Plattform verfügbar sind.

Dies ist unter anderem in folgenden Fällen hilfreich:

• Dynamisches Streaming großer Content-Updates in Single-Page-Apps: Wie bereits erwähnt, ist ein großer Nachteil der aktuellen SPA-Architektur, dass sie nicht vom Streaming der ersten HTML-Ladevorgänge profitiert – bis jetzt!
• Häufig verwendete Inhalte wie HTML-Fußzeilen einfügen: Wenn Sie die JavaScript-APIs verwenden, können Sie Partials abrufen und in die Seite einfügen. Dabei profitieren Sie vom Caching, anstatt sie auf jeder gesendeten Seite zu wiederholen. Da JavaScript für die Ausführung erforderlich ist, sollte diese Methode jedoch nur für Inhalte verwendet werden, die beim ersten Laden nicht sichtbar sind.

Das sind nur einige Beispiele. Wir sind gespannt, was ihr euch einfallen lasst.

Einschränkungen und Besonderheiten

Für diese neuen APIs gelten einige Einschränkungen und Besonderheiten, die Sie beachten sollten:

• Für die Integration von Streaming mit der Trusted Types API ist die Verwendung einer neuen createParserOptions-Methode erforderlich, mit der ein Sanitizer in jeden HTML-Einstellungsvorgang eingefügt werden kann. Weitere Informationen zur Integration vertrauenswürdiger Typen
• Ähnlich wie bei <template for> kann das Verschieben von Elementen, in die gestreamt wird, unerwartete Folgen oder Streamingfehler verursachen.
• streamHTMLUnsafe funktioniert in vielerlei Hinsicht ähnlich wie der Hauptparser. So werden <template for>-Anweisungen verarbeitet, sobald sie dem Hauptdokument hinzugefügt werden, und defer-Scripts werden bis zum Ende des Streams aufgeschoben.

Standardisierungsstatus

Die neueren Einfüge- und Streamingmethoden werden gerade in den HTML-Standard aufgenommen, werden aber noch nicht von allen Browsern unterstützt.

Polyfill

Das Chrome-Team hat eine html-setters-polyfill auf npm veröffentlicht, damit Websites diese neue Funktion sofort nutzen können, noch bevor sie in anderen Browsern verfügbar ist.

Dieser Polyfill streamt nicht, sondern puffert und wird angewendet, wenn er vollständig ist. Es handelt sich eher um ein Polyfill für die API-Form als für die Funktionalität.

Außerdem hängt die Festlegung sicherer Inhalte von setHTML und der Sanitizer API ab, die in Safari nicht unterstützt wird.

Beide zusammen verwenden

Das sind zwar zwei separate APIs, aber ihr volles Potenzial entfaltet sich erst, wenn sie kombiniert werden. Durch das Streamen neuer <template for>-Elemente in den HTML-Code können Sie verschiedene Inhaltsteile dynamisch aktualisieren, ohne sie mit separaten JavaScript-Verweisen auf das DOM direkt ansprechen zu müssen.

Ein einfacher Seitenaufruf im SPA-Stil könnte so implementiert werden, dass eine Übersichtsseite mit Verarbeitungsanweisungen geladen wird und dann die Vorlagen jeder neuen Seite in den unteren Bereich des HTML-Codes gestreamt werden, um in diese Verarbeitungsanweisungen eingefügt zu werden.

Es gibt zweifellos noch mehr Potenzial und Anwendungsfälle für diese beiden APIs. Lassen Sie sich also nicht von unserer (begrenzten!) Fantasie einschränken. Durch die einfachere Verwaltung von Teilaktualisierungen können Sie Boilerplate-Code reduzieren, Aktualisierungen vereinfachen und neue Möglichkeiten für das Web erschließen.

Chrome arbeitet im Rahmen des Projekts „Declarative Partial Updates“ an einigen weiteren APIs. Wir freuen uns jedoch, Ihnen diese ersten beiden zur Verfügung zu stellen. Wir halten dich auf dem Laufenden und informieren dich, sobald es Neuigkeiten gibt.