What Is SSR in Next.js? How Server-Side Rendering Works

SSR (Server-Side Rendering) means the HTML of a page is generated on the server for every incoming request and sent to the browser ready to display. In Next.js this is close to the default behavior: every page in the App Router renders on the server as a Server Component; you switch a page between SSR, SSG and ISR simply by changing the caching option of your data fetches. The result: users and search engines see fully populated HTML without waiting for JavaScript to load — which means both speed and SEO. This is the main reason we build on Next.js in our corporate web development projects.

How Does SSR Work?

In a classic React app (CSR — client-side rendering), the browser receives a nearly empty HTML file plus a large JavaScript bundle; content appears only after the JavaScript runs. SSR reverses that order: the request hits the server, the server fetches the data, React components are rendered to HTML, and the browser receives a page with content already in it. The browser displays that HTML immediately; JavaScript then loads and makes the page interactive (hydration).

• The user requests the /products page.
• The server fetches fresh data from the database or API.
• React components are rendered to HTML on the server.
• The browser instantly displays populated HTML (fast LCP).
• JavaScript loads in the background and the page becomes interactive.

The most critical benefit of SSR is first-load speed: instead of a blank screen, the user sees real content within the first milliseconds. LCP — one of Google’s Core Web Vitals — is directly affected by this.

SSR vs SSG vs ISR vs CSR

The power of Next.js is that you are not locked into a single rendering strategy; you choose per page. The difference between the four strategies is when the HTML gets generated:

• SSR (on the server, every request): Content is generated fresh on each request. Ideal for personalized dashboards and pages where prices change in real time.
• SSG (at build time, once): HTML is generated when the site is built and served from a CDN. The fastest option for blogs and corporate marketing pages.
• ISR (build + periodic refresh): SSG speed plus background regeneration at set intervals. A balanced choice for product listings and news sites.
• CSR (in the browser): HTML is built in the browser with JavaScript. Fine for logged-in, in-app screens where SEO does not matter.

How to Use SSR in Next.js (Code Example)

In the App Router you do not need a separate API to make a page SSR; disabling the cache while fetching data inside a Server Component is enough:

// app/products/page.tsx — rendered on the server on every request (SSR)
export default async function ProductsPage() {
  const res = await fetch('https://api.example.com/products', {
    cache: 'no-store', // SSR: fresh data on every request
    // alternative: next: { revalidate: 60 } → ISR (refresh every 60s)
  });
  const products = await res.json();

  return (
    <main>
      <h1>Products</h1>
      <ul>
        {products.map((p: { id: string; name: string }) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </main>
  );
}

The cache: no-store option puts the page into SSR mode; replace it with next: { revalidate: 60 } and the page becomes ISR. Older projects on the Pages Router achieve the same with getServerSideProps — one more reason migrating to the App Router both simplifies the code and adds flexibility.

When Should You Choose SSR?

SSR is not the right answer for every page; because the server runs on every request, it costs more than SSG/ISR. The practical rule: if the content changes per user or per moment, use SSR; if it is the same for everyone, use SSG/ISR. User dashboards, carts and pages showing live stock or prices need SSR; about, services and blog pages run both faster and cheaper with SSG/ISR. Traditional systems like WordPress cannot give you this per-page flexibility — we covered that comparison in detail in WordPress or Next.js?.

How SSR Affects SEO

Search engines and AI answer engines (ChatGPT, Perplexity, Gemini) want to see populated HTML when they crawl your page. With CSR, content arrives only after JavaScript runs, so indexing can be delayed or incomplete; with SSR/SSG, the very first response sent to the crawler is the full content. Titles, descriptions and structured data (JSON-LD) are also generated on the server, so every page ships with correct metadata. We walk through the implementation side step by step in our Next.js SEO guide.

Conclusion

SSR is one of the rendering strategies Next.js offers: HTML is generated on the server for every request, and users and search engines see content instantly. Using it well means choosing SSR/SSG/ISR per page — SSR for dynamic pages, SSG/ISR for static ones. If you are unsure which strategy fits your project, contact our web team or request a quote and let’s make the architectural decision together.