· 1 min read
Choosing a rendering strategy in Next.js
Static, dynamic or streamed? A practical way to decide how each page in a Next.js app should render.
- Next.js
- Full-stack development
- Website performance
Next.js gives you several ways to render a page, and picking the right one per route is one of the highest-leverage decisions in a project. The good news: the decision is usually simple once you ask the right questions.
Start with how often the content changes
If a page looks the same for everyone and changes rarely — a marketing page, a case study, a blog post — render it statically at build time. It is served from a CDN, loads almost instantly and costs almost nothing to run.
If the content changes on a schedule, static pages can still be revalidated periodically, so you keep the speed without rebuilding the whole site.
Ask whether the page is personal
Dashboards, account pages and anything that depends on the signed-in user need dynamic rendering. The server builds the page per request, using cookies or session data.
The trick is to keep the dynamic part as small as possible. Render the shell statically and stream in the personalised pieces, so visitors see something useful immediately.
Keep client components small
Interactive pieces — menus, forms, theme toggles — need JavaScript in the browser. Everything else can stay a server component and ship no JavaScript at all. A useful habit: push the "use client" boundary down to the smallest component that truly needs it.
A quick checklist
- Same for everyone, rarely changes → static
- Same for everyone, changes often → static with revalidation
- Depends on the user → dynamic, with streaming
- Needs interactivity → a small client component inside a server page
Getting this right early makes a site faster, cheaper to host and easier to maintain — and it is much harder to retrofit later.