Zum Inhalt springen
Alle Technologien

SvelteKit das Full-Stack-Framework für Svelte

SvelteKit ist zu Svelte, was Next.js zu React und Nuxt zu Vue ist, nur deutlich schlanker. Es bringt File-basiertes Routing, Server-Side Rendering, Static Site Generation, Form-Actions und Server-Endpoints out of the box. Wir nutzen SvelteKit für Marketing-Websites, statische Sites, performance-getriebene Web-Apps und überall dort, wo wir maximale Auslieferungs-Geschwindigkeit ohne Framework-Overhead wollen. Die fertige SvelteKit-Anwendung liefern wir mit sauberem SEO-Setup und Dokumentation, zur Auslieferung unter Ihrem Namen.

Frontend Systemebene
Die Rolle von SvelteKit im Projekt, schematisch dargestellt.

01 / Einsatz

Wofür sich SvelteKit eignet

  • Marketing-Sites mit Top-Performance (Core Web Vitals als SEO-Hebel)
  • Statische Content-Sites mit `adapter-static` (CDN-/Edge-tauglich)
  • Server-rendered Web-Apps mit Form-Actions statt eigener API-Schicht
  • Progressive Web Apps mit Service-Worker-Integration
  • Multi-Adapter-Deployments (Vercel, Cloudflare Workers, Node-Server, statisch)

02 / Einblick

SvelteKit in der Praxis

Ein Inhalt. Drei Umsetzungen.

Einen Artikel laden und darstellen: dieselbe Aufgabe in Next.js, Nuxt und SvelteKit. Vergleichen Sie direkt im Code, wie Datenabruf, Fehlerbehandlung und Seitenausgabe aufgebaut sind.

Umsetzung vergleichenGleiche Aufgabe, andere Werkzeuge
So funktioniert es

Eine serverseitige load-Funktion lädt den Inhalt. Die benachbarte Svelte-Seite erhält die Daten über ihre PageData und übernimmt die Darstellung.

Wann wir es wählen

Passt zu Svelte-Projekten, die Datenladen, Formularaktionen und Seitenansichten mit den Routenkonventionen von SvelteKit verbinden möchten.

Was wir dabei abwägen

Die Trennung zwischen serverseitigem und universellem Laden sowie der Deployment-Adapter müssen zu den Anforderungen passen.

Code in SvelteKit
src/routes/beispiel/+page.server.ts
import { error } from '@sveltejs/kit'
import type { PageServerLoad } from './$types'

type Article = { title: string; summary: string }

export const load: PageServerLoad = async ({ fetch }) => {
  const response = await fetch('https://cms.example.com/api/article', {
    cache: 'no-store',
  })
  if (response.status === 404) error(404, 'Inhalt nicht gefunden.')
  if (!response.ok) error(502, 'Der Inhalt konnte nicht geladen werden.')
  const article: Article = await response.json()
  return { article }
}
src/routes/beispiel/+page.svelte
<script lang="ts">
import type { PageData } from './$types'
let { data }: { data: PageData } = $props()
</script>

<article>
  <h1>{data.article.title}</h1>
  <p>{data.article.summary}</p>
</article>
Rahmen des Beispiels

Die Beispiele erwarten eine öffentliche CMS-Schnittstelle mit JSON-Feldern title und summary oder HTTP 404. cms.example.com ist eine Platzhalteradresse, die Sie beim Übernehmen durch Ihren Endpunkt ersetzen. Gezeigt wird ein neuer serverseitiger Seitenaufruf ohne vorgeschalteten CMS-Cache oder Prerendering.

Die Entscheidung im ProjektNext.js, Nuxt und SvelteKit im Projektvergleich

03 / Vorgehen

So arbeiten wir mit SvelteKit

  1. SvelteKit-Setup mit Vite, TypeScript und passendem Adapter

  2. Routing- und Layout-Struktur (`+page.svelte`, `+layout.svelte`, route-groups)

  3. Pro Route entscheiden: SSR, SSG, ISR oder Client-only

  4. Load-Funktionen (`+page.server.ts`) und Form-Actions für Daten-Flows

  5. API-Endpoints (`+server.ts`) für externe Konsumenten

  6. Deployment auf Vercel, Coolify oder als statisches Bundle

Das liefern wir bei SvelteKit

  • SvelteKit-Anwendung mit klar dokumentierter Routing-Struktur
  • Adapter-Setup passend zum Hosting-Ziel (statisch, Node, Vercel, Cloudflare)
  • Optimierte Bundle-Größe (typisch deutlich kleiner als Next.js/Nuxt)
  • SEO-Setup: Meta-Tags, Sitemap, OG-Images, structured data
  • Übergabe inkl. README für Setup, Build und Deployment

Häufige Fragen zu SvelteKit

SvelteKit vs. Next.js oder Nuxt: Wann passt was?
SvelteKit ist die schlankste der drei Optionen: kleinste Bundles, einfachstes Mental Model (Form-Actions und Load-Funktionen statt Server-Components-Komplexität). Next.js gewinnt, wenn das React-Ökosystem oder Server Components zwingend sind. Nuxt liegt dazwischen, gute DX für Vue-Teams. Wir wählen pro Projekt.
SSR, SSG oder reine SPA: Was empfehlen Sie?
SSG (statisch) für klassische Content- und Marketing-Sites: schnellstes Auslieferungsmodell, einfaches Hosting auf CDN. SSR für dynamische, personalisierte oder auth-geschützte Bereiche. Reine SPAs sind selten die richtige Wahl. Meist gibt es einen guten Grund für SSR oder SSG.
Welche Adapter nutzen Sie typischerweise?
Wir nutzen den Adapter passend zum Hosting-Ziel: adapter-static für reine SSG-Sites, adapter-node für unseren Coolify-Server, adapter-vercel für Vercel-Deployments, adapter-cloudflare für Edge-Workloads. Die Wahl des Adapters ist Teil der Deployment-Strategie, nicht eine spätere Entscheidung.
Wie reif ist das SvelteKit-Ökosystem?
Für produktive Projekte ausreichend reif. Solide Komponenten-Bibliotheken (shadcn-svelte, Skeleton, Flowbite), Auth-Lösungen (Lucia, Auth.js), gute Form-Validation (sveltekit-superforms), klares Testing (Playwright, Vitest). Bei sehr spezialisierten UI-Anforderungen prüfen wir das vorab konkret.
Kann ich SvelteKit auf meinem eigenen Server hosten?
Ja, mit adapter-node baut SvelteKit eine eigenständige Node.js-Anwendung, die wir z. B. via Docker auf unserem Coolify-Server (Hetzner) oder bei beliebigen Node-Hostern betreiben. Bei reinen SSG-Sites reicht ein statisches CDN-Hosting.

SvelteKit für Ihr Projekt?

Beschreiben Sie uns Ihre Anforderungen. Wir besprechen, wie die Technologie in Ihr Projekt und Ihre vorhandene Infrastruktur passt.

Projekt besprechen