A few years ago, choosing a framework mostly decided how your site rendered. Today the same codebase can serve a static marketing page, a personalised dashboard and a streaming search results page side by side. The question is no longer which approach your stack supports, but which approach each page deserves.
Getting it right is one of the cheapest performance wins available. Getting it wrong gives you slow pages, stale content or a hosting bill that makes no sense.
The four options, in plain terms
- Static generation builds the HTML once, ahead of time, and serves the same file to everyone from a CDN. Fastest and cheapest, but the content is only as fresh as the last build.
- Incremental regeneration is static with an expiry date: pages are rebuilt in the background after a set time or when content changes.
- Server rendering builds the HTML on every request. Always fresh and personalisable, but every visit costs compute and waits on your slowest data source.
- Streaming sends the page in pieces: the fast parts arrive immediately and slower sections fill in as their data is ready.
Start with two questions
For each route, ask how often the content changes and whether it differs per visitor. Those two answers eliminate most of the options.
- Same for everyone and changes rarely — marketing pages, docs, blog posts: static, with regeneration when the CMS publishes.
- Same for everyone but changes often — product listings, prices, stock: incremental regeneration with a short window, or on-demand revalidation.
- Different per visitor — account pages, dashboards, carts: server rendering, with slow sections streamed.
Where teams usually go wrong
Rendering everything on the server by default
It feels safe because the content is always fresh, but it makes your marketing pages as slow as your database and as expensive as your traffic. A campaign spike becomes an infrastructure incident.
Personalising the whole page for one small element
A greeting or a cart count in the header shouldn't force the entire page to be server-rendered. Render the page statically and load the personal fragment separately.
Ignoring the slowest dependency
A server-rendered page is only as fast as its slowest API call. If one recommendation service takes a second, stream that section rather than holding the whole response hostage.
Performance is decided route by route, not framework by framework.
Measure what users experience
Lab scores are a starting point, but field data from real devices is what search engines and users respond to. Track Largest Contentful Paint and Interaction to Next Paint for your key templates, segmented by device type, and review them whenever a rendering decision changes.
A sensible default
If you're starting fresh, make everything static unless there's a reason not to. Add regeneration where content changes, server rendering where it's personal, and streaming wherever a slow dependency would otherwise block the page. Write the decision down for each route so the next developer knows it was deliberate.
Written by
DevTechnology Engineering