Declarative partial page updates: goodbye to heavy streaming JavaScript? ⚡️

At Google I/O in May 2026, the Chrome team presented something exciting that is currently being incorporated into HTML standards: Declarative Partial Updates. The feature is already available for testing in Chrome 148.

The problem: traditional HTML streaming has always been strictly linear. The browser parses the document from top to bottom as bytes arrive. If your page has a “heavy” block, such as a recommendations section requiring a slow database query, the server either had to hold up the whole stream, or developers had to cobble together JS workarounds, loading pieces through AJAX/Fetch and inserting them into the DOM manually.

The new API solves this inside the browser itself using out-of-order HTML streaming, or nonlinear streaming.

How does it work?
A special processing-instruction marker is inserted where the content will appear later:

<div><? marker name="deferred-box" ?></div>

The browser renders the rest of the page without waiting, giving the user a fast First Paint. Once the server has finally computed the heavy data, it adds a regular <template> tag to the same stream, specifying the target:

<template for="deferred-box">
  <div class="heavy-widget">Тут лежат данные из БД!</div>
</template>

The browser picks up this template on the fly and declaratively, without any JavaScript involvement at all, inserts its content exactly where the deferred-box marker is.

What else is included in this package?
Alongside streaming out of the box, the JS methods for inserting HTML have been updated. Instead of the old, unsafe innerHTML, there is an expanded set of static and streaming APIs: setHTML(), setHTMLUnsafe(), and entirely new methods such as streamHTMLUnsafe() and appendHTML(). They let you implement SPA-like partial page updates, in the style of HTMX, feeding chunks of HTML streams to the browser directly through its built-in Streams API.

Why do we need this?

1. Islands architecture: hello, Astro and similar tools. Static “islands” and dynamic blocks can now be assembled and updated by the HTML parser itself.
2. Getting rid of unnecessary JS: no more shipping client scripts just to catch a chunk from the server and call appendChild.
3. Performance: less CPU load, since parsing and insertion happen at the lowest level of the browser engine.

While the initiative is being tested in Chromium, official polyfills such as template-for-polyfill are already being actively developed on npm. It feels like the concept of Server-Driven UI could reach an entirely new level in a couple of years.

What do you think of bringing <?таких_конструкций?>, constructs like these, back into modern HTML? Does it remind you of good old PHP/BigPipe, but now on steroids right in the browser? 👇

Read the post