Svelte / Advanced: rendering, resources and release evidence / Lesson 13

SSR, hydration and prerender contracts

Choose page rendering options from data authority and initial-output requirements rather than treating browser-only rendering as a universal fix.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish SSR, CSR, prerendering and hydration responsibilities.
Keep initial output deterministic and private data outside public build artifacts.

Rendering options describe different work and audiences

SSR produces server HTML, CSR enables browser behavior, and prerendering can produce route output during a build for suitable request-independent content. These options are related but not synonymous. Disabling SSR is not the same as generating useful static HTML, and disabling CSR changes interaction rather than authorizing the remaining server output. A private session page should not be prerendered as if its user-specific data were public. Review route inheritance and dynamic entry generation under the selected Kit version. A configuration that compiles can still publish the wrong representation if its audience and data timing were not reviewed.

Make a public static-page assumption explicit

The fragment belongs to a synthetic public read-only page with no session-dependent data or form actions. It selects prerendered server HTML without client hydration. It is not a general recipe for private or interactive pages. No Kit compiler or adapter evaluated the exports. A real build must know the intended route entries and must not require an unavailable live endpoint merely to render a page. Verify links and form behavior when CSR is off; progressive navigation and interactive controls do not necessarily behave like the hydrated application.

javascript Illustrative public-only page options

// Public read-only route option fragment
export const prerender=true;
export const ssr=true;
export const csr=false;

These exports are framework configuration, not executed local models. No static page or build artifact was generated.

Match the first browser output to the server snapshot

Hydration attaches browser behavior to server-produced markup under the component contract. Independently generated time, random IDs, locale differences or window-dependent initial branches can make the outputs disagree. Effects do not run during SSR, so moving essential display calculation into an effect can leave the server snapshot incomplete. Use deterministic derived output and an approved initial model, then make any intentional browser-specific adaptation in the correct lifecycle. Invalid HTML or intermediary modifications are separate possible causes. Do not suppress every warning or disable SSR globally before identifying the exact differing node and input.

Choose deterministic formatting explicitly

The local formatter derives a UTC date from an explicit timestamp. Two different timezone spellings for the same instant produce the same date, and invalid input rejects. This is ordinary Date behavior, not a Svelte hydration test. The UTC rule is a synthetic display contract; a real product may intentionally choose the user’s timezone and must supply that choice consistently to both sides. A stable formatting helper does not establish that the supplied timestamp was authorized or current. Keep data eligibility and representation timing separate from the local string calculation.

javascript Complete offline UTC-format contract

function utcDate(text){const date=new Date(text);if(Number.isNaN(date.getTime()))throw new Error("INVALID_TIME");return date.toISOString().slice(0,10);}
console.assert(utcDate("2026-01-01T23:30:00-02:00")==="2026-01-02");
console.assert(utcDate("2026-01-02T01:30:00Z")==="2026-01-02");
let rejected=false;try{utcDate("invalid");}catch{rejected=true;}console.assert(rejected);

Equivalent instants agree under the declared timezone rule. No SSR HTML or hydration tree is produced.

Verify build audience and actual browser lifecycle

Test direct load, hydrated navigation, disabled client code, representative locales and identity changes using the intended page options. Inspect generated public data and assets for private fields. Keep current layout data reactive during reuse and prevent pending old-principal responses from restoring private state. This course runs only utcDate; prerender generation, SSR, hydration, CSR-disabled behavior and adapter output remain unexecuted. Actual verification needs an authorized isolated build/browser setup with safe source fakes and exact versions. A passing formatter or page-option object is not a performance, SEO or privacy certification for the deployed site.

Common errors and fixes

A private session page is prerendered into public output

Why it happens: Request-dependent audience was treated as build-time public data.
How to fix it: Keep private reads request-authorized and choose compatible page options.
Prevent it next time: Inspect generated data and test denied callers.

Essential SSR content is computed only in an effect

Why it happens: Browser-only lifecycle was mistaken for server derivation.
How to fix it: Use deterministic render/derived data and reserve effects for external work.
Prevent it next time: Compare source HTML and initial browser output.

SSR is disabled to hide every hydration warning

Why it happens: A broad mode change replaced diagnosis of the actual mismatch.
How to fix it: Identify the differing node, inputs and markup cause.
Prevent it next time: Verify correct content and interaction, not only warning absence.

Check your understanding

1. Does csr=false make a page safe to publish?

Show worked solution

No. It controls client rendering behavior. The server or build can still expose private data. Review audience, source authorization and generated artifacts independently, then verify the actual nonhydrated interaction contract. A mode flag cannot replace domain policy.

2. Why does a deterministic UTC test not prove hydration correctness?