Server-Side Rendering (SSR)

Rendering Fresh HTML on Every Request

A route is server-side (dynamically) rendered whenever its content genuinely depends on something only known at request time — the logged-in user's session, request headers, real-time data that can't tolerate any staleness, or an explicit opt-out of caching. Next.js runs the route's Server Components again for every single incoming request.

In the App Router, there's no separate getServerSideProps function to write — you simply use APIs that inherently require per-request data (cookies(), headers(), or fetch(url, { cache: "no-store" })), and Next.js automatically renders that route dynamically.

// app/dashboard/page.tsx
import { cookies } from "next/headers";

export default async function DashboardPage() {
  const sessionId = cookies().get("session")?.value;
  const user = await getUserBySession(sessionId);

  return <h1>Welcome back, {user.name}</h1>;
}

Reading cookies() makes this page inherently request-specific, so Next.js renders it fresh for every visitor rather than reusing a cached build.

Forcing Dynamic Rendering Explicitly

// app/page.tsx
export const dynamic = "force-dynamic";

export default async function Page() {
  // always renders fresh, even without cookies/headers
}

• export const dynamic = "force-dynamic" forces a route to render on every request, regardless of its data.
• Reading cookies() or headers() implicitly makes a route dynamic without needing this export.
• fetch(url, { cache: "no-store" }) also implicitly opts the route into dynamic rendering.
• Dynamic rendering trades some performance for guaranteed per-request freshness.

SSR Cheat Sheet

What triggers dynamic rendering and its trade-offs.

SSR vs. Static Rendering vs. ISR

These three rendering strategies form a spectrum from "rendered once, ever" to "rendered on every request," with Incremental Static Regeneration (covered in the next lesson) sitting in between as a time-based compromise.

Performance Considerations for SSR

Because SSR runs your Server Components on every request, its response time is directly tied to how fast your data sources (databases, third-party APIs) respond. Streaming (covered in a later lesson) helps here by letting fast parts of the page render immediately while slower parts stream in afterward.

Common Mistakes

• Using force-dynamic on every route out of caution, losing the performance benefits of static rendering and ISR.
• Not realizing that reading cookies() even once, deep in the component tree, makes the whole route dynamic.
• Assuming SSR in the App Router requires getServerSideProps — that's a Pages Router-only API.
• Ignoring slow database queries in an SSR route, which directly slows down every single page load.

Key Takeaways

• SSR renders a route's HTML fresh on every request, guaranteeing up-to-date content.
• Reading cookies()/headers() or using cache: "no-store" implicitly triggers dynamic rendering.
• export const dynamic = "force-dynamic" opts in explicitly, regardless of the data used.
• SSR trades some raw performance for guaranteed freshness on every request.
• Combine SSR with streaming for pages that mix fast and slow data sources.