Render-Modi pro Route konfigurieren

Die drei Schalter im Überblick

In jeder +page.ts, +page.server.ts, +layout.ts oder +layout.server.ts kannst du diese drei Werte exportieren:

Das Praktische: Diese Schalter vererben sich entlang der Layout-Hierarchie. Setzt du prerender = true in der Root-Layout, wird die ganze App prerendert — solange einzelne Routen das nicht überschreiben.

SSR ein- und ausschalten

ssr = true ist der Default — der Server liefert fertiges HTML aus. ssr = false schaltet das ab — der Server schickt nur die HTML-Hülle, der Browser rendert alles selbst.

export const ssr = false;

Mit dieser einen Zeile schaltest du das gesamte /dashboard/...-Subtree auf reines Client-Rendering. Wann ist das sinnvoll?

• Eingeloggter Bereich, der ohnehin nicht öffentlich indexiert wird.
• Komponenten, die window/document direkt benutzen und nicht SSR-tauglich sind (Karten-Libraries, manche Chart-Tools, Drag-and-Drop-Hilfen).
• Inhalte, die hochgradig clientseitig dynamisch sind und kaum vom ersten Render profitieren.

Was du dabei verlierst: Suchmaschinen-Lesbarkeit, schneller First Paint mit Inhalt, Funktionieren bei deaktiviertem JavaScript. Auf dem Dashboard meistens egal.

CSR ein- und ausschalten

csr = true ist der Default — der Browser lädt JavaScript, hydrated das HTML und macht die Seite interaktiv. csr = false schaltet alle Client-JavaScript ab.

export const csr = false;

Was wird dadurch erreicht?

• Der Server rendert ganz normal (sofern ssr = true ist).
• Der Browser bekommt das HTML, aber kein JavaScript-Bundle.
• Es gibt keine Hydration, keine Interaktivität, keine Client-Navigation.

Das ist eine seltene Konfiguration. Sinnvoll bei:

• Druck-Versionen oder reinen Inhalts-Seiten (Datenschutz, AGB), wo Interaktivität nichts beiträgt.
• Performance-Optimierung für sehr schnelle Marketing-Seiten — kein JS, kein CPU-Aufwand im Browser.
• Email-Templates, die du als HTML servierst.

Beachte: Auch Form Actions ohne use:enhance funktionieren ohne Client-JS — du verlierst nicht das Form-Funktionieren, nur Progressive Enhancement.

Prerender ein- und ausschalten

prerender = true ist der spannendste Schalter. Er sagt SvelteKit: „Erzeuge diese Seite beim Build als statische HTML-Datei.” Beim Hosten wird die Datei einfach so ausgeliefert — kein Server-Code zur Laufzeit.

export const prerender = true;

Das im Root-Layout wirft den Befehl an alle Routen weiter — die ganze App wird als statische Site erzeugt. Du brauchst dann auch keinen Node-Server beim Hosten, ein simples CDN reicht.

Drei mögliche Werte:

• true — Die Seite muss prerendert werden. SvelteKit versucht es beim Build und wirft einen Fehler, falls etwas schiefgeht (z. B. dynamischer Content).
• 'auto' — Die Seite kann prerendert werden. Wenn alle Daten zur Build-Zeit verfügbar sind, wird sie statisch. Sonst rendert SvelteKit sie zur Laufzeit per SSR.
• false — Die Seite wird zur Laufzeit gerendert (Default).

'auto' ist praktisch in Mischformen: Ein Marketing-Layout prerendert sich automatisch, eine Sub-Route mit dynamischem Inhalt nicht — alles aus einer Konfiguration.

Mischen erlaubt — und üblich

Die wirkliche Stärke der drei Schalter zeigt sich, wenn man sie pro Bereich unterschiedlich setzt. Eine typische Aufteilung in einer realen App:

src/routes/
├── (marketing)/
│   ├── +layout.ts                  prerender = true (Marketing ist statisch)
│   ├── +page.svelte                 → /
│   ├── about/+page.svelte           → /about
│   └── pricing/+page.svelte         → /pricing
├── blog/
│   ├── +layout.ts                  prerender = 'auto'
│   └── [slug]/+page.svelte         → /blog/<slug>
└── (app)/
    ├── +layout.ts                  ssr = false (eingeloggter Bereich, CSR)
    └── dashboard/+page.svelte       → /dashboard

Ergebnis dieser Mischung:

• Marketing-Seiten sind beim Build fertig — schnellstes Hosting, perfekt für CDN.
• Blog-Artikel werden prerendert, wenn der Artikel zum Build-Zeitpunkt existiert. Neue Artikel werden zur Laufzeit gerendert.
• Dashboard läuft komplett im Browser — keine SSR-Last für authenticated Routes.

Alles aus einer Codebase, ein Build, ein Deploy.

Zwei zusätzliche Page-Optionen

Neben den drei Schaltern gibt es noch zwei Werte, die du in derselben Datei setzen kannst:

export const trailingSlash = 'always'; // oder 'never' oder 'ignore'
export const config = {
    isr: { expiration: 60 },
};

trailingSlash entscheidet, wie URLs mit oder ohne Schlussstrich behandelt werden. 'always' zwingt /about/, 'never' zwingt /about. Wichtig für SEO-Konsistenz.

config ist ein freies Feld, in dem Adapter-spezifische Optionen landen. Bei Vercel etwa kannst du hier Incremental Static Regeneration (ISR) konfigurieren — eine Seite, die nach einer gewissen Zeit automatisch neu gerendert wird.

Die Schalter zusammengefasst

Die meisten Apps brauchen 90 % der Zeit den Default. Die Optionen sind Werkzeuge für gezielte Anpassungen.

FAQ — typische Fragen rund um die Render-Modi

Was ist der Default in SvelteKit? ssr=true, csr=true, prerender=false. Also: Server rendert, Browser hydrated, kein Build-Time-HTML. Das ist der häufigste Modus und der meisten Anwendungen genug.

Brauche ich überhaupt einen Server, wenn ich prerender=true setze? Wenn alle Routen prerendert werden, nein. Du kannst dann den adapter-static einsetzen und die fertige App auf jedem CDN hosten — Cloudflare Pages, Netlify, GitHub Pages, ein einfacher Web-Server. Sobald aber eine Route nicht prerenderbar ist (z. B. weil sie eingeloggte Daten zeigt), brauchst du einen Adapter mit Server-Anteil.

Funktionieren +server.ts-Endpunkte beim Prerendering? Ja — wenn auch sie als prerenderbar markiert sind. Du kannst eine Sitemap als routes/sitemap.xml/+server.ts mit prerender=true als statische Datei erzeugen. Live-API-Endpunkte (POST, PATCH) hingegen kannst du nicht prerendern — sie laufen zur Laufzeit auf dem Server.

Was passiert mit Form Actions im Prerender? Form Actions laufen zur Laufzeit auf dem Server. Wenn deine Seite prerendered ist und ein Form-Submit hat, brauchst du trotzdem einen Server-Adapter — die Page selbst ist statisch, das Submit aber dynamisch.

Wann nutze ich prerender='auto' statt true? Wenn manche URLs der Route prerenderbar sind und andere nicht. Klassisch: Eine [slug]-Route, deren Slugs teilweise zur Build-Zeit bekannt sind, teilweise erst zur Laufzeit hinzukommen. Mit 'auto' macht SvelteKit das Beste daraus.

Kann ich ssr=false und prerender=true kombinieren? Theoretisch ja, aber meistens unsinnig. prerender braucht Server-Rendering, um die Datei zu erzeugen. ssr=false schaltet das ab. Die Kombination wirft im Build typischerweise einen Fehler.

Was ist der Unterschied zwischen ssr=false und einer reinen SPA mit Vite? Funktional ähnlich, technisch nicht. Bei ssr=false in SvelteKit hast du immer noch das ganze Routing, die Layout-Hierarchie, die load-Funktionen — alles SvelteKit-Features. Du verzichtest nur auf Server-Rendering. Eine reine Vite-SPA kennt keine dieser Konzepte.

Wirken die Schalter auch in +page.server.ts? Ja, du kannst sie sowohl in .ts als auch in .server.ts exportieren. In welcher Datei sie stehen, ist egal — SvelteKit liest sie aus beiden.

Verlangsamt SSR meine Seite? Nein, normalerweise das Gegenteil. Bei SSR sieht der Nutzer fertige Inhalte, sobald die ersten Bytes ankommen — auch ohne JavaScript. Bei reiner CSR sieht er erst nach dem JS-Download und der Hydration etwas. SSR fühlt sich für den Nutzer schneller an, auch wenn der Server etwas Arbeit hat.

Was passiert, wenn ich die Schalter im Layout und in der Page widersprüchlich setze? Page-Optionen überschreiben Layout-Optionen. Du kannst also im Layout prerender=true setzen und in einer einzelnen Page prerender=false — die spezifischere gewinnt.

Weiterführende Ressourcen

Externe Quellen

• Page options – svelte.dev
• Configuration – svelte.dev

Verwandte Artikel

• Was ist SvelteKit?
• Prerendering im Detail
• Streaming-Responses
• Adapter