Choose rendering by freshness, authority and cost

First, build a mental model

Static rendering prepares a reusable answer early. Request rendering prepares an answer for a request. Browser rendering computes UI after files arrive. A product can combine these at different boundaries.

1. Use prebuilt public content when the required information is known during the build. Client JavaScript can add local interaction and fetch suitably authorized external data later.
2. Use a supported request runtime when the HTML or operation must depend on request-time cookies, protected data or a changing server decision. That changes the hosting contract.
3. With output: 'export', Next.js emits a static artifact. Supported build-resolved GET handlers can emit static responses, but a request-time POST mutation cannot become an active server merely by living in route.ts.
4. Check the installed framework version and its feature support. Static export, server rendering, client interactivity and cache behavior are separate decisions; do not infer them from a file's extension.

// next.config.mjs: a static hosting contract
const nextConfig = { output: 'export' };
export default nextConfig;

// Build output is served as files.
// Request-time protected writes need a trusted runtime elsewhere.

1. Public lesson

   Its explanation can be rendered during a build and reused for many learners.

2. Local practice

   An answer changes browser state without requiring a private application server.

3. Private operation

   A hypothetical protected order write requires fresh identity/authorization at a trusted endpoint, outside a files-only hosting contract.