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.

Practice

1. What does SSR (Server-Side Rendering) do in a Svelte page?

easy

A. It sends fully rendered HTML from the server to the browser.

B. It renders the page only after JavaScript loads in the browser.

C. It builds static pages ahead of time during the build process.

D. It disables JavaScript on the page for faster loading.

Solution

1. Step 1: Understand SSR concept

   SSR means the server prepares the full HTML before sending it to the browser.

2. Step 2: Compare with other options

   CSR waits for JavaScript to render, prerender builds static pages ahead, and disabling JavaScript is unrelated.

3. Final Answer:

   It sends fully rendered HTML from the server to the browser. -> Option A

4. Quick Check:

   SSR = server sends ready HTML [OK]

Hint: SSR means server sends ready HTML, not browser rendering [OK]

Common Mistakes:

• Confusing SSR with CSR
• Thinking prerender is the same as SSR
• Believing SSR disables JavaScript

2. Which of the following is the correct way to disable SSR for a Svelte page?

easy

A. export const csr = true;

B. export const prerender = false;

C. export const ssr = false;

D. export const ssr = true;

Solution

1. Step 1: Recall syntax to disable SSR

   In Svelte, setting export const ssr = false; disables server-side rendering.

2. Step 2: Check other options

   prerender controls static generation, csr is not a valid option, and ssr = true enables SSR.

3. Final Answer:

   export const ssr = false; -> Option C

4. Quick Check:

   Disable SSR with ssr = false [OK]

Hint: Use 'export const ssr = false;' to disable SSR [OK]

Common Mistakes:

• Using 'prerender = false' to disable SSR
• Trying to set 'csr = true' which is invalid
• Confusing enabling and disabling SSR

3. Given this Svelte page code:

export const prerender = true;
export const ssr = false;

What will happen when this page is built and served?

medium

A. The page is statically generated at build time and rendered only on the client.

B. The page is server-rendered on each request and not prerendered.

C. The page is neither prerendered nor server-rendered, causing an error.

D. The page is prerendered and server-rendered on every request.

Solution

1. Step 1: Analyze prerender and ssr flags

   Setting prerender = true means the page is built as a static HTML file ahead of time. Setting ssr = false disables server-side rendering on requests.

2. Step 2: Understand combined effect

   The page is generated once at build time (prerendered) and then served as static HTML. Since SSR is off, no server rendering happens on requests; rendering happens on the client.

3. Final Answer:

   The page is statically generated at build time and rendered only on the client. -> Option A

4. Quick Check:

   prerender true + ssr false = static build + client render [OK]

Hint: prerender true + ssr false means static build + client render [OK]

Common Mistakes:

• Thinking SSR still runs on requests
• Assuming no rendering happens causing error
• Confusing prerender with SSR

4. You want a Svelte page to be fully static and load instantly without server rendering. You write:

export const ssr = false;
export const prerender = false;

What is the problem with this setup?

medium

A. The page will be server-rendered but not prerendered, causing slow loads.

B. The page will not prerender and also disables SSR, so it won't generate HTML before client loads.

C. The page will cause a syntax error because both options cannot be false.

D. The page will prerender but still use SSR, causing duplicate rendering.

Solution

1. Step 1: Understand the effect of both flags false

   Setting ssr = false disables server-side rendering, and prerender = false disables static generation.

2. Step 2: Identify the consequence

   Without SSR or prerender, the page has no prebuilt HTML and relies on client-side rendering only, causing a blank page until JavaScript runs.

3. Final Answer:

   The page will not prerender and also disables SSR, so it won't generate HTML before client loads. -> Option B

4. Quick Check:

   ssr false + prerender false = no prebuilt HTML [OK]

Hint: Both ssr and prerender false means no prebuilt HTML [OK]

Common Mistakes:

• Assuming prerender happens automatically
• Thinking this causes syntax error
• Believing SSR still runs when false

5. You want a Svelte page that:
- Is prerendered as static HTML for fast loading
- Uses SSR only if the user is logged in
- Otherwise, renders on the client

Which setup best achieves this behavior?

hard

A. export const prerender = false;
export const ssr = false;
// Fully client-side rendering only

B. export const prerender = false;
export const ssr = true;
// Server renders always regardless of login

C. export const prerender = true;
export const ssr = false;
// Use client-side code to check login and fetch data

D. export const prerender = true;
export const ssr = true;
// Use server hooks to check login and render accordingly

Solution

1. Step 1: Understand prerender and SSR roles

   Prerender true builds static HTML at build time. SSR true enables server rendering on requests.

2. Step 2: Match requirements

   To prerender for fast loading and also use SSR conditionally (like checking login), you need both prerender and SSR enabled. Server hooks can check login and decide rendering.

3. Step 3: Evaluate other options

   export const prerender = true; export const ssr = false; // Use client-side code to check login and fetch data disables SSR, so no server rendering on login. export const prerender = false; export const ssr = true; // Server renders always regardless of login disables prerender, losing static HTML. export const prerender = false; export const ssr = false; // Fully client-side rendering only disables both, no server or static rendering.

4. Final Answer:

   export const prerender = true; export const ssr = true; // Use server hooks to check login and render accordingly -> Option D

5. Quick Check:

   Prerender + SSR true for static + conditional server render [OK]

Hint: Enable both prerender and SSR for static plus conditional server render [OK]

Common Mistakes:

• Disabling SSR when conditional server render is needed
• Disabling prerender losing static HTML benefits
• Assuming client code can replace server login checks