Rendering and architecture · Comparison
CSR vs SSR vs SSG vs ISR
Four answers to one question: when is a page's HTML built? In the browser, on the server for each request, once at build time, or at build time with refreshes in the background.
4 options · 7 questions side by side · updated
| Compare | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| HTML is built | In the browser | On the server, per request | At build time | At build time, then refreshed |
| First view | Slow: waits for JavaScript | Fast | Very fast, from a CDN | Very fast, from a cache |
| SEO | Weak without extra work | Strong | Strong | Strong |
| Data freshness | Live, fetched in the browser | Live on every request | As of the last build | Refreshed on a timer or on demand |
| Server cost | None: static files | Work on every request | None after the build | Small: occasional rebuilds |
| Personalised pages | Yes, in the browser | Yes | No, same for everyone | No, same for everyone |
| Typical use | Dashboards behind a login | Search results, feeds, baskets | Blogs, docs, marketing pages | Large stores and news sites |
How to choose between CSR, SSR, SSG and ISR
- Pick SSG for pages that are the same for everyone and change rarely.
- Pick ISR when those pages are numerous or change often, and a few minutes of staleness is acceptable.
- Pick SSR for pages that must be fresh or personalised on every request.
- Pick CSR for app screens behind a login, where search engines do not matter.
The options
- CSRThe server sends a nearly empty page plus JavaScript, and the visitor's browser builds the content itself. It suits app-like screens behind a login.
- SSRThe server builds the full HTML for a page each time someone asks for it, so content appears straight away and search engines can read it.
- SSGEvery page is built into plain HTML files once, when the site is published, and then served as it is from a CDN, which is quick and cheap for pages that are the same for everyone.
- ISRStatic pages that rebuild themselves in the background after a set time or when their content changes, giving a site static speed without full rebuilds.
More comparisons
- Single-page app vs multi-page appDoes the browser load one page and swap its contents, or load a new page for every link? The choice affects speed, SEO and how much the app has to handle itself.
- Monolith vs microservicesOne deployable application or many small ones. The choice is less about technology than about team size and how independently the parts of a product need to change.
- React vs Vue vs Angular vs SvelteThe four main ways to build interactive web interfaces. Each can build almost anything; they differ in how much they include, how they update the page and how large their communities are.
- Next.js vs Vite vs Astro vs Create React AppFour ways to start a React-based website or app. They are not quite the same kind of tool: Next.js and Astro are frameworks, Vite is a build tool, and Create React App is a retired starter.
- Tailwind CSS vs Radix UI vs shadcn/uiThese three are often named together because they stack: Tailwind provides the styling, Radix provides accessible behaviour, and shadcn/ui combines styling with accessible primitives (Radix or Base UI) into components you own.
- Zustand vs Redux vs TanStack QueryZustand and Redux manage state that lives in the browser; TanStack Query manages data that lives on a server. Many apps use one of the first two alongside the third.
Crafted in the dark. Shipped to the world.
Tell us what you are building. You get a private project space with a proposal and a line-by-line quote within a day.