Three questions settle it. Must the page be indexed or shared as a link? Does its content differ per reader? How fresh must it be? Mix the answers freely: the unit of decision is the route, not the application.
| Strategy | Renders | Best for | Cost |
|---|---|---|---|
| Client only | In the browser | Dashboards, editors, anything behind a login | Blank first paint |
| Static prerender | At build time | Docs, marketing, catalogs | Rebuild to refresh |
| Streaming SSR | Per request | Personalized pages that must be indexed | A Node process under load |
| Server Components | Before bundling | Data-heavy pages with small interactive parts | A framework |
Start with the cheapest option that meets the requirements, and measure before adding a tier. Server rendering buys a faster first paint and indexable HTML; it does not make a running application faster, and it will not rescue a page whose real problem is a 900 KB bundle or an unindexed query. If you do adopt it, rely on a framework: caching, routing, data loading, per-route error boundaries and asset manifests are all part of the job, and each is a source of bugs when hand-rolled. The APIs here are the ones frameworks call, and knowing them turns their documentation from magic into plumbing.
Keep the catalog project open. The next chapters give its components something real to talk to — an Express 24,430 API in Express.js, MongoDB 1,815 behind it in MongoDB — and Next.js hands the rendering pipeline you just built by hand to Next.js 10,514 .