SvelteKit

Was ist SvelteKit?

SvelteKit ist ein Framework zum Bauen von Webanwendungen mit Svelte. Svelte kümmert sich um die UI-Komponenten, SvelteKit ergänzt, was eine vollständige App braucht: dateibasiertes Routing, Daten laden, Server-Endpunkte und Formularverarbeitung. Seiten lassen sich auf dem Server, im Browser oder beim Build rendern, pro Route frei wählbar. Für Svelte spielt es die Rolle, die Next.js für React und Nuxt für Vue hat.

Die Entwicklung läuft auf Vite, Codeänderungen erscheinen per Hot Module Replacement sofort im Browser.

So funktionieren Routing und Datenladen

Routen ergeben sich aus der Ordnerstruktur unter src/routes. Dateien, die mit + beginnen, bestimmen das Verhalten einer Route:

• +page.svelte ist die Seite selbst. Sie wird bei der ersten Anfrage auf dem Server gerendert, bei späterer Navigation im Browser.
• +page.js exportiert eine load-Funktion, die beim ersten Rendern auf dem Server und bei Client-Navigation im Browser läuft.
• +page.server.js enthält ein load, das nur auf dem Server läuft und deshalb auf Datenbanken oder private Umgebungsvariablen zugreifen kann. Hier können auch Form Actions exportiert werden.
• +layout.svelte umrahmt Unterseiten mit gemeinsamer Oberfläche, etwa einer Navigation.
• +server.js erzeugt einen API-Endpunkt, indem es Handler mit den Namen von HTTP-Methoden exportiert, etwa GET und POST.

Ein Ordner in eckigen Klammern wie src/routes/blog/[slug] passt auf ein dynamisches Segment, in load verfügbar als params.slug.

Rendering-Optionen

Drei Seitenoptionen steuern, wie eine Route gerendert wird. ssr ist standardmäßig aktiv, Seiten werden also zuerst auf dem Server gerendert (Server-Side Rendering). Auch csr ist standardmäßig aktiv, das Server-HTML wird im Browser interaktiv, ein Schritt namens Hydration. prerender baut eine Route beim Build zu statischem HTML, das ist Static Site Generation. Steht ssr im Root-Layout auf false, wird die App zur Single-Page-App, und mit csr auf false wird kein JavaScript an den Client geliefert.

Sie können das in einer App mischen: Marketingseiten vorab rendern, ein Dashboard auf dem Server rendern und ein Tool nur im Client laufen lassen.

Adapter: überall deployen

Ein Adapter wandelt die gebaute App in etwas um, das ein Host ausführen kann. Die SvelteKit-Dokumentation nennt offizielle Adapter für Node-Server (adapter-node), rein statische Ausgabe (adapter-static), Vercel, Netlify, Cloudflare Workers und Pages sowie Bun. Wählen Sie den Adapter passend zum Ziel, und denken Sie daran: Ein rein statischer Adapter funktioniert nur, wenn sich jede Route vorab rendern lässt.

Form Actions

Mit Form Actions verarbeitet eine +page.server.js-Datei <form>-Absendungen auf dem Server. Sie nutzen POST und funktionieren ohne Client-JavaScript. Mit use:enhance wird das Formular per fetch ohne Seitenneuladen abgeschickt, mit demselben Servercode. Für JSON-APIs oder andere Nicht-Formular-Anfragen nehmen Sie stattdessen einen +server.js-Endpunkt.

Häufige Fehler

• Geheimnisse in ein universelles load (+page.js) legen. Es läuft auch im Browser, Datenbankzugriff und private Variablen gehören deshalb in +page.server.js.
• Eine Seite mit Form Actions vorab rendern. Laut Dokumentation lassen sich solche Seiten nicht prerendern.
• Den statischen Adapter für eine App mit dynamischen Routen wählen, die sich nicht prerendern lassen.
• trailingSlash auf 'ignore' lassen. /x und /x/ sind dann getrennte URLs, was laut Dokumentation SEO schadet. Standard ist 'never'.

SvelteKit, Lasttests und Monitoring

Server-gerenderte Routen leisten bei jeder Anfrage echte Arbeit: load-Funktionen, Datenbankabfragen und HTML-Rendering. Dort lohnt der Blick, wenn der Traffic wächst. Führen Sie einen Lasttest gegen die wichtigen Routen durch, etwa Startseite, eine datenlastige Seite und Ihre +server.js-Endpunkte, und beobachten Sie Antwortzeit und Fehler bei steigender Zahl virtueller Nutzer. Der (englische) Beitrag How to load test single-page applications behandelt die browserlastige Seite.

Nach dem Launch prüft API-Monitoring Ihre Endpunkte nach Zeitplan, und Page-Speed-Monitoring verfolgt die Core Web Vitals, damit ein langsames Release schnell auffällt.

Häufige Fragen zu SvelteKit

Was ist der Unterschied zwischen Svelte und SvelteKit?

Svelte ist das Komponenten-Framework für die Oberfläche. SvelteKit ist das Anwendungs-Framework darum herum und ergänzt Routing, Datenladen, Server-Rendering, Endpunkte und Deployment-Adapter.

Nutzt SvelteKit Server-Side Rendering?

Ja, standardmäßig. Seiten werden bei der ersten Anfrage auf dem Server gerendert und im Browser danach interaktiv. Sie können das pro Route oder für die ganze App abschalten.

Kann SvelteKit eine statische Website bauen?

Ja. Rendern Sie die Routen vorab und nutzen Sie den statischen Adapter. Das klappt nur, wenn sich jede Route prerendern lässt. Seiten mit Daten zur Anfragezeit oder Form Actions brauchen einen anderen Adapter.

Wo kann ich eine SvelteKit-App deployen?

Überall, wo es einen offiziellen oder Community-Adapter gibt. Die offiziellen decken Node-Server, statisches Hosting, Vercel, Netlify, Cloudflare und Bun ab.

Wie unterscheidet sich SvelteKit von Next.js und Nuxt?

Die Idee ist dieselbe: ein Full-Stack-Framework mit Routing und Server-Rendering. Der Unterschied ist die UI-Bibliothek darunter, Svelte statt React oder Vue.