Web Rendering Strategies: SSG, SSR, CSR, ISR & PPR

When building a frontend, one useful question is:

Who creates the page structure, and when?

But first, the word rendering itself can mean two things.

What Does Rendering Mean?

At the browser level, every website is rendered by the browser.

The browser takes HTML and CSS and turns them into pixels:

HTML + CSS
  ↓
DOM / CSSOM
  ↓
Layout
  ↓
Paint
  ↓
Pixels

So even a plain static HTML file is still rendered by the browser.

When people talk about CSR, SSR, and SSG, however, “rendering” usually means:

How is the page’s HTML or UI structure produced before the browser displays it?

Page structure produced by
├── developer → static HTML
├── browser JavaScript → CSR
├── build process → SSG
└── server → SSR
Then
↓
Browser renders it into pixels

Static Files

A website can simply consist of files written directly by the developer:

index.html
styles.css
script.js

Here, index.html already contains the page content.

script.js may add interactions, but using JavaScript does not automatically make the site CSR.

Client-side JavaScript ≠ Client-Side Rendering

If JavaScript only adds behavior to existing HTML, it is still a static site with client-side JavaScript.

A host such as GitHub Pages can serve these files directly.

If you wrote the HTML yourself, this is not SSG because no generator produced it.

Client-Side Rendering

With Client-Side Rendering (CSR), JavaScript in the browser creates most of the UI.

A simple CSR app may look like:

app.js
index.html
styles.css

The HTML may contain only:

<div id="root"></div>

Then:

Browser loads HTML
      ↓
Loads JavaScript
      ↓
JavaScript creates UI
      ↓
Browser paints it

app.js may also handle routing, state, and interactions.

Modern apps often use code splitting, so the browser does not necessarily download the entire application at once.

Pre-rendering

With pre-rendering, the page’s HTML is produced before client-side JavaScript needs to create the initial UI.

Static Site Generation

With Static Site Generation (SSG), HTML is generated ahead of time, usually during a build.

Source
  ↓
Build
  ↓
Generated HTML/CSS/JS
  ↓
Static host / CDN
  ↓
Browser

A build may generate files such as:

index.html
about.html
products/42.html

SSG works well for blogs, docs, landing pages, and other mostly static content.

Incremental Static Regeneration (ISR) extends this idea by allowing generated pages to be refreshed after deployment.

Server-Side Rendering

With Server-Side Rendering (SSR), HTML is generated when a request reaches the server.

Suppose the user opens:

https://example.com/products/42

The flow is:

Browser
  ↓
GET /products/42
  ↓
SSR server
  ↓
match route
  ↓
load data
  ↓
generate HTML
  ↓
send HTML
  ↓
browser displays it

The page does not need to exist beforehand as products/42.html.

The server may simply have routing logic such as:

/             → homepage
/about        → about page
/products/:id → product page

The homepage works the same way:

GET /
  ↓
match homepage route
  ↓
render homepage
  ↓
return HTML

In true SSR, / does not need to exist as a prebuilt index.html.

Does SSR use a template engine?

It can.

Traditional server applications may use:

Data +
Template
 ↓
Template engine
 ↓
HTML

For example:

<h1>{{ product.name }}</h1>

But a separate template engine is not required.

React-based frameworks can render components directly on the server:

Components + Data
       ↓
Server renderer
       ↓
HTML

SSR describes where and when the HTML is produced, not which rendering library is used.

What gets deployed for SSR?

With SSR, you usually deploy a server-side application rather than only finished HTML files.

SSR application
├── server code
├── routes
├── rendering logic
├── client JavaScript
├── CSS
└── assets

It may run as a Node.js server, serverless function, edge runtime, or another server environment.

A typical production setup may look like:

Browser
  ↓
CDN / Reverse Proxy / Load Balancer
  ↓
SSR application

The reverse proxy is infrastructure around SSR, not SSR itself.

What reaches the browser?

The server itself is not shipped to the user.

The browser may receive:

HTML
CSS
client JavaScript
images
other assets

Server code, database credentials, and private backend logic stay on the server.

So:

CSR → browser JavaScript creates initial UI
SSG → build creates HTML ahead of time
SSR → server creates HTML for a request

Hydration

SSG and SSR pages can still use client-side JavaScript.

The browser first receives already-produced HTML. JavaScript can then attach application behavior to it.

This is called hydration.

HTML arrives
   ↓
Browser displays it
   ↓
JavaScript loads
   ↓
Hydration
   ↓
Page becomes interactive

So SSG or SSR may produce the initial HTML while JavaScript handles interactions afterward.

Performance and Resource Usage

CSR generally shifts more work to the user’s device.

The browser may need to download, parse, and execute JavaScript before creating much of the UI.

This can increase CPU, RAM, battery, and network usage.

SSR shifts the initial UI-generation work to the server.

Request
  ↓
load data
  ↓
server renders
  ↓
send HTML

This can make content appear sooner, but the server must do more work per request and may increase Time to First Byte.

SSR does not automatically mean low browser usage. If a large JavaScript bundle is sent afterward for hydration, the browser may still do substantial work.

SSG moves the generation work to build time and usually requires very little server work per request.

So:

CSR shifts more initial UI work to the browser. SSR shifts it to request-time server execution. SSG shifts it to build time.

SEO

SSG and SSR are generally SEO-friendly because crawlers can receive meaningful HTML directly.

For example:

<h1>Keyboard</h1>
<p>$100</p>

With pure CSR, the initial response may instead contain:

<div id="root"></div>

and JavaScript may need to run before the content appears.

Hybrid Rendering

Modern frameworks can mix approaches.

Partial Prerendering (PPR) can keep some parts of a page static while rendering other parts dynamically.

Page
├── header → static
├── article → static
└── user data → dynamic

Native App Frontends

Native apps are not usually described using SSG, SSR, or CSR.

A native application ships compiled application code to the device.

For example:

iOS
├── Swift / Objective-C
└── SwiftUI / UIKit
Android
├── Kotlin / Java
└── Compose / Views

When the app opens:

Installed app
   ↓
OS runtime
   ↓
Native UI framework
   ↓
UI rendered on device

Native apps often fetch data from an API:

Native app
   ↓
API request
   ↓
JSON
   ↓
Native app renders UI

This is conceptually similar to CSR because rendering logic runs on the user’s device, but the better term is native client rendering.

CSR specifically refers to web UI rendered using browser-side code.

In Short

Frontend
├── Web
│   ├── Static HTML
│   │   └── developer writes HTML
│   │
│   ├── CSR
│   │   └── browser JavaScript creates UI
│   │
│   ├── Pre-rendering
│   │   ├── SSG → build creates HTML
│   │   ├── ISR → static HTML can regenerate
│   │   └── SSR → server creates HTML per request
│   │
│   └── Hybrid
│       └── PPR
│
└── Native apps
    └── native client rendering

The most important distinction is:

All web pages are ultimately rendered by the browser into pixels. CSR, SSG, and SSR describe how the page structure is produced before that final browser rendering happens.

No resources added for this note.