1. Full Client-Side Rendering (CSR)

Regular Single-Page Application

1. Full Client-Side Rendering (CSR)

Regular Single-Page Application

Serve only static files and fetch data through AJAX

Architecture

Bad, Cost more in indexing (running JS, potential wrong results)

SEO

Fastest TTFB (leveraging CDN)

performance

Blank page in the first loading (TTI >>> FCP)

2. CSR w/ Pre-rendering

(Build-time

prerendering)

JS

2-1. CSR w/ Pre-rendering (Var 1.)

Var 1. generates pre-rendered static HTML for each page and runs as a SPA once a page is loaded.

Longer build-time process 

Architecture

Inflexible for building more content 

Static resources that may require more space to place

2-1. CSR w/ Pre-rendering (Var 1.)

Not flexible. Works only in a given framework environment

Development Experience

 TTI = FCP, Fast like static pages

performance

Gatsby, VitePress

FRAmework

2-2. CSR w/ Pre-rendering (Var 2.)

Var 1. generates only the app's shell and serves as a SPA.

Same as Full CSR, but leveraging the static layouts

Architecture

hack the UX w/ App shell (PWA) (FCP → LCP)

performance

3. Server-Side Rendering w/ Rehydration (SSR)

Rehydration = server-side + client-side rendering

provide whole static HTML at the first landing, and runs SPA in coming navigations

3. Server-Side Rendering w/ Rehydration (SSR)

Cost Big: Cost more resources for running JS and rendering contents on server-side

Architecture

e.g. Browser -> CDN & Render Server (Node.js) -> API Server

Most flexible → leverage all possible solutions for rendering (acts as a real server. e.g. layered cache, runtime purging, throttling...)

3. Server-Side Rendering w/ Rehydration (SSR)

e.g. Different APIs, Debugging, API calls, Memory Leak...

Development Experience

Complex: One code runs in two environment (Browser, Node.js)

Framework

Next.js, Nuxt.js

5. Static site generation

(Build-time

prerendering)

5. Static site generation

Serve only static files

Architecture

theoretically The Best

Performance, SEO

functionality

Inflexible for building dynamic content

build-time JS for rendering, runtime JS as the add-ons

More JS could be added

6. Server-side rendering w/ template engine

Simple. could combine rendering & API server as one

Architecture

e.g. Django = rendering server, API server, JS build-time bundling

Server need to render and serve documents

6. Server-side rendering w/ template engine

Development Experience

Coupled with UI and Data (No Separation of Concerns)

Skew. JS Components are more flexible than template engines

--> should consider SPA

6. Server-side rendering w/ template engine

philosophy of less js

Could have no build-time through deployments

e.g. DHH built Hey with fewer JS bundling (https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203)

4. Incremental Static Regeneration

4. Incremental Static Regeneration

4. Incremental Static Regeneration

4. Incremental Static Regeneration

4. Incremental Static Regeneration (ISR)

Flexible as SSR Rehydration

features

Serve as static pages at first loads

Cache Revalidation (no thundering herd problem)

Purge cache on demand (event-driven)

Based on Server-Side Rendering w/ Hydration

4. Incremental Static Regeneration (ISR)

3 advantages in one which no one did before:

3. Minimize the API call & rendering cost

2. Ability to keep everything updated / dynamic

1. Instant Performance

4. Incremental Static Regeneration