Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the experimental SSR streaming. With one simple change in the Nuxt config I was able to reduce the Largest Contentful Paint (LCP) by over 2 seconds. I simply enabled the experimental SSR streaming, and the first byte arrived in 16 milliseconds.
With out it, the server spent about 2.5 seconds rendering the page. Streaming changed what the browser could display during that wait.
As a part of my testing I also tried out two other features: useLayout() and named views. Let's take a look at all of these now!
You will need: Node.js 22 or another version supported by Nuxt 4.5 npm Basic experience with Nuxt pages, components, and layouts Chrome or another browser with document-request timing tools My sample app! https://github.com/ErikCH/nuxt-ssr-streaming
The demo preview runs on port 3010. The streamed route is /, and /buffered uses the same components with streaming disabled by a route rule.
Normal server-side rendering can buffer the document until every server-rendered component finishes. A slow database query or API request can leave the browser waiting even when the page shell is ready.
Nuxt 4.5 added the experimental ssrStreaming option. It uses Vue's web-stream renderer to flush ready HTML while later boundaries continue rendering.
I used a fixed delay so the delivery difference would be easy to see. The delay runs on the server, and useState serializes the result into the Nuxt payload for hydration.
Place the component inside a Vue Suspense boundary. The fallback becomes part of the shell that Nuxt can send before SlowPanel resolves.
The fallback needs to be useful. Navigation, page context, and a clear loading state give the visitor something to work with. Sending an empty shell earlier does little for the experience.
The demo enables streaming outside development and keeps /buffered as a control route.
The /buffered route uses the same slow component, delay, and shell. Its route rule changes the response mode without changing the work performed by the component.
Open the streamed and buffered routes as full document requests. Disable the browser cache and use a hard reload. Client-side navigation does not create a new SSR document request.
Both routes performed the same delayed work and returned the same amount of HTML. The streamed route delivered the response in 14 chunks and gave the browser useful HTML much earlier. The buffered route delivered one chunk after the slow boundary finished.
This was just a test, on a somewhat contrived setup. However, I would try this yourself in your own app and see how the results go. Make sure to try it in development first, before going to production.
ssrStreaming is experimental and disabled by default. Nuxt can fall back to buffered rendering for: Bots and crawlers Cached routes Incremental Static Regeneration (ISR) Stale-while-revalidate (SWR) routes Redirects Routes using ssr: false Prerendered output Routes with streaming: false
Streaming also changes when the HTTP response becomes committed. After the shell has been flushed, later component code may be too late to change the status, headers, or cookies. Test authentication redirects, cookie writes, cache headers, errors, and middleware before enabling streaming on a production route.
I would start with a content-heavy page that has a useful shell and one isolated slow boundary. Measure the deployed route with its real adapter and route rules. Keep buffering where the application needs to finish response decisions before sending HTML.