Zum Inhalt springen
CASOON

Svelte kompakt erklärt – Teil 5: SvelteKit und Routing – Struktur, Layouts und SEO für moderne Anwendungen

Entwicklung

Datei-basiertes Routing, Layouts, SSR und SEO mit SvelteKit – der moderne Standard.

2 Minuten
Svelte kompakt erklärt – Teil 5: SvelteKit und Routing – Struktur, Layouts und SEO für moderne Anwendungen
#Svelte #SvelteKit #Routing #Layouts
SerieSvelte kompakt erklärt
Teil 4 von 8

Mit SvelteKit stellt das Svelte-Ökosystem ein umfassendes Meta-Framework bereit, das moderne Webstandards konsequent umsetzt: Datei-basiertes Routing, modulare Layouts, serverseitiges Rendering (SSR), Static-Site-Generation (SSG) und exzellente SEO-Unterstützung – alles direkt integriert und ohne zusätzliche Konfiguration.

📁 Datei-basiertes Routing – einfach und mächtig

SvelteKit nutzt ein dateibasiertes Routingsystem, das stark an Next.js erinnert. Jede Datei in src/routes wird automatisch zur Route.

Beispiele:

src/routes/ ├── +page.svelte → / ├── about/+page.svelte → /about ├── blog/[slug]/+page.svelte → /blog/:slug
  • +page.svelte: Definiert die Seite (komponentenbasiert)
  • +page.ts/js: Optionaler Server- oder Client-Loader für Daten
  • [param]: Dynamische Route (z. B. für Blogposts oder Produktseiten)
  • [[optional]]: Optionaler Parameter

🧱 Layouts – wiederverwendbare Seitenstruktur

SvelteKit unterstützt nested Layouts – d. h. ein übergeordnetes Layout kann mehreren Unterseiten dienen.

Beispielstruktur:

src/routes/ ├── +layout.svelte → Basislayout (z. B. Header/Footer) ├── about/+page.svelte ├── dashboard/ │ ├── +layout.svelte → eigenes Layout für Dashboard │ └── stats/+page.svelte

In +layout.svelte:

<Header />
<main><slot /></main>
<Footer />

Layouts können eigene Scripts, Styles oder auch Stores enthalten – und so Logik und Struktur bündeln.

SEO mit SvelteKit

SvelteKit bietet alles, was moderne SEO braucht – und das direkt aus dem Framework heraus.

Vorteile:

  • Server-side Rendering: Inhalte sind bei Seitenaufruf direkt verfügbar
  • Page-Preloading: Schnelles Navigieren ohne harte Reloads
  • Meta-Tags dynamisch setzen
  • Zugriff auf Pfad, Params, Daten im <svelte:head>

Beispiel:

<svelte:head>
  <title>Mein Blog – {data.title}</title>
  <meta name="description" content={data.summary} />
</svelte:head>

Load-Funktion – Daten vorab laden

Mit load() lassen sich Daten für Seiten und Layouts vorab laden – auf Client oder Server.

Beispiel in +page.ts:

export async function load({ params, fetch }) {
  const res = await fetch(`/api/posts/${params.slug}`);
  const post = await res.json();
  return { post };
}

In der Komponente steht data.post dann direkt zur Verfügung.

Vorteile:

  • Trennung von Datenlogik und UI
  • SSR, SSG oder clientseitiges Laden möglich
  • Voller TypeScript-Support

Internationalisierung (i18n) & dynamisches Routing

SvelteKit bietet viele Erweiterungsmöglichkeiten für internationale Projekte:

  • Middleware zum Umschalten von Sprachen
  • Dynamische Routen pro Sprache
  • Integration mit Libraries wie svelte-i18n oder tolgee

Best Practices für Struktur & Routing

  • Flache Routenstruktur mit sinnvollen Unterordnern
  • Gemeinsame Komponenten und Stores in /src/lib/
  • Layouts nutzen für konsistente Navigation & Struktur
  • Separate +layout.ts Dateien zur Vorbereitung von Layout-Daten (z. B. Userstatus, Menüs)
  • SEO-optimierte Titel & Meta-Tags pro Seite

Ein letzter Gedanke (Teil 5)

SvelteKit nimmt viele Hürden moderner Webentwicklung ab – mit durchdachtem Routing, flexiblen Layouts, schneller Datenverarbeitung und starker SEO-Basis. Die Kombination aus minimalistischem Code und maximaler Kontrolle macht es zu einer leistungsfähigen Plattform für moderne Single-Page- und Multi-Page-Anwendungen.

SvelteKit in der Production – was wirklich zählt

Aus echten Production-Erfahrungen lassen sich konkrete Stärken und Schwächen benennen:

Stark in:

  • Build-Performance: Production-Builds einer mittelgroßen Site (50 Seiten) liegen typisch bei 15–40 Sekunden. Next.js braucht 1–3 Minuten, Gatsby 3–10 Minuten.
  • Bundle-Größen: Eine typische SvelteKit-Site liegt bei 30–80 KB JavaScript (gzipped), oft die Hälfte von vergleichbaren React-Setups.
  • Mental Model: File-based Routing, Layouts, Hooks — die Konzepte sind in 1–2 Tagen gelernt. Bei Next.js App Router brauchen Teams oft Wochen, bis Server- und Client-Komponenten-Logik sicher verstanden ist.

Schwächer in:

  • Library-Ökosystem: UI-Bibliotheken (Skeleton, Flowbite-Svelte) decken Basics ab, aber für spezifische Component-Libraries (Charts, Tabellen, komplexe Inputs) ist React breit aufgestellter.
  • Recruiting: SvelteKit-Entwickler sind in Deutschland 5–8x seltener als React-Entwickler. Bei Wachstum oder Personalwechsel real ein Problem.
  • Server Components / Streaming: Sveltes Server Routes sind solide, aber React Server Components sind in Next.js etablierter — bei sehr großen Apps spielt das eine Rolle.

Realistische SEO-Konfiguration

Wer SvelteKit für SEO-relevante Sites nutzt, sollte konkret achten auf:

  • Adapter-Wahl: adapter-static für reine Static-Sites, adapter-cloudflare oder adapter-node für SSR-Use-Cases. Falsche Adapter-Wahl kostet entweder SEO (bei Static-Only) oder Performance (bei unnötigem SSR).
  • Trailing Slashes konsistent: SvelteKit erlaubt verschiedene Modi (always, never, ignore). Inkonsistenz führt zu Duplicate-Content-Issues.
  • Meta-Tags pro Route: Mit <svelte:head> pro Seite, nicht im Root-Layout. Sonst werden Meta-Tags nicht pro Route gerendert.
  • Sitemap-Generation: Manuell oder über +server.ts-Route mit XML-Generation. Nicht out-of-the-box, aber in 30–60 Minuten implementierbar.

Wann SvelteKit nicht passt

  • Bei bestehender React-Codebase: Migration kostet Zeit, ohne sicheren ROI. Lieber innerhalb von React modernisieren.
  • Bei sehr großen Frontend-Teams (20+ Entwickler): Recruiting-Risiko wird real.
  • Bei strikten Library-Anforderungen: Wenn Material-UI oder Ant Design Pflicht ist, bleibt SvelteKit außen vor.
  • Bei sehr komplexen Server-Components-Patterns: Hier ist Next.js App Router weiter entwickelt.