SSR

Server-Side Rendering generates HTML (and RSC payload) per request when data must be fresh, user-specific, or authorization-dependent. In App Router, dynamic segments, cookies, headers, or `export const dynamic = 'force-dynamic'` opt into request-time rendering.

					export const dynamic = 'force-dynamic';

export default async function Page() {
  const user = await getUserFromCookies();
  return <Dashboard data={await fetchDashboard(user.id)} />;
}
				

SSR improves first meaningful HTML for crawlers and users but increases server work and TTFB versus cached static output.

On interviews: explain when SSR beats ISR and how request data stays server-side.

Common pitfalls: SSR for globally identical content, N+1 fetches per request, and leaking secrets into serialized props.

The trade-off is freshness and personalization versus server cost and cache hit rate.

Checklist:

• Use SSR when output varies per request.
• Batch server fetches; avoid waterfalls.
• Keep secrets and tokens server-only.
• Monitor TTFB and error rates.