SSG, SSR, ISR, RSC: Next.js Rendering Modes Explained for Non-Developers

If you have been talking to a development team about rebuilding your website with Next.js, you have almost certainly heard terms like SSG, SSR, ISR, RSC, and the App Router. These are presented as technical distinctions, and they are — but they are also business distinctions. The rendering mode chosen for each page directly affects how fast it loads, how well it ranks in Google, how fresh the content is, and how much it costs to run.

This post demystifies each rendering mode in plain language. By the end, you will understand what each acronym means, when each approach is appropriate, and why having a framework that lets you mix them intelligently is a meaningful competitive advantage over traditional CMS platforms that are locked into a single rendering model.

Why Rendering Mode Matters: The Core Trade-Off

Every web page is fundamentally an HTML document — a file containing the structure and content that a browser renders into a visual page. The central question of web architecture is: when and where is that HTML document assembled?

• Assembled at build time and stored as a file: Fastest possible delivery. The file is cached globally on CDN edges and delivered immediately to any visitor, anywhere. No computation required at request time.
• Assembled on the server at request time: Slightly slower delivery (server must compute before responding), but the content can be fully current and personalised to the specific visitor.
• Assembled in the browser using JavaScript: The server sends a mostly-empty HTML shell; the browser downloads JavaScript, executes it, and builds the page. Flexible for complex interactivity, but slow initial load and poor SEO if not managed carefully.

Traditional CMS platforms like WordPress are locked into server-side rendering for every page — every visit triggers a database query and PHP execution cycle. That is why caching plugins are necessary on WordPress: they work around the platform's default by storing the server-rendered output and serving it as if it were a static file. Next.js does not need this workaround because it can choose the right approach for each page by design.

SSG: Static Site Generation — Build Once, Serve Infinitely

What it means

SSG renders pages during the build process — before any visitor arrives. The output is a collection of complete HTML files that are uploaded to a CDN and served directly to visitors worldwide. No server computation happens at request time.

What this means for your business

• Lighthouse Performance scores of 90–100 — structurally achievable with SSG in a way that server-rendered sites cannot match
• TTFB (Time to First Byte) under 50ms vs. 300–800ms for WordPress — a direct input to Google's ranking algorithm
• Zero server infrastructure to maintain for the public-facing site — no PHP processes, no database connections on request
• Handles unlimited traffic spikes without degradation — a CDN edge can serve the same file to 10 or 10 million simultaneous visitors

Best used for

Landing pages, feature pages, about pages, service descriptions, case studies, blog posts that do not change frequently. For a typical marketing site, SSG is the right choice for 80–90% of pages.

The limitation

Content is only as fresh as the last build. If you publish a new blog post and the site does not rebuild, visitors will not see it. This limitation is directly addressed by ISR, described next.

ISR: Incremental Static Regeneration — Static Speed With Living Content

What it means

ISR extends SSG with automatic background regeneration. Pages are pre-built and served from CDN (same performance as SSG), but Next.js automatically regenerates individual pages in the background based on a configured time interval or on-demand trigger — without requiring a full site rebuild.

The stale-while-revalidate pattern

You configure a revalidation interval on a page — say, 60 seconds. The first visitor after that interval expires receives the cached version while Next.js generates a fresh version in the background. The next visitor receives the updated version. You can also use on-demand ISR: when a content editor publishes a new post in Payload CMS, a webhook triggers Next.js to regenerate only the specific pages affected by that change. The blog index and the new post page are updated immediately; the rest of the site is untouched.

What this means for your business

• Same delivery performance as SSG — CDN-cached, globally distributed, sub-50ms TTFB
• Content updates without rebuild overhead — a site with 10,000 blog posts does not need to rebuild all 10,000 pages when one is updated
• On-demand revalidation means content editors see their changes go live within seconds of publishing

Best used for

Blog post listings, individual blog posts, case studies, product pages, team pages. Any content that is mostly stable but needs to reflect CMS updates promptly — which is most of a content-heavy marketing site.

SSR: Server-Side Rendering — Always Current, Always Computed

What it means

SSR generates the HTML on the server for each individual request, using the most current data available. Every visitor receives a freshly computed page. The browser receives complete HTML — indexable by search engines, fast on first paint — but the server has performed computation for every visitor.

What this means for your business

• Pages are always current — no stale cache, no revalidation delay
• Content can be personalised per visitor — the server can read cookies, session data, or request headers to tailor the response
• More server compute required — appropriate for pages where freshness and personalisation justify the cost, not for static marketing content

Best used for

Pages that require per-visitor personalisation, real-time pricing or inventory data, authenticated content (dashboards, account pages), or content so time-sensitive that even a 60-second cache would be problematic. For most marketing site pages, SSR is not necessary and adds server overhead without meaningful user benefit.

RSC: React Server Components — The Architecture That Changes Everything

What it means

React Server Components are a newer architecture, now the default in Next.js App Router, that allows individual components — not just pages — to run on the server. Server Components execute on the server, fetch their own data, render to HTML, and ship zero JavaScript to the browser for their own rendering logic.

Why this matters differently from SSR

SSR renders entire pages on the server. RSC operates at the component level within a page. A page can have some components that are pure Server Components (zero JavaScript shipped, data fetched server-side) and other components that are Client Components (JavaScript shipped for interactivity). This granularity is new — and it means a page can be mostly static-rendered Server Components with specific interactive islands of Client Components, rather than being forced into a single rendering model.

What this means for your business

• Dramatically smaller JavaScript bundles — only interactive components (dropdowns, forms, carousels) ship JavaScript; everything else ships HTML
• Faster Time to Interactive — the browser has less JavaScript to parse and execute before the page is usable
• Better performance on low-end devices and slow connections, which are the majority of global mobile traffic

Best used for

Any component that displays content but does not need to respond to user interactions: headers, footers, blog post bodies, team member cards, service descriptions, testimonials. In a typical marketing site, 70–80% of components can be Server Components.

How a Real Marketing Site Mixes All Four

The power of Next.js is not any single rendering mode — it is the ability to use the right mode for each piece of content, within a single coherent application:

• Homepage: SSG with on-demand ISR. Pre-built for maximum performance; regenerated when the CMS content is updated.
• Blog post listing: ISR with 60-second revalidation. Always fast, reflects new posts within 60 seconds of publication.
• Individual blog posts: SSG with on-demand ISR. Static for performance; regenerated when the specific post is updated in the CMS.
• Navigation and footer: Server Components fetching from Payload CMS Local API. Zero JavaScript shipped for these components.
• Testimonial carousel: Client Component for interactivity. JavaScript ships only for this component.
• Contact form: Client Component with a Server Action for form submission. Interactivity is client-side; submission logic runs server-side without a separate API endpoint.
• Pricing page (if personalised): SSR. Fetches the visitor's location from headers, displays region-appropriate pricing on every request.

A WordPress site cannot make these distinctions. Every page goes through the same PHP request lifecycle, regardless of whether the content is static or dynamic. Caching plugins approximate static delivery for some pages, but they do not offer per-component rendering control or the ability to mix strategies at a granular level.

The App Router: The Modern Way to Build Next.js

Before Next.js 13, rendering modes were configured at the page level using specific data-fetching functions (getStaticProps, getServerSideProps). The App Router, introduced in Next.js 13 and stabilised in Next.js 14–15, reorganises this around a more intuitive file system structure and makes Server Components the default.

The practical implication for business owners: when your development team says they are using the App Router, they are using the current-generation Next.js architecture that unlocks all of the above rendering modes and React Server Components. When they say Pages Router, they are using the previous generation — still supported and capable, but without the full Server Component architecture. For new projects, the App Router is the correct choice.

Conclusion: Rendering Mode Is a Business Decision

Understanding rendering modes — even at the conceptual level described here — makes you a more informed participant in the technical decisions your development team makes. When they propose ISR for the blog and SSG for the landing pages, you will understand why. When they ask about on-demand revalidation webhooks from the CMS, you will understand what they are trying to achieve.

And when a vendor recommends a platform that is locked into a single rendering model, you will know what you are giving up: the flexibility to serve each piece of content through the architecture that is right for it, rather than the only architecture the platform supports.

Have questions about how these rendering choices would apply to your specific site? Book a free technical consultation — we will map your content types to the right rendering approach and show you what the performance impact would look like.