Let's take a simple example: a chart display in a SaaS CRM.
Although not very visually complex, in CSR the browser:
Receive only the HTML skeleton.
Download the JS.
Wait for API responses.
Only then does it display useful content to view the graphs.
Each delay builds on the next. And if the JS package is 2MB and your API takes c level contact list 1 or 2 seconds, the user could be staring at a blank screen for 5 seconds or more —and that's too long.
An alternative is Server-Side Rendering (SSR)
Server-side rendering (SSR) solves part of the problem. Instead of sending empty HTML, the server generates all the HTML content and sends it pre-rendered. This way, the user sees content from the very beginning , even if the JS hasn't finished loading yet.
This greatly improves the perception of performance .
But classic SSR isn't as easy to implement if your app is already in production. It involves refactoring components, managing server and client state, and dealing with the notorious "hydration" in React, which can lead to subtle errors.
The Lightweight Solution: HTML Streaming
This is where the star of the day comes in: HTML streaming from the server .
The idea is simple but effective: instead of waiting for all the content to be ready to send the response, the server sends the HTML in parts , as the data becomes available.
This allows for parallelization of what is normally a chain of sequential tasks.
How does it work?
The user accesses your page.
The server immediately sends a first piece of HTML with the header, styles, and perhaps a loader.
While the browser processes that first chunk and begins downloading the JS, the server makes the necessary API calls.
As data arrives, the server continues sending HTML fragments that complete the page.
By the time the JS is ready, it already has the necessary data embedded in the HTML. No additional calls from the client are required.