Prerendering Technology Comparison: SSR vs SSG vs ISR vs CSR

Why Different Rendering Modes Matter

In modern web development, the choice of rendering mode directly impacts website performance, SEO, user experience, and maintenance costs. Different application scenarios have vastly different requirements for rendering modes—a blog website needs blazing-fast initial load speeds and SEO friendliness, while an admin dashboard prioritises complex interactivity and real-time data updates.

The four mainstream rendering modes—CSR (Client-Side Rendering), SSR (Server-Side Rendering), SSG (Static Site Generation), and ISR (Incremental Static Regeneration)—each make different trade-offs between performance, flexibility, and operational complexity. This article provides an in-depth comparison to help you choose the best rendering strategy for your project.

It is worth stressing that these four options are not a linear "newer replaces older" progression but parallel "trade-off by scenario" choices. Picking the wrong mode will not break your site overnight, but it will keep charging you in the form of slow first screens, expensive servers, and painful rewrites once traffic grows.

Detailed Breakdown of the Four Rendering Modes

CSR - Client-Side Rendering

How it works: The server returns an empty HTML shell and JavaScript bundle. The browser executes the JS to render page content.

Representative Frameworks: Create React App, Vite + React/Vue

Advantages:

• Simple deployment, only needs static file hosting
• Fast page transitions (SPA experience)
• Low server load

Disadvantages:

• Slow initial load (requires downloading and executing JS)
• SEO unfriendly (crawlers struggle to index dynamic content)

The typical use case is tools that only work after login, such as admin dashboards and analytics panels. Users do not expect these pages to be indexed, and do not mind a few hundred extra milliseconds of first paint, but they do need complex interactions and state management — which is exactly what CSR delivers.

SSR - Server-Side Rendering

How it works: The server renders the complete HTML page upon receiving a request. The browser displays it directly and hydrates interactivity.

Representative Frameworks: Next.js, Nuxt.js, Remix

Advantages:

• First-screen content is visible quickly
• SEO friendly
• Suitable for dynamic content

Disadvantages:

• High server costs (every request requires rendering)
• Response time affected by data fetching speed

SSR suits pages whose content differs per user, such as a personal dashboard with live login state or pages that change with permissions. Its worst enemy is a slow API: if a page depends on an endpoint that takes 2 seconds to respond, every visitor waits 2 seconds on the server. Streaming rendering and caching are the usual mitigations.

SSG - Static Site Generation

How it works: All page HTML files are generated at build time. The server returns pre-built static files directly.

Representative Frameworks: Astro, Gatsby, Hugo, 11ty

Advantages:

• Fastest loading speed (pre-built HTML)
• High security (no runtime server)
• Low hosting costs (only needs CDN)

Disadvantages:

• Content updates require rebuilding
• Not suitable for dynamic data

Content sites (blogs, documentation, corporate sites) are almost all SSG beneficiaries: page content is fixed for long stretches, so it can be baked into static files and served from a CDN. With incremental builds, a site of a few hundred articles regenerates just one page when a single article changes, and build times stay perfectly acceptable.

ISR - Incremental Static Regeneration

How it works: Combines the benefits of SSG and SSR, regenerating specific pages on demand without a full rebuild.

Representative Frameworks: Next.js

The idea behind ISR is "behave like a static site, refresh quietly in the background when needed." For an e-commerce product page, for example, content is unchanged most of the time and can be static; when the price or stock changes, the system regenerates that one page on the revalidate interval. It adds an "expire then regenerate" layer over pure SSG while avoiding the repeated rendering that pure SSR requires.

Comparison Table

Selection Guide

By Scenario

• Content websites (blogs, documentation, corporate sites): SSG first—best value for money
• E-commerce platforms: ISR or SSR, needs to balance SEO and content freshness
• Admin dashboards: CSR is fully sufficient
• Social/news platforms: SSR for instant content display on first visit

Hybrid Strategy

Most modern frameworks support hybrid rendering modes. For example, in Next.js, you can use SSG, SSR, and ISR together:

// Statically generated marketing page
export async function getStaticProps() {
  return { props: { marketing: true } };
}

// ISR blog page
export async function getStaticProps() {
  return {
    props: { posts: await getPosts() },
    revalidate: 60,
  };
}

// SSR user dashboard
export async function getServerSideProps(context) {
  return {
    props: { userData: await fetchUserData(context.req.cookies.token) },
  };
}

A common hybrid rollout: the marketing homepage uses SSG, product listing pages use ISR (regenerated every 60 seconds), and the user cart uses SSR. Three modes working side by side in one project fit real business needs far better than a one-size-fits-all "whole site in one mode" approach.

A Complete Example

Say you are building a marketing-focused corporate site: the public blog, case studies, and pricing pages need to be fast with excellent SEO, so build them with SSG and serve from a CDN; on-site search and user bookmarks are post-login features, implemented with CSR; product documentation updates occasionally, so use ISR with a 10-minute revalidate. The result is near-100% CDN hit ratio, almost no request pressure on the origin, and documentation updates visible within 10 minutes of publishing. This combination puts each mode's strengths exactly where they matter.

Important Considerations

1. Don't over-engineer: Start with the simplest solution for your project and upgrade as needed
2. Consider team capabilities: SSR and ISR require higher operational expertise
3. Evaluate data update frequency: Content update frequency determines caching strategy
4. CDN caching strategy: Proper cache configuration can effectively compensate for performance gaps

Conclusion

No single rendering mode is suitable for all scenarios. Choosing the right approach depends on your project's specific needs—content update frequency, SEO requirements, team tech stack, and budget. As a general recommendation, consider SSG as the default choice, and gradually introduce ISR or SSR when dynamic content is needed. With the development of edge computing and streaming technologies, the boundaries between rendering modes will continue to blur.

Reference: https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration (Next.js ISR official docs)
Reference: https://www.smashingmagazine.com/2020/11/static-site-generator-build-logic-incremental-static-regeneration/ (Smashing Magazine on ISR)