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.
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.
Eine Server Component lädt den Inhalt und gibt die fertige Seite zurück. notFound übernimmt fehlende Inhalte; weitere Fehler gehen an die Fehlergrenze der Route.
Passt zu React-Projekten, bei denen serverseitige Inhalte und interaktive Komponenten gemeinsam geplant werden.
Server- und Client-Grenzen sowie Cache-Regeln müssen bewusst festgelegt werden. no-store macht das Beispiel nachvollziehbar, ist aber keine allgemeine Cache-Empfehlung.
Code in Next.js
import { notFound } from 'next/navigation'
type Article = { title: string; summary: string }
export default async function Page() {
const response = await fetch('https://cms.example.com/api/article', {
cache: 'no-store',
})
if (response.status === 404) notFound()
if (!response.ok) throw new Error('Der Inhalt konnte nicht geladen werden.')
const article: Article = await response.json()
return <article>
<h1>{article.title}</h1>
<p>{article.summary}</p>
</article>
}useFetch lädt den Inhalt beim serverseitigen Rendern und übergibt ihn im Seiten-Payload an Vue. Das Template nutzt die geladenen Daten.
Passt, wenn Vue bereits gesetzt ist und Seiten, Datenabrufe sowie Server-Routen in einem gemeinsamen Projekt organisiert werden sollen.
Schlüssel und Lebensdauer gemeinsam genutzter Daten sowie Route Rules müssen abgestimmt sein. Ein voller Seitenaufruf ist nicht dasselbe wie jeder clientseitige Routenwechsel.
Code in Nuxt
<script setup lang="ts">
type Article = { title: string; summary: string }
const { data: article, error } = await useFetch<Article>(
'https://cms.example.com/api/article',
{ cache: 'no-store' },
)
if (error.value) {
throw createError({
statusCode: error.value.statusCode === 404 ? 404 : 502,
statusMessage: 'Der Inhalt konnte nicht geladen werden.',
})
}
if (!article.value) throw createError({ statusCode: 404 })
</script>
<template>
<article v-if="article">
<h1>{{ article.title }}</h1>
<p>{{ article.summary }}</p>
</article>
</template>Eine serverseitige load-Funktion lädt den Inhalt. Die benachbarte Svelte-Seite erhält die Daten über ihre PageData und übernimmt die Darstellung.
Passt zu Svelte-Projekten, die Datenladen, Formularaktionen und Seitenansichten mit den Routenkonventionen von SvelteKit verbinden möchten.
Die Trennung zwischen serverseitigem und universellem Laden sowie der Deployment-Adapter müssen zu den Anforderungen passen.
Code in SvelteKit
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 }
}<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.
03 / Vorgehen
So arbeiten wir mit SvelteKit
-
SvelteKit-Setup mit Vite, TypeScript und passendem Adapter
-
Routing- und Layout-Struktur (`+page.svelte`, `+layout.svelte`, route-groups)
-
Pro Route entscheiden: SSR, SSG, ISR oder Client-only
-
Load-Funktionen (`+page.server.ts`) und Form-Actions für Daten-Flows
-
API-Endpoints (`+server.ts`) für externe Konsumenten
-
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?
SSR, SSG oder reine SPA: Was empfehlen Sie?
Welche Adapter nutzen Sie typischerweise?
Wie reif ist das SvelteKit-Ökosystem?
Kann ich SvelteKit auf meinem eigenen Server hosten?
Artikel zu SvelteKit
- Technologie
2 min LesezeitWordPress-Relaunch: Bestehendes verbessern oder Headless umbauen?
Wie Agenturen vor einer Migration Redaktion, Funktionen, Suchadressen und Betriebsaufwand prüfen können.
- Technologie
3 min LesezeitUnser Tech-Stack: Womit wir Projekte umsetzen
Frontend, Backend, CMS, Hybrid-Apps und Infrastruktur. Welche Aufgaben unser Angebot umfasst und wie wir die technische Auswahl treffen.
- Technologie
3 min LesezeitKI in Webprojekten: Aufgabe, Daten und Grenzen zuerst klären
Wie sich KI-Funktionen nachvollziehbar planen, begrenzen und prüfen lassen, bevor sie Teil eines Kundenprojekts werden.
- Technologie
2 min LesezeitCMS auswählen: WordPress, Sanity, Strapi oder Contentful?
Redaktion, Datenmodell, Schnittstellen und Betriebsverantwortung als Grundlage für die CMS-Auswahl.
Passende Leistungen
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