Page options (SSR, CSR, prerender) in Svelte - Deep Dive

Overview - Page options (SSR, CSR, prerender)

What is it?

Page options in Svelte define how a web page is created and delivered to users. SSR (Server-Side Rendering) means the page is built on the server before sending it to the browser. CSR (Client-Side Rendering) means the page is built in the browser using JavaScript. Prerender means the page is built once ahead of time and served as a static file.

Why it matters

These options affect how fast a page loads, how well it works on different devices, and how search engines see it. Without these choices, websites might be slow, hard to find, or use too much data. Choosing the right option helps make websites faster, more reliable, and easier to use.

Where it fits

Before learning page options, you should understand basic web pages and how browsers work. After this, you can learn about routing, data fetching, and advanced performance techniques in Svelte.

Mental Model

Core Idea

Page options decide where and when the page content is created: on the server, in the browser, or ahead of time.

Think of it like...

It's like ordering a meal: SSR is like the chef cooking your food fresh when you order, CSR is like getting raw ingredients and cooking it yourself at home, and prerender is like buying a ready-made meal from the store.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   SSR (Server)│──────▶│  Send full    │──────▶│  Browser shows │
│  builds page  │       │  HTML page    │       │  ready page   │
└───────────────┘       └───────────────┘       └───────────────┘

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   CSR (Client)│──────▶│  Send minimal │──────▶│ Browser builds│
│  sends JS    │       │  HTML + JS    │       │  page on fly │
└───────────────┘       └───────────────┘       └───────────────┘

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Prerender     │──────▶│  Build once   │──────▶│ Serve static  │
│  build at dev │       │  static HTML  │       │  page fast   │
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is Server-Side Rendering (SSR)?

Concept: SSR means the server creates the full HTML page before sending it to the browser.

When a user visits a page, the server runs the Svelte code to build the page's HTML. This HTML is sent to the browser, which can show the page immediately without waiting for JavaScript to run. Later, JavaScript can take over to make the page interactive.

Result

Users see a fully loaded page quickly, even if their device is slow or has JavaScript disabled.

Understanding SSR helps you see how servers can speed up page loading and improve user experience by sending ready-to-view content.

2

Foundation

What is Client-Side Rendering (CSR)?

Concept: CSR means the browser builds the page using JavaScript after receiving minimal HTML from the server.

The server sends a basic HTML shell and JavaScript code. The browser downloads and runs the JavaScript, which creates the page content dynamically. This can delay the initial view but allows rich interactivity.

Result

Users see a blank or loading screen first, then the page appears once JavaScript finishes running.

Knowing CSR shows how browsers can build pages themselves, which is useful for apps needing lots of user interaction.

3

Intermediate

What is Prerendering in Svelte?

Concept: Prerendering means building the page once ahead of time into a static HTML file.

During the build process, Svelte creates the full HTML for the page and saves it as a file. When users visit, the server just sends this file without running code. This is great for pages that don’t change often.

Result

Pages load very fast because they are static files served directly, with no server computation needed on each request.

Understanding prerendering helps you optimize pages that don’t need to change often, saving server work and speeding up delivery.

4

Intermediate

How to Choose Between SSR, CSR, and Prerender

🤔Before reading on: Do you think SSR always makes pages faster than CSR? Commit to your answer.

Concept: Each option has strengths and tradeoffs depending on page needs like speed, interactivity, and content freshness.

SSR is good for fast initial load and SEO but needs server resources. CSR is good for highly interactive apps but slower to show content. Prerender is best for static pages that rarely change, offering fastest load but no dynamic data.

Result

You can pick the best rendering method for each page to balance speed, interactivity, and server cost.

Knowing the tradeoffs prevents blindly choosing one method and helps build better user experiences.

5

Intermediate

SvelteKit Page Options Syntax

🤔Before reading on: Do you think setting 'ssr: false' disables server rendering completely? Commit to your answer.

Concept: SvelteKit lets you control rendering per page using options like 'ssr' and 'prerender' in a page’s configuration.

In a +page.js or +page.server.js file, you can export 'export const ssr = true' to enable SSR or 'false' to disable it. Similarly, 'export const prerender = true' tells SvelteKit to prerender the page at build time. These flags control how the page is built and served.

Result

You can customize rendering behavior easily per page to fit your app’s needs.

Understanding these flags lets you fine-tune performance and behavior without complex code changes.

6

Advanced

How Hydration Works in SSR and Prerender

🤔Before reading on: Do you think SSR pages are fully static after loading? Commit to your answer.

Concept: Hydration is the process where JavaScript takes over a server-rendered or prerendered page to make it interactive.

After the server sends the HTML, the browser downloads the JavaScript bundle. This JavaScript connects to the existing HTML elements, adding event listeners and dynamic behavior without rebuilding the whole page. This keeps the page fast and interactive.

Result

Users get a fast initial load with full interactivity after hydration completes.

Knowing hydration explains how SSR and prerendered pages become dynamic, avoiding the blank screen problem of CSR.

7

Expert

Edge Cases and Pitfalls in Page Options

🤔Before reading on: Do you think prerendered pages can handle user-specific data like login info? Commit to your answer.

Concept: Some page options have limits, like prerendered pages not supporting dynamic user data, and SSR needing server resources that can slow under load.

Prerendered pages are static and can’t show user-specific content unless client-side code updates them after load. SSR pages can slow if the server is busy or if data fetching is slow. CSR can cause SEO issues if content is not visible to search engines. Choosing the wrong option can cause bugs or poor performance.

Result

You learn to avoid common mistakes and pick the right option for each scenario.

Understanding these limits helps build robust apps and avoid surprises in production.

Under the Hood

SSR runs the Svelte compiler and page code on the server to produce HTML strings. This HTML is sent to the browser, which then downloads JavaScript to hydrate the page, attaching event handlers. CSR sends minimal HTML and JavaScript; the browser runs the JavaScript to build the DOM dynamically. Prerendering runs the build process once, saving the HTML output as static files served directly by the server or CDN.

Why designed this way?

These options exist to balance speed, interactivity, and server load. SSR improves initial load and SEO but requires server computation. CSR allows rich client interactivity but delays content display. Prerendering offers fastest load for static content but lacks dynamic data. This design lets developers pick the best tool for their needs.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Server      │──────▶│  HTML Output  │──────▶│   Browser     │
│  (SSR/Build)  │       │  (SSR or      │       │  Hydrates or │
│               │       │  Prerender)   │       │  Builds DOM  │
└───────────────┘       └───────────────┘       └───────────────┘

Browser flow:
┌───────────────┐       ┌───────────────┐
│  Minimal HTML │──────▶│  Runs JS to   │
│  (CSR)        │       │  Build DOM    │
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does disabling SSR mean the page is not rendered at all? Commit yes or no.

Common Belief: Disabling SSR means the page won't render anything until JavaScript runs.

Reality: Disabling SSR means the server sends minimal HTML, but the browser still renders the page after running JavaScript.

Why it matters: Thinking no rendering happens can cause confusion about blank pages and delays, leading to wrong debugging steps.

Quick: Can prerendered pages show live user data like logged-in info? Commit yes or no.

Common Belief: Prerendered pages can show dynamic user-specific data because they are built ahead of time.

Reality: Prerendered pages are static and cannot include live user data; such data must be loaded client-side after page load.

Why it matters: Expecting prerendered pages to show live data can cause security issues or broken user experiences.

Quick: Is CSR always slower than SSR for initial page load? Commit yes or no.

Common Belief: CSR is always slower than SSR because it builds pages in the browser.

Reality: CSR can be slower for initial load because the browser must download and run JavaScript first, but can be faster for some interactions after load.

Why it matters: Misunderstanding this can lead to wrong performance optimizations and poor user experience.

Quick: Does hydration rebuild the entire page DOM from scratch? Commit yes or no.

Common Belief: Hydration rebuilds the whole page DOM in the browser after SSR or prerender.

Reality: Hydration attaches event listeners and makes the existing HTML interactive without rebuilding the DOM from scratch.

Why it matters: Thinking hydration rebuilds the DOM can cause unnecessary performance worries or incorrect debugging.

Expert Zone

1

SSR can be combined with caching strategies to reduce server load while keeping fast initial loads.

2

Prerendering works best with static content but can be enhanced with client-side hydration for dynamic parts.

3

Disabling SSR ('ssr: false') in SvelteKit disables server rendering but still sends a minimal HTML shell for CSR.

When NOT to use

Avoid prerendering for pages needing real-time or user-specific data; use SSR or CSR instead. Avoid CSR for SEO-critical pages; use SSR or prerender. Avoid SSR for very high-traffic pages without caching, as server load can become a bottleneck.

Production Patterns

Many sites use SSR for main pages to improve SEO and load speed, CSR for user dashboards with heavy interactivity, and prerender for marketing or blog pages that rarely change. Hybrid approaches mix these per route for best results.

Connections

Progressive Web Apps (PWA)

Builds-on

Understanding page rendering options helps optimize PWAs for offline use and fast loading by choosing when to prerender or hydrate content.

Content Delivery Networks (CDN)

Supports

Prerendered pages are often served via CDNs to deliver static content quickly worldwide, showing how rendering choices affect infrastructure.

Cooking and Meal Preparation

Opposite approach

Comparing SSR, CSR, and prerender to cooking methods reveals how timing and location of work affect final product delivery and freshness.

Common Pitfalls

#1 Serving dynamic user data in prerendered pages expecting it to be fresh.

Wrong approach:

export const prerender = true;
// Page shows user name directly from prerendered HTML

Correct approach:

export const prerender = true;
// Load user data client-side after page loads for freshness

Root cause:

Misunderstanding that prerendered pages are static and built once at build time.

#2 Disabling SSR but expecting SEO benefits from server-rendered HTML.

Wrong approach:

export const ssr = false;
// Expect search engines to see full content immediately

Correct approach:

export const ssr = true;
// Enable SSR for SEO-critical pages

Root cause:

Confusing SSR disabling with improved client-side interactivity without considering SEO impact.

#3 Not hydrating SSR pages, causing interactive parts to fail.

Wrong approach:

// Server sends HTML but JavaScript bundle is missing or not loaded

Correct approach:

// Ensure JavaScript bundle loads to hydrate and activate interactivity

Root cause:

Ignoring the need for hydration after SSR to make pages interactive.

Key Takeaways

Page options in Svelte control where and when pages are built: on the server, in the browser, or ahead of time.

SSR sends fully built HTML from the server for fast initial load and SEO benefits, then hydrates for interactivity.

CSR builds pages entirely in the browser, enabling rich interactivity but slower initial display and SEO challenges.

Prerendering builds static HTML files at build time, offering fastest load for static content but no live data.

Choosing the right page option depends on your app’s needs for speed, interactivity, SEO, and server resources.