SSR in Next.js

What Actually Happens During an SSR Request

For a dynamically-rendered route, an incoming request triggers your Server Components to run from scratch: any await calls to a database or external API happen right then, and the resulting HTML is streamed back to the browser as it becomes ready — the total response time is directly tied to how long those server-side operations take.

This is different from a client-rendered SPA, where the initial HTML is often minimal and the real work happens after JavaScript loads in the browser — SSR shifts that work earlier, onto the server, which is why the server's own performance matters so much for SSR routes.

// app/dashboard/page.tsx (SSR — reads cookies, so it's dynamic)
import { cookies } from "next/headers";

export default async function DashboardPage() {
  const session = cookies().get("session")?.value;
  const [user, stats] = await Promise.all([
    getUser(session),
    getStats(session),
  ]);

  return <h1>Welcome, {user.name} — {stats.total} total items</h1>;
}

Using Promise.all() here means both requests run concurrently, directly reducing this SSR route's response time.

Diagnosing a Slow SSR Route

1. Identify which fetch/database calls the route makes.
2. Check whether independent calls run sequentially instead of via Promise.all().
3. Measure the actual latency of each external call.
4. Consider streaming (Suspense) for calls that don't block the whole page.

• SSR response time is the sum of your slowest sequential dependency chain, not just "the slowest single call".
• Promise.all() collapses independent calls into a single, parallel wait.
• Streaming with <Suspense> lets fast content render while slow content is still loading.
• A slow third-party API is often the real bottleneck, not Next.js itself.

SSR Deep-Dive Cheat Sheet

Techniques for keeping SSR routes fast.

Combining SSR with Streaming

SSR doesn't require the entire page to wait on its slowest data source. Wrapping a slow section in <Suspense> lets Next.js send the rest of the page's HTML immediately, then stream in the slow section once it resolves — the page remains dynamically rendered, but the user isn't blocked on its slowest part.

import { Suspense } from "react";

export default async function DashboardPage() {
  const user = await getUser(); // fast, blocks initial render
  return (
    <>
      <h1>Welcome, {user.name}</h1>
      <Suspense fallback={<p>Loading stats...</p>}>
        <SlowStats />
      </Suspense>
    </>
  );
}

When SSR Is Genuinely the Right Call

SSR is worth its cost specifically when content truly cannot be cached — per-user dashboards, live pricing, or anything that must reflect the exact state of the world at the moment of the request. If content could tolerate even a minute of staleness, ISR is almost always a better trade-off.

Common Mistakes

• Defaulting to SSR for content that would work fine (and perform much better) as ISR.
• Writing sequential await calls for data that has no actual dependency on each other.
• Not using <Suspense> to isolate a page's slowest data source from its fast, critical content.
• Blaming Next.js for slow SSR responses when the actual bottleneck is a slow database query or third-party API.

Key Takeaways

• SSR response time is directly determined by your server-side data-fetching performance.
• Promise.all() and <Suspense> streaming are the two biggest levers for keeping SSR fast.
• SSR is the right choice specifically for content that cannot tolerate any staleness.
• Many "needs SSR" requirements are actually satisfied by ISR with a short revalidation window.
• Profiling your actual data sources is more valuable than micro-optimizing Next.js configuration.