Comparison
Server-side renderingvsStreaming SSR
Server-side rendering
the HTML arrives with the content already in it, and the page is readable before any script runs.
Running the component code on the server for each request and sending finished HTML. It gets content on screen sooner and gives crawlers something to read, at the cost of a server that must render on every request and a time-to-first-byte that now includes your data fetching. The rendered HTML is inert until hydration, so 'visible' and 'usable' become two different moments you have to measure separately.
Full entry →Streaming SSR
the header and layout arrive immediately and the slow part of the page fills in a moment later, in the same response.
Sending server-rendered HTML in chunks as it becomes ready instead of waiting for the whole page. The shell reaches the browser before the slowest data fetch finishes, so time to first byte stops being hostage to the slowest query. The costs are that you cannot set headers or a status code once the stream has started, and that error handling after the first byte means rendering a fallback in place rather than redirecting.
Full entry →