# Static, SSR or ISR: how to pick a rendering mode in 2026

Last updated: 2026-11-10

Build a page ahead of time when everyone sees the same thing and it changes only when you deploy. Render it on each request when it depends on who is asking, on cookies or on data that must be current to the second. Use ISR, or a cached response that refreshes in the background, when the page is the same for everyone but changes more often than you want to rebuild. Most real apps mix all three, route by route, and every modern framework lets you do that.

## The three modes at a glance

| Mode | When the HTML is made | How fresh it is | What the host needs | Good fit |
|---|---|---|---|---|
| Static | Once, at build time | As fresh as your last deploy | A file server | Docs, blogs, marketing pages |
| Server rendering, SSR | On every request | Current when the request arrives | A server or isolate runtime | Dashboards, carts, logged-in pages |
| ISR or stale-while-revalidate | At build or on the first request, then again after a set time or on demand | Seconds to hours behind, by your choice | A runtime plus a shared cache | Product pages, listings, news |
| Client-side rendering | In the browser, after JavaScript loads | Whatever the API returns | A file server for the shell | Admin areas behind a login |

## What to check before you pick a mode

- **Does the page change per visitor?** Anything that reads a session cookie, a header or the user's account must render on request. ISR caches one version for everyone, and the SvelteKit Vercel docs warn that user-specific data in an ISR route can leak between visits.
- **How stale can it be?** If a price or stock level must be exact, render on request. If a minute or an hour is fine, cache it.
- **How many pages are there?** Static builds produce one HTML file per URL. With tens of thousands of product pages, build time grows, and ISR lets you build a few and render the rest on first visit.
- **What will it cost to run?** A static page served from files runs no code. A server-rendered page runs your code for every visit, and the Next.js ISR guide notes that background regeneration counts as extra compute on hosts that bill per request.

## Static: built once, served as files

Static rendering, also called prerendering or SSG, runs your components during the build and writes an HTML file for each URL. The web.dev guide on rendering describes it as giving a consistently fast time to first byte, because nothing is generated when the request arrives, and the files can sit on any CDN.

The catch is that you must know every URL at build time, and a content change means a new build. Static exports also give up server features. The Next.js static export guide lists what stops working with `output: 'export'`: ISR, Server Actions, rewrites, redirects, headers, Proxy, Draft Mode and image optimization with the default loader, among others.

If your whole site fits this mode, any file host will do; see [static site hosting in Europe](/i/static-site-hosting-europe).

## Server rendering: HTML made on each request

With SSR, the server runs your page code for every request and sends finished HTML, which the browser then hydrates. web.dev points out the trade: you get a fast first paint and less JavaScript in the browser, but generating the page takes time, which can raise time to first byte, and the server does that work on every visit.

Use it when the response depends on the request: account pages, search results, anything behind a login, or data that has to be current. You need a host that runs your framework's server output, as a Node.js process or on an isolate runtime.

## ISR and stale-while-revalidate: cached, then refreshed

ISR is a Next.js term, and other frameworks now offer the same idea under other names. A page is rendered once, cached, and served from the cache. After the time you set, the next visitor still gets the cached copy while a fresh one renders in the background. You can also clear it on demand with `revalidatePath` or `revalidateTag` in Next.js. Vercel describes the pattern as stale-while-revalidate, and the same HTTP directive does the same job in other frameworks.

ISR is where hosts differ the most. The Next.js guide says ISR needs the Node.js runtime, doesn't work with a static export, and keeps a separate file-system cache on each instance, so an on-demand revalidation only clears the instance that receives it unless you add a shared cache handler. [How Next.js ISR works outside Vercel](/i/nextjs-isr-self-hosted) covers that setup in detail.

## Mixing modes per route

You rarely choose one mode for the whole app. Each framework sets it per page or per group of routes:

| Framework | Static | Rendered on request | Cached and refreshed |
|---|---|---|---|
| Next.js | The default for routes with no request data; `output: 'export'` for a fully static site | Routes that read request data or use uncached fetches | `export const revalidate = 60`, plus `revalidatePath` and `revalidateTag` |
| Astro | The default for every page | `export const prerender = false` or `output: 'server'`, with an adapter | Route caching with `Astro.cache`, added in Astro 7 |
| Nuxt | `prerender: true` in `routeRules` | The default, called universal rendering | `swr` and `isr` route rules |
| SvelteKit | `export const prerender = true`, or `adapter-static` for the whole app | The default | The `isr` option of the Vercel adapter |

A few details matter here. Nuxt's docs say its `isr` rule adds the response to the CDN cache only on Netlify or Vercel, while `swr` caches on the server or a reverse proxy, and hybrid rendering isn't available with `nuxt generate`. SvelteKit's `prerender = 'auto'` prerenders the pages its crawler finds or you list, and still server-renders any other URL on that route. Astro's route caching needs a cache provider: a built-in in-memory one, or the experimental CDN providers in its Netlify, Vercel and Cloudflare adapters.

## What each mode needs from a European host

ISR is the mode to test before you move, because it depends on where the host keeps cached pages and whether every server hears about a revalidation.

**Eurobase** runs Next.js, Nuxt, Astro and SvelteKit on V8 isolates, on European infrastructure run by Scaleway, a French provider. Static assets are served without running your code. In a Next.js app without its own Wrangler config, Eurobase keeps the ISR cache, the data cache and `use cache` entries, and calls to `revalidatePath` or `revalidateTag` work the way Next.js documents them. Two Next.js limits apply: pages that use Cache Components are rendered for each visit, and a whole Next.js response is stored only if your app sets `CDN-Cache-Control`. With the other frameworks, a response that sends `Cache-Control: public, s-maxage=60` is kept for 60 seconds and answered without running your Worker, `stale-while-revalidate` hands out the old copy while a fresh one renders, and you can purge by tag, by path or everything. Each deployment begins with an empty cache. Plans are Free, Starter at €10 and Pro at €20 a month + VAT. There are no usage charges today: work over a limit is refused, apps on V8 isolates and Functions stop until the monthly reset, and containers and static sites keep serving. There are no preview deployments, and ISO 27001 and SOC 2 certification is still in progress.

For a host-by-host comparison, see [Next.js hosting in Europe](/i/nextjs-hosting-europe), [Astro hosting in Europe](/i/astro-hosting-europe), [Nuxt hosting in Europe](/i/nuxt-hosting-europe) and [SvelteKit hosting in Europe](/i/sveltekit-hosting-europe).

## How to choose

1. Start static. Make every page static unless it has a reason not to be.
2. Move a page to server rendering when it reads cookies, headers or the signed-in user, or when its data must be exact.
3. Move a page to ISR or a cached response when it's the same for everyone but static builds can't keep up with how often it changes.
4. Before you migrate, check that your host stores cached pages somewhere every server can see, and test a revalidation end to end.

## Frequently asked questions

### Is SSR better for SEO than a static site?

Not in itself. Both send complete HTML that crawlers can read. A static page is usually faster to deliver because nothing renders at request time. SSR helps SEO compared with client-side rendering, where the first HTML is mostly empty.

### Is ISR the same as caching SSR responses?

Close, but not identical. Both serve a stored copy and refresh it in the background. ISR in Next.js also prerenders pages at build time, tracks cache tags and lets your code revalidate a path or tag. An SSR response with `s-maxage` and `stale-while-revalidate` gets the same refresh behaviour from any cache that honours those headers.

### Can I use ISR with a static export?

No. The Next.js docs list ISR among the features a static export doesn't support, because something has to run when a page is regenerated. Nuxt's hybrid rendering likewise isn't available with `nuxt generate`.

### Does server rendering cost more to host?

It runs your code on every visit, so it uses more CPU than serving a file, and per-request billing grows with traffic. On a flat plan such as Eurobase's, the cost shows up as a limit instead: Worker CPU time counts against a monthly allowance, while static assets and cached responses use none.

## Sources

- [web.dev: Rendering on the web](https://web.dev/articles/rendering-on-the-web)
- [Next.js ISR guide](https://nextjs.org/docs/app/guides/incremental-static-regeneration) and [Next.js static exports](https://nextjs.org/docs/app/guides/static-exports)
- [Vercel ISR docs](https://vercel.com/docs/incremental-static-regeneration)
- [Astro on-demand rendering](https://docs.astro.build/en/guides/on-demand-rendering/) and [Astro route caching](https://docs.astro.build/en/guides/caching/)
- [Nuxt rendering modes](https://nuxt.com/docs/guide/concepts/rendering)
- [SvelteKit page options](https://svelte.dev/docs/kit/page-options) and [SvelteKit Vercel adapter](https://svelte.dev/docs/kit/adapter-vercel)
- [Eurobase cache docs](/docs/cache), [Workers on Eurobase](/docs/workers), [Containers and static sites](/docs/containers), [Next.js hosting on Eurobase](/hosting/nextjs) and [Plans and limits](/docs/plans)