Out-of-order HTML streaming in Chrome 150: what it replaces
Chrome 150 ships out-of-order HTML streaming with template for. How it works, what it replaces in React-style streaming, and what Safari users see today.
Out-of-order HTML streaming is now built into the browser. Since Chrome 150, stable from 30 June 2026, a server can send a slow section of a page after everything else and the HTML parser drops it into the right place, using a <template for> element and no JavaScript. What it replaces is the inline-script trick frameworks use today, not the frameworks.
InfoQ's report on 21 September brought the feature to wider attention, three months after it reached Chrome stable. Here is where it stands as of September 2026:
| Piece | Status | Source |
|---|---|---|
Declarative <template for> and processing instructions | Shipped in Chrome 150; InfoQ also lists Edge 150 | Chrome release notes |
| HTML standard | <template for> merged into WHATWG HTML on 20 August 2026 | whatwg/html #11818 |
| Safari (WebKit) | Standards position: support. Not shipped. | WebKit #628 |
| Firefox (Mozilla) | Standards position: positive. Not shipped. | Mozilla #1369 |
response.textStream() | Chrome 151 | InfoQ |
JavaScript streaming methods (streamHTML and relatives) | Separate standardisation track | InfoQ |
How does out-of-order HTML streaming work?
You mark a place in the document with processing instructions, then stream a template that names it. The WICG explainer uses a gallery example:
<section>
<?start name="gallery">Loading...<?end>
</section>
<template for="gallery">
Actual gallery content
</template>When the parser meets the template, it removes the <?start> and <?end> markers and the fallback between them, and inserts the template's contents in their place. A single <?marker name="..."> works as an insertion point with no fallback. Put a new marker at the end of a patch and the next template with the same name appends after it, which is how a results list can fill in one item at a time.
Patches for different regions can interleave. The explainer's example has a product carousel above a list of search results. The server sends the page shell with both placeholders, then result one, then the carousel, then results two and three; the page shows the carousel first and the results in order beneath it. The byte order no longer has to match the reading order.
The scoping rule that stops one component hijacking another
A <template for> can only patch markers inside its own parent element, to stop untrusted markup reaching into a form or navigation elsewhere on the page. The one exception is a template placed directly under <body>, which gets document scope so it can patch markers in <head>. If you stream templates from nested components, this rule decides where they have to be emitted.
What declarative HTML streaming replaces
Streaming HTML has always had two limits, as the explainer puts it: content arrives in DOM order, and streaming stops once the document is parsed. Anything cleverer has been done in script. The explainer says so directly: React streams content out of order by injecting inline <script> tags that modify the already parsed DOM.
The idea is older than React. InfoQ traces it to Facebook's BigPipe, then to React's Suspense streaming and Next.js, all aimed at one goal: stop a slow part of the page blocking the whole page. The ChromeStatus entry frames the native version the same way, as a performance fix for when the server is slow to produce content that appears early in the document.
What changes is who does the moving. Today the framework ships the script that relocates each chunk, and that script has to run before the content lands in place. With <template for> the parser does it, so the placement no longer depends on script executing. For teams already careful about what inline scripts they emit, and we've written about one such case in JSON-LD script injection, one fewer class of inline script is a real gain.
Does this replace React Suspense?
No, and it isn't designed to. Suspense is how you declare a loading boundary and its fallback in component code. The new primitive is a delivery mechanism for the bytes. The explainer's stated design principles include letting current framework ecosystems integrate with the primitives rather than replacing them, and ChromeStatus notes heavy involvement from framework and CMS developers in the WICG repository.
What none of our sources say is whether React or Next.js will switch their streaming output to <template for>, or when. Treat any claim that "Suspense now uses native streaming" as unverified until the framework's own release notes say it.
The strongest case for ignoring all this is simple: your framework's streaming already works in every browser, and the native version works in Chromium only. For most React teams that's the right call today. The native path earns its place where there is no framework runtime to lean on: server-rendered pages, CMS templates and plain Node responses where you'd otherwise write the patching script yourself.
Which browsers support out-of-order HTML streaming?
Only Chromium ships it. InfoQ's summary line says Safari and Firefox "have signaled support", while its body describes a positive WebKit position and "receptive interest" from Mozilla. The primary records are firmer than the second phrase: WebKit's position is labelled support and Mozilla's is labelled positive. A standards position is still not a release date, and neither engine has shipped the feature.
Progressive rendering without JS support: what older browsers see
In a browser without support, the fallback stays on screen. Processing instructions are currently parsed as bogus comments, and template contents are never rendered, so a visitor on an unsupported browser sees "Loading..." where the content should be. That is a broken page, not a degraded one. You need a fallback path: either a small script that applies the templates when native support is missing, or in-order rendering for those clients. Testing that path in Safari and Firefox belongs in your QA and automation suite from day one.
When we would adopt it
If you hand-roll streaming in a server-rendered app, adopt now behind a fallback: the markup is small and the standard is merged. If you're on Next.js or another React framework, wait for the framework to adopt it and don't hand-patch its output. And if most of your traffic is Safari on iOS, the fallback is your main path, so measure before you build.
This is the kind of platform change we track in our web app development work. For another browser-level shift in how pages get consumed, see WebMCP for browser agents.
Frequently asked questions
Out-of-order HTML streaming lets a server send parts of a page in any order while the browser places each part where it belongs. A template element with a for attribute names a placeholder marked with processing instructions, and the HTML parser swaps the placeholder for the content without any JavaScript.
Declarative HTML streaming shipped in Chrome 150, released to stable on 30 June 2026, and InfoQ reports it in Edge 150. WebKit has a standards position of support and Mozilla a position of positive, but as of September 2026 neither Safari nor Firefox has shipped it.
Out-of-order HTML streaming does not replace React Suspense. Suspense declares loading boundaries and fallbacks in component code, while the new browser feature only changes how streamed HTML gets placed. The sources do not say whether React or Next.js will adopt it, so treat framework support as unconfirmed.
Browsers without support parse the processing instruction markers as bogus comments and never render template contents, so visitors keep seeing the fallback text, such as Loading, instead of the real content. Sites adopting the feature need a script fallback or in-order rendering for those browsers.
The template for element is part of the WHATWG HTML standard. The pull request adding it for declarative out-of-order streaming was merged on 20 August 2026. The companion JavaScript streaming methods, such as streamHTML, are going through a separate standardisation process, according to InfoQ.
