← Alle Beiträge

Moderne Frontend-Architektur — React, Svelte und die Performance-Patterns, die zählen

Matthias Bruns · · 7 Min. Lesezeit
frontend react svelte architecture performance

Die Framework-Wahl ist nicht die Architektur-Entscheidung

Jedes Quartal geht ein neuer „React vs. Svelte vs. X”-Benchmark viral. Teams verbringen Wochen mit Evaluierung, bauen einen Proof-of-Concept — und liefern dann die gleiche über-fetchende, client-gerenderte SPA, die sie mit jedem Framework gebaut hätten. Die Wahl zwischen React und Svelte ist weit weniger wichtig als die Architektur-Patterns, die darauf aufsetzen.

Die eigentlichen Entscheidungen: Wo findet das Rendering statt? Wie viel JavaScript erreicht den Browser? Wie kommunizieren Komponenten ihren State? Diese Fragen bestimmen, ob die App in 800ms oder 4 Sekunden lädt — nicht ob React 19 oder Svelte 5 zum Einsatz kommt.

Rendering-Strategien: Pro Seite wählen, nicht pro App

Die Ära von „unsere App ist eine SPA” oder „unsere App ist server-gerendert” ist vorbei. Moderne Meta-Frameworks — Next.js, SvelteKit, Astro — erlauben die Wahl der Rendering-Strategie pro Route.

Static Site Generation (SSG) für Inhalte, die sich selten ändern. Blogposts, Dokumentation, Marketing-Seiten. Einmal bauen, vom CDN ausliefern, null Server-Kosten pro Request.

Server-Side Rendering (SSR) für Seiten, die bei jedem Request frische Daten brauchen. Dashboards, Suchergebnisse, personalisierte Inhalte. Der Server rendert HTML, der Client hydratisiert es.

Client-Side Rendering (CSR) für hochinteraktive Bereiche hinter der Authentifizierung. Admin-Panels, Echtzeit-Editoren, Drag-and-Drop-Interfaces. Kein SEO-Bedarf, volle Interaktivität von Anfang an.

Das Pattern, das 2026 gewinnt: Hybrid Rendering. Marketing-Seiten als SSG. Produktseiten als SSR mit Streaming. Die App-Shell als CSR. Eine Codebase, drei Strategien, jede für ihren Einsatzzweck optimiert.

Islands Architecture: Weniger JavaScript ausliefern

Islands Architecture, populär gemacht durch Astro, ist das wirkungsvollste Frontend-Pattern der letzten Jahre. Das Konzept: Den Großteil der Seite als statisches HTML auf dem Server rendern, dann nur die interaktiven „Inseln” — ein Such-Widget, ein Warenkorb, ein Kommentarbereich — im Client hydratisieren.

Das Ergebnis ist dramatisch. Eine typische Content-lastige Seite, die als React-SPA 200KB JavaScript auslieferte, braucht jetzt 15KB. Der Rest ist statisches HTML, das der Browser sofort rendert. Core Web Vitals verbessern sich durchgehend: besserer Largest Contentful Paint (LCP), niedrigerer Interaction to Next Paint (INP), reduzierter Cumulative Layout Shift (CLS).

Astro geht noch weiter und erlaubt das Mischen von Frameworks innerhalb einer Seite. Eine React-Komponente für den interaktiven Preisrechner, eine Svelte-Komponente für den animierten Hero, pures HTML für alles andere. Jede Insel hydratisiert unabhängig, nach eigenem Zeitplan.

Das ist nicht theoretisch. Der Astro Showcase zeigt Produktions-Sites von Unternehmen mit Millionen monatlicher Besucher — mit Lighthouse-Scores konstant über 95.

Signals: Das Reaktivitätsmodell, das alles verändert

Reacts Re-Rendering-Modell — Komponenten-Funktion erneut ausführen, Virtual DOM diffen, echtes DOM patchen — ist seit einem Jahrzehnt das dominante Paradigma. Es funktioniert, hat aber seinen Preis. Jede State-Änderung führt den gesamten Komponenten-Baum erneut aus, wenn nicht manuell mit useMemo, useCallback und React.memo optimiert wird.

Signals verfolgen einen grundlegend anderen Ansatz. Statt Komponenten erneut auszuführen, tracken Signals, welche spezifischen DOM-Knoten von welchen spezifischen State-Teilen abhängen. Bei State-Änderungen werden nur die betroffenen DOM-Knoten aktualisiert. Kein Diffing, kein Virtual DOM, keine manuelle Memoization.

Svelte 5 hat Runes ($state, $derived, $effect) als Signals-Implementierung eingeführt. Der Compiler analysiert den Code zur Build-Zeit und generiert chirurgisch präzise DOM-Updates. Der Entwickler schreibt geradlinigen reaktiven Code; der Compiler erledigt die Optimierungsarbeit.

React bewegt sich in die gleiche Richtung. Der React Compiler (ehemals React Forget) memoized Komponenten und Hooks automatisch — ohne manuelles useMemo/useCallback. Er übernimmt keine Signals direkt, löst aber das gleiche Problem: unnötige Re-Renders reduzieren, ohne Entwickler-Aufwand.

Die praktische Konsequenz: 2026 können sowohl React als auch Svelte exzellente Runtime-Performance liefern. Der Unterschied liegt in der Developer Experience. Sveltes Ansatz ist expliziter — die Reaktivität ist in der Syntax sichtbar. Reacts Ansatz bewahrt das vertraute Function-Component-Modell und optimiert im Hintergrund.

React Server Components: Der Server-First-Shift

React Server Components (RSC) sind Reacts größte architektonische Änderung seit Hooks. Server Components laufen ausschließlich auf dem Server. Sie können direkt auf Datenbanken, Dateisysteme und interne APIs zugreifen. Sie senden gerendertes HTML an den Client — kein JavaScript-Bundle für die Komponente selbst.

Der Paradigmenwechsel im Mental Model:

// Server Component — läuft auf dem Server, liefert null JS an den Client
async function ProductPage({ id }) {
  const product = await db.products.find(id);
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton productId={id} /> {/* Client Component */}
    </div>
  );
}

Die ProductPage-Komponente erreicht nie den Browser. Nur AddToCartButton — markiert mit 'use client' — liefert JavaScript aus. Das Data Fetching passiert auf dem Server, nah an der Datenbank, ohne Wasserfall von API-Calls aus dem Browser.

Next.js App Router baut vollständig auf diesem Modell auf. Jede Komponente ist standardmäßig eine Server Component. Client-seitige Interaktivität wird explizit eingewählt. Diese Umkehrung — Server-first statt Client-first — reduziert Bundle-Größen und eliminiert ganze Kategorien von Ladezuständen.

Wann React, wann Svelte?

Nach Jahren der Beratung zu Frontend-Architektur ist das unser Entscheidungs-Framework:

React wählen, wenn:

  • Das Team React bereits kennt (Umschulungskosten sind real)
  • Das Ökosystem gebraucht wird — Component Libraries, Tooling, Third-Party-Integrationen
  • Eine große, langlebige Anwendung gebaut wird, bei der die Verfügbarkeit von React-Entwicklern zählt
  • Server Components und das Next.js-Ökosystem gewünscht sind

Svelte wählen, wenn:

  • Performance ein primäres Anliegen ist und das kleinstmögliche Bundle gewünscht wird
  • Das Team klein ist und mit weniger Boilerplate schnell vorankommt
  • Content-lastige Sites gebaut werden, bei denen Compile-Time-Optimierung glänzt
  • Ein opinionated, batteries-included Meta-Framework gewünscht ist (SvelteKit)

Astro wählen, wenn:

  • Content König ist — Blogs, Marketing-Sites, Dokumentation
  • Islands Architecture mit der Flexibilität gewünscht ist, React, Svelte oder beides zu nutzen
  • Perfekte Lighthouse-Scores mit minimalem Aufwand benötigt werden

Die ehrliche Antwort für die meisten Teams: Das Framework, das gut beherrscht wird, kombiniert mit der richtigen Rendering-Strategie, wird das „theoretisch schnellere” Framework mit naiver Anwendung übertreffen.

Core Web Vitals: Die Metriken, die den Unterschied machen

Googles Core Web Vitals beeinflussen direkt das Suchranking. 2026 sind die entscheidenden Metriken:

Largest Contentful Paint (LCP) — wie schnell der Hauptinhalt erscheint. Ziel: unter 2,5 Sekunden. Lösung: SSR/SSG, Bildoptimierung und Font-Preloading. Wenn das Hero-Image ein 2MB-unkomprimiertes PNG ist, kann kein Framework das retten.

Interaction to Next Paint (INP) — wie schnell die Seite auf Nutzereingaben reagiert. Ziel: unter 200ms. Lösung: kleinere JavaScript-Bundles, Code Splitting und Vermeidung langer Tasks auf dem Main Thread. Islands Architecture hilft hier enorm.

Cumulative Layout Shift (CLS) — wie stark das Layout während des Ladens springt. Ziel: unter 0,1. Lösung: explizite Bild-Dimensionen, Font-Display-Swap-Strategien und Platzhalter für dynamisch geladene Inhalte.

Das Muster in der Praxis: Teams, die SSR + Islands Architecture + aggressives Code Splitting einsetzen, erreichen konsistent „gute” Core-Web-Vitals-Scores. Teams, die client-gerenderte SPAs ausliefern, kämpfen konsistent — unabhängig vom Framework.

Praktische Architektur für ein wachsendes Team

Hier ist die Frontend-Architektur, die wir Teams beim Skalieren von 3 auf 15 Engineers empfehlen:

Monorepo mit geteiltem Design System. Turborepo oder Nx für Package-Management. Das Design System lebt in einem Shared Package. Jede Produkt-Vertikale besitzt ihr eigenes App-Package.

Feature-basierte Ordnerstruktur. Nicht components/, hooks/, utils/. Stattdessen: features/checkout/, features/search/, features/product/. Jeder Feature-Ordner enthält seine Komponenten, Hooks, Tests und API-Calls. Ein Entwickler, der am Checkout arbeitet, muss nie den Search-Ordner anfassen.

State Management: lokal halten. Globale State Stores (Redux, Zustand) sind nötig für wirklich globale Concerns — Authentifizierung, Feature Flags, Theme. Für alles andere: State in der Komponente halten, die ihn besitzt. Server Components eliminieren den Großteil des Client-seitigen States, indem Data Fetching auf den Server verlagert wird.

Test-Pyramide, nicht Test-Eistüte. Unit Tests für Utility-Funktionen und Hooks. Integration Tests für Feature-Flows. Eine dünne Schicht E2E-Tests für kritische Pfade. Wenn die E2E-Suite 45 Minuten braucht, ist das ein Architektur-Problem, kein Test-Problem.

Fazit

Frontend-Architektur 2026 dreht sich nicht darum, das „beste” Framework zu wählen. Es geht darum, die richtige Rendering-Strategie pro Seite anzuwenden, das Minimum an nötigem JavaScript auszuliefern und die Codebase so zu strukturieren, dass ein Team von 10 Personen arbeiten kann, ohne sich gegenseitig in die Quere zu kommen.

Islands Architecture, Signals-basierte Reaktivität und Server Components sind keine konkurrierenden Ideen — sie sind komplementäre Patterns, die verschiedene Teile desselben Problems lösen: schnelle, interaktive Web-Experiences liefern, ohne in Komplexität zu versinken.

Ein Framework wählen, das das Team beherrscht. Diese Patterns bewusst anwenden. Mit Core Web Vitals messen. Iterieren. Das ist die gesamte Strategie.

Lesebarkeit

Schriftgröße