Prerendering vs SSR in SvelteKit: trade-offs?

WHY IT EXISTS: Different pages have different freshness requirements. A blog post changes rarely; a live feed changes per request. SvelteKit lets you choose per route to optimize both performance and data currency.

THE MENTAL MODEL: Prerendering is compile-time. SSR is runtime. Prerender = write HTML to disk at build time, serve as static files. SSR = execute server-side code per request, send HTML. Prerender is fastest (no compute on request) but data is fixed at build time. SSR is fresh but more expensive.

HOW IT WORKS: In SvelteKit config (svelte.config.js), set prerender: true globally or per-route. Pages marked for prerender run their load() function once at build (not per request), and their HTML is written to dist/. The build step calls your API or database, renders the page, and freezes the output. On production, serve the static files directly; no server compute. SSR pages skip this; instead, on each request, the server runs load() and renders fresh HTML. Trade-offs: Prerender gives near-zero latency (CDN edge) and zero server load, but data is stale until the next deploy. SSR has request latency and server cost, but data is always current. For data-driven pages (e.g., a product listing that updates hourly), consider a hybrid: prerender for SEO performance, but pair it with a client-side fetch or cache invalidation strategy (Incremental Static Regeneration via a webhook, or rely on client-side revalidation).

WHEN IT MATTERS: High-traffic blogs and marketing sites favor prerender (fast, cheap, great SEO). Real-time apps (dashboards, feeds) need SSR. E-commerce often prerender category pages (mostly static) and SSR search results (dynamic).

ONE CONCRETE EXAMPLE: A SvelteKit site with a /products page. If products rarely change, mark it for prerender: at build, load() fetches all products from your CMS, renders the page, and writes static HTML. On deploy, users get instant load. If products update weekly, trigger a rebuild weekly. Alternatively, SSR the page: each request calls load(), hits the database, renders fresh. This costs more per request but always shows current data.