How Does Streaming HTML Make a Page Feel Faster?

How Does Streaming HTML Make a Page Feel Faster?

Streaming lets the server send the first part of the HTML while it is still working out the rest. The browser starts downloading stylesheets and fonts immediately instead of waiting for the whole page. Nothing gets faster in total. The useful work just starts sooner.

We spend a lot of time on performance for B2B marketing sites, and streaming is one of the few techniques that helps precisely where most sites are weakest: the gap between the click and anything appearing.

This walks through how it works, when it helps, and what to do when your stack cannot stream at all.

What Actually Happens Without Streaming?

The browser sits idle. It asks for the page, the server queries a database, calls an API and renders a template, and only when the last byte is ready does anything get sent. During that whole window the browser knows nothing about the stylesheet it will need.

Chrome's documentation for developers describes this directly as server think-time, the work a server does to produce the HTML, and says the resulting latency delays the point at which the browser can start rendering the page.

The cost is doubled because of what comes next. Once the HTML finally arrives, the browser discovers the stylesheet, requests it, and waits again. Two round trips happen in sequence that could have happened in parallel.

How Does Streaming Change That?

By flushing the head of the document early. The server sends the opening HTML, the title, the stylesheet link and the font preloads before it has any idea what the page body will contain, then sends the body when it is ready.

The browser's preload scanner picks up those resource references the moment they arrive and starts fetching. By the time the slow part of your page is ready, the CSS is already downloaded and parsed. The database query and the stylesheet download overlap instead of queueing.

This is why streaming shows up as an improvement in perceived speed more than in total load time. The last byte may arrive at the same moment. The first pixel arrives much earlier, and that is the part a person experiences.

What Does It Do to Your Core Web Vitals?

It mostly helps Largest Contentful Paint, which web.dev defines as needing to occur within 2.5 seconds of when the page first starts loading, measured at the 75th percentile of page loads across mobile and desktop.

The other two metrics are less affected. Interaction to Next Paint, which web.dev says should be 200 milliseconds or less, is about the responsiveness of your JavaScript, and Cumulative Layout Shift, which should be 0.1 or less, is about reserved space. Streaming does not fix either, and done carelessly it can make layout shift worse.

That last point is worth holding onto. If you stream content into a region whose size is unknown, you are shipping a layout shift on purpose. Reserve the space first. Our piece on cumulative layout shift covers how to do that properly.

What If Your Stack Cannot Stream?

Use Early Hints instead. HTTP status 103 lets a server send a preliminary response carrying hints about resources before the final response is ready. MDN describes it as a server sending hints about the sites and resources it expects the final response to link to, so the browser can preconnect or start preloading before the real response exists.

This solves the same problem from the other end. You are not restructuring how your application renders. You are telling the browser what it will need while your server does its slow work.

The reported gains are real. Chrome's documentation cites real-world results of several hundred milliseconds faster Largest Contentful Paint on Shopify and Cloudflare implementations, with some cases reaching up to a second faster.

What Are the Rules for Early Hints?

A few, and they matter. MDN notes that the response may carry a Link header indicating resources to load, and a Content-Security-Policy header that is enforced while processing the hint. A server may send multiple 103 responses, but browsers only process the first one.

There is also a transport constraint. MDN recommends only sending 103 responses over HTTP/2 or later unless the client is known to handle informational responses correctly, and notes that most browsers limit support to HTTP/2 or later for exactly that reason.

Support differs by directive. Chrome's documentation lists preconnect as supported in Chrome 103 and later, Edge 103 and later, Firefox 120 and later and Safari 17 and later, while preload is listed for Chrome 103 and later, Edge 103 and later and Firefox 123 and later, with Safari not supported.

Where Should You Apply This First?

On entry pages. Chrome's guidance is to focus Early Hints on top landing pages, meaning the pages where users typically start when they visit your site, because the benefit diminishes on subsequent navigations once connections are already warm.

For a B2B site that usually means the homepage, your two or three highest-traffic blog posts, and any paid landing page. Those are the pages where a visitor arrives cold, with no cached CSS and no open connection to your font host.

Deeper pages benefit less, and the engineering cost is the same. This is one of the few performance techniques where the right move is to apply it narrowly.

How Does This Interact With a Static Site?

If your pages are prerendered at build time, most of this problem never happens. There is no database query on the request path, so there is no server think-time to hide, and the HTML is sitting on a CDN ready to send.

That is how our own site works, and it is why we recommend prerendering for marketing sites whenever the content changes on a publishing schedule rather than per request. Streaming is a good answer to slow server rendering. Not rendering on the server at request time is a better one.

We compared those approaches in static versus server rendered, and the decision usually comes down to how personal the page content needs to be.

What Goes Wrong in Practice?

Buffering. Many stacks quietly hold the whole response before sending it, so your carefully flushed head never leaves the building. A proxy, a compression layer or a framework default can all do this, and the symptom looks identical to not having implemented streaming at all.

The way to check is to watch the network tab for when the first byte of HTML arrives relative to the full response. If they land together, something is buffering. Our piece on time to first byte covers how to read those numbers.

The other common failure is streaming a page whose head depends on the body. If your title tag or canonical URL is computed from data fetched late, you cannot flush the head early without getting them wrong. That usually means a small refactor to resolve metadata first.

Is This Worth the Engineering Time?

It is worth it when your server think-time is genuinely large and you cannot remove it. If your backend takes 600 milliseconds to produce HTML because of a call you do not control, streaming or Early Hints is the cheapest way to stop that time being dead time.

It is not worth it if your page is slow because of four megabytes of JavaScript. Starting sooner does not help when the real problem is what happens after. Fix the payload first, then hide the latency you cannot remove.

If you want a straight answer about where your site's time is actually going, we are happy to look at it with you. You can reach our team at phoenix.studio.