Engineering · Published August 30, 2026
Caching and First Paint in Nuxt SSR
Server rendering is not automatically fast. First paint depends on how requests are organised, not on the rendering mode.
Many teams adopt SSR for first paint and SEO, then discover the first screen still takes one or two seconds. The cause is rarely rendering; it is serial data fetching, slow APIs or missing cache.
Three usual bottlenecks
Serial requests. The page waits for categories, list and recommendations in turn, so total time is the sum. Running them in parallel often halves it.
No cache. Home and list pages are identical for everyone and can be cached on the server for a few dozen seconds, cutting API load sharply.
Over-fetching. A list page requests detail fields, a detail page requests list data, and both waste bandwidth and query time.
Our defaults
Content pages get a short server-side cache, invalidated by an API call after editors publish, so nobody sees stale content.
Critical first-screen requests run in parallel inside useAsyncData; non-critical modules load on the client later.
Images and fonts go through a CDN so they do not compete for first-screen bandwidth.
SSR only moves rendering to the server. Real speed comes from fewer requests, parallel requests and sensible caching.
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →