Static, dynamic, hybrid: architecting Next.js for the web

"Static rendering" does not mean "frozen site". It means part of the site already exists, ready to be served, before a visitor even arrives. This decision — what to generate at build time, what at request time — structures the entire architecture.

What the build can freeze

Everything that does not depend on the request is meant to be pre-rendered: content pages, articles, product sheets, marketing pages. The benefits are direct — no calculation at click time, a quasi-static server, instant pages served from anywhere in the world.

export function generateStaticParams() {  return articles.map(({ slug }) => ({ slug }));} // The page becomes a file generated at build:// /blog/[slug]/index.html, ready to serve.

What must remain dynamic

Personalized data — a cart, a dashboard, content specific to each visitor — has no place in a frozen build. It goes through dynamic entry points, isolated from content pages. The hybrid site separates the two worlds instead of mixing them.

The trap of "all dynamic"

When everything is rendered at the request, every visit pays the calculation cost, and every infrastructure error becomes a visible performance problem. The static-first reflex inverts the load: you only pay for the dynamic where it brings value.

A good marketing architecture is not a technical feat: it is a list of choices that make each page trivial to serve.

In practice, on this site

This site is statically generated end to end: content pages load no client-side JavaScript, and the only interactive islands — search, forms — are loaded separately. Measurable result: a Lighthouse score of 100 on content pages.