SSR – Server-Side Rendering

Understanding Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is a rendering method where the HTML for a page is generated on the server for every single request. Unlike Client-Side Rendering (CSR), where the browser does the heavy lifting, SSR delivers a fully populated HTML page to the user immediately.

In an SSR model, when a user requests a page, the server fetches the necessary data, renders the React components into HTML strings, and sends the complete document to the browser. The browser can display this content instantly, even before the JavaScript bundle has downloaded.

The SSR Execution Flow

The process for displaying content in SSR is distinct from CSR:

1. Request: The browser sends a request to the server for a specific URL.
2. Server Processing: The server executes the page logic, fetches data from APIs or databases, and generates the full HTML for the page.
3. Response (The Content): The server sends back the fully rendered HTML. The user sees the content immediately upon arrival.
4. Bundle Download: The browser downloads the JavaScript bundle in the background.
5. Hydration: React "hydrates" the static HTML, attaching event listeners and making the page interactive.

When Should You Use SSR?

SSR is the go-to choice when SEO and initial load performance are critical, especially for dynamic content.

1. SEO Priority

Search engines love SSR. Because the content is present in the initial HTML response, crawlers can easily index your page without needing to execute JavaScript. This is crucial for:

• E-commerce Product Pages: Where every product needs to be indexed with the correct price and description.
• News Sites & Blogs: Where content needs to be discoverable immediately.
• Social Media Sharing: SSR ensures that Open Graph (OG) tags are populated correctly, so links look great when shared on Twitter, Facebook, or LinkedIn.

2. Dynamic Data with Fast First Paint

If your application relies on data that changes frequently (e.g., a stock ticker, a personalized feed, or a user profile) but you still want a fast First Contentful Paint (FCP), SSR is ideal. It ensures the user sees the up-to-date content immediately, rather than a loading spinner.

3. Support for Lower-End Devices

By offloading the rendering work to the server, you reduce the processing burden on the user's device. This is beneficial for users on older mobile phones or slow connections who might struggle with heavy client-side rendering.

When Should You Avoid SSR?

While powerful, SSR comes with trade-offs, primarily related to server costs and latency.

1. High Server Load & Cost

Since the server must render the page for every request, high traffic can put a significant strain on your infrastructure. You may need to scale your servers (and pay more) to handle spikes in traffic, unlike Static Site Generation (SSG) which can be served cheaply from a CDN.

2. Slower Time to First Byte (TTFB)

The user has to wait for the server to finish rendering before they receive any content. If your server is slow to fetch data or render the page, the user will see a blank screen for longer than with SSG or even a well-optimized CSR shell.

3. Full Page Refreshes (Traditional SSR)

In traditional SSR setups (without a framework like Next.js), navigating to a new page often triggers a full browser refresh, which feels less "app-like" than the smooth transitions of CSR. However, Next.js mitigates this by using CSR for subsequent navigations.

🛠️ Implementing SSR in Next.js

Next.js makes implementing SSR seamless, offering different methods depending on the router you are using.

SSR Example: Pages Router

In the Pages Router, you use the getServerSideProps function. This function runs on the server for every request, and its returned props are passed to your page component.

// pages/ssr-page.tsx
import type { InferGetServerSidePropsType, GetServerSideProps } from "next";
 
type Repo = {
  name: string;
  stargazers_count: number;
};
 
export const getServerSideProps = (async () => {
  // Fetch data from external API
  const res = await fetch("https://api.github.com/repos/vercel/next.js");
  const repo: Repo = await res.json();
 
  // Pass data to the page via props
  return { props: { repo } };
}) satisfies GetServerSideProps<{ repo: Repo }>;
 
export default function Page({
  repo,
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  return (
    <main>
      <h1>{repo.name}</h1>
      <p>Current Star Count: {repo.stargazers_count}</p>
    </main>
  );
}

SSR Example: App Router (Modern)

In the App Router, all components are Server Components by default. To implement SSR, you simply fetch data directly inside your component. Next.js automatically deduplicates requests and renders the component on the server.

To ensure the page is dynamically rendered for every request (true SSR), you can opt out of caching using no-store.

// app/ssr-page/page.tsx
 
async function getData() {
  // The 'no-store' cache option ensures this fetches fresh data on every request
  const res = await fetch("https://api.github.com/repos/vercel/next.js", {
    cache: "no-store",
  });
 
  if (!res.ok) {
    throw new Error("Failed to fetch data");
  }
 
  return res.json();
}
 
export default async function Page() {
  const data = await getData();
 
  return (
    <main className="p-10">
      <h1 className="text-3xl font-bold mb-4">
        Server-Side Rendering in App Router
      </h1>
      <div className="bg-gray-100 p-6 rounded-lg shadow-md">
        <h2 className="text-xl font-semibold">{data.name}</h2>
        <p className="text-gray-700 mt-2">
          Stars:{" "}
          <span className="font-mono font-bold text-blue-600">
            {data.stargazers_count}
          </span>
        </p>
        <p className="text-sm text-gray-500 mt-4">
          This data was fetched on the server at request time.
        </p>
      </div>
    </main>
  );
}

Conclusion: Balancing Performance and Freshness ⚖️

Server-Side Rendering is a powerful tool for delivering dynamic, SEO-friendly content with a fast initial visual load. While it introduces more server complexity than Static Site Generation (SSG), it is often the necessary choice for personalized or highly dynamic applications.

In the modern web landscape with frameworks like Next.js, the line between SSR and other methods is blurring. You can now mix Server Components, Client Components, and Streaming to get the best of both worlds—fast server response times and rich client-side interactivity.