Rendering Strategies Questions

• SSG: HTML built once at build time; served from CDN. About page, blog posts.
• SSR: HTML built per request. Cart, search results, account pages.
• ISR: static, but rebuilt in the background after revalidate seconds or on demand (tags/paths). Product and category pages.

In the App Router, a route is static unless it uses dynamic APIs; ISR is export const revalidate = N or fetch-level revalidate.

Using cookies(), headers(), connection(), draftMode(), reading searchParams, uncached data with cache: 'no-store', or export const dynamic = 'force-dynamic'. The build output shows it as ƒ. export const dynamic = 'error' makes the build fail if a page you expect to be static becomes dynamic.

PPR prerenders a static shell of a route and leaves "holes" for dynamic parts wrapped in <Suspense>. The shell is served instantly (CDN), and the dynamic parts stream in the same HTTP response. One personalised widget no longer forces the whole page to be dynamic. In Next.js 16 it comes with Cache Components.

With Suspense boundaries (or loading.tsx), the server sends HTML in chunks: first the shell and fallbacks, then each completed part with a small script that swaps it in. Users see content sooner (better TTFB/FCP/LCP), slow queries do not block fast ones, and crawlers still get complete HTML. Buffering proxies (nginx without proxy_buffering off) can break it.

Node.js (default) supports all Node APIs, npm packages and database drivers. Edge supports only Web APIs but starts fast and runs close to users; good for simple redirects, geolocation, A/B logic. Put compute close to the data: an edge function talking to a database in one region is not faster.