The product list is slow to display. On investigation, what is slow is neither the product names nor the images, but only the stock display, which queries an external service item by item. Still, the whole page does not appear, so as far as users are concerned, the site is simply "slow".
There has long been an answer to this symptom: return the parts that can be shown first, and swap in only what arrives late. Implementing it, however, meant relying on a framework's mechanisms. That premise is starting to change.
<template> gains a for attribute
The syntax from a proposal known as Declarative Partial Updates was incorporated into the WHATWG HTML Living Standard on August 20, 2026. Put forward by the Chrome development team, it expresses out-of-order streaming by adding a new for attribute to the standard <template> element.
The position to be replaced is marked with processing instructions such as <?marker> or <?start>–<?end>. Support has already shipped in Chrome 150 and Edge 150, and textStream(), which reads a response as a stream of text, was added in Chrome 151. WebKit has stated its standards position as "support", and Mozilla as "positive". However, in this check we could not confirm that it works in stable releases of Safari and Firefox.
What becomes unnecessary and what remains
It is easy to misread this as meaning that frameworks will no longer be needed. What actually gets replaced is only the plumbing for implementing partial updates.
- What may become unnecessary: client-side mechanisms added solely for swapping content, and the extra JavaScript for them
- What is still needed: a server-side design that separates out slow processing, and a layout that does not break when the order changes
In other words, if the server cannot return "what can be shown first" and "what comes later" separately, the syntax is of no use even once it is in the standard. The idea of this split itself is covered in streaming SSR and partial updates.
Benefits for all users are still some way off
Since support starts with Chrome-family browsers, updating your site now benefits only some users. In practice, build it so that the page still finishes displaying as before in browsers without support: content is swapped in when it arrives, and if it does not arrive, the page waits until the end. Built this way, the benefits grow automatically as support spreads. The Chrome development team has also published a polyfill (a script that reproduces the same behavior) for browsers without support, but it explains that because the browser's HTML parsing itself cannot be changed, the polyfill covers only the main use cases.
Put the other way around, there is little reason to rush a rewrite now. There are other things to do first.
What works even with your current build
There are also things you can do without waiting for the syntax. Separate the slow processing from rendering the screen, and show a "loading" placeholder in its place first. If you fix the placeholder's size, the display will not jump when the content arrives later.
This works regardless of the new specification, and it also means preparing in advance a layout that does not break when the order changes. It leaves you ready to move straight to the standard syntax once more browsers support it.
This approach is not wasted while you wait for more browsers to add support. With the placeholder sizes fixed, text and images jump around less while loading, which also improves the metrics.
Measure in the right place
To begin with, an update made without confirming that the slowness really comes from "some slow processing" will miss the mark. Browser measurement tools only show the part of the path as seen from the browser. If time is being spent between the delivery front end and the server, adding partial updates will not change the wait until the first byte arrives.
How to measure by segment is covered in the segments to check when a site is slow, and how to read the metrics in the basics of Core Web Vitals.
Conversely, if measuring by segment shows that the page generation itself is slow, adding partial updates will not change how fast it feels. Sticking to the order of measuring first and deciding second is, in the end, the quickest route.
If measurement shows the slow processing really is limited to part of the screen, separate that part out on the server side. When support spreads, you will only need to switch it over to the syntax, and the separation itself is effective even with your current build.
We checked the change to the WHATWG HTML specification (the pull request merged on August 20), the Chrome and Edge release notes, and WebKit's and Mozilla's standards positions on September 24, 2026. We have not tested an implementation in supporting browsers, checked how the polyfill behaves, or measured display times by applying it to an existing site. Because the HTML specification is continuously updated, the syntax and each browser's support may change.
For investigating site speed or scoping what to update, please consult GleamHub.
