Rendering-Architektur
Eine Frontend-Architektur, gewählt danach, wie Ihr Produkt genutzt wird
Das richtige Rendering-Modell hängt davon ab, wer die Seite zuerst lesen muss: eine Suchmaschine, ein wiederkehrender Nutzer oder ein Gerät mit schwacher Verbindung. Wir wählen zwischen clientseitigem Rendering, serverseitigem Rendering, statischer Generierung und hybriden Frameworks wie Next.js und Nuxt – je nach Inhalt, Zielgruppe und wie oft sich Ihre Daten ändern.
SSR vs. CSR vs. statisch: Was passt?
| Ansatz | Funktionsweise | Passt gut für | Achten Sie auf |
|---|---|---|---|
| Clientseitiges Rendering (SPA) | Der Browser lädt JavaScript und baut die Seite auf | Dashboards und Tools hinter einem Login | Crawler sehen wenig Inhalt; der erste Seitenaufbau ist auf einfachen Smartphones langsamer |
| Serverseitiges Rendering (SSR) | Der Server sendet bei jeder Anfrage fertiges HTML, danach wird die Seite interaktiv | Shops, Marktplätze und Listings, die sich oft ändern und indexiert werden müssen | Serverkosten und Hydration-Zeit |
| Statische Generierung (SSG) | HTML wird einmal beim Deployment erzeugt | Dokumentation, Marketingseiten, Blogs | Bei Inhaltsänderungen ist ein neuer Build nötig |
| Inkrementelle Regenerierung | Statische Seiten werden im Hintergrund neu erzeugt, wenn sich Daten ändern | Große Kataloge mit Tausenden Seiten | Die Cache-Invalidierung braucht sorgfältiges Design |
| Hybrid (Next.js, Nuxt) | Jede Route wählt ihr eigenes Modell; Server-Komponenten streamen HTML | Ein Shop mit Kundenbereich oder ein SaaS mit öffentlichen Marketingseiten | Mehr bewegliche Teile, daher braucht das Team klare Konventionen |
| Cross-Platform (React Native, Capacitor, Tauri, Electron) | Eine Codebasis für Web, Mobile und Desktop | Produkte, die App-Store-Präsenz oder Gerätehardware brauchen | Lücken zwischen nativen und Web-APIs müssen eingeplant werden |
Ein typischer Onlineshop braucht beides. Produkt- und Kategorieseiten werden mit strukturierten Daten serverseitig gerendert, damit Suchmaschinen und KI-Assistenten Preise und Verfügbarkeit lesen können. Warenkorb, Filter und Checkout verhalten sich wie eine Single-Page-App. Hybride Frameworks ermöglichen beides in einer Codebasis.
Eine Codebasis, die klein und modular bleibt
Große Frontends werden langsam, wenn alles von allem abhängt. Wir strukturieren Projekte so, dass:
- UI-Komponenten rein darstellend sind und ihre Daten von außen erhalten.
- Geschäftslogik (Preisregeln, Validierung, Sync) in reinen TypeScript-Modulen liegt, die sich ohne Rendering testen lassen.
- Features getrennte Module mit erzwungenen Grenzen sind, damit die Änderung eines Teams nicht unbemerkt den Screen eines anderen Teams kaputtmacht.
- jede Route nur ihren eigenen Code lädt, damit ein neues Feature nicht jede Seite schwerer macht.
State- und Speichermanagement
Wir trennen die Arten von State, die gern vermischt werden:
Server-State
Daten aus Ihrer API liegen in einem Query-Cache wie TanStack Query, mit klaren Regeln für Neuladen und Aktualität.
UI-State
Geöffnete Panels und Auswahlen bleiben lokal in Komponenten oder in einem kleinen Store wie Zustand oder Pinia.
URL-State
Filter, Tabs und Paginierung stehen in der URL, damit Ansichten geteilt und als Lesezeichen gespeichert werden können.
Persistenter State
Entwürfe und Offline-Warteschlangen landen in IndexedDB.
Kassensysteme, Kiosks und Monitoring-Screens laufen tagelang ohne Neuladen. Dafür testen wir den Speicher über lange Sitzungen und räumen Subscriptions, Timer und Listener auf, damit die App am Ende einer Schicht nicht langsamer wird.
Frontend-Sicherheit
Wir nutzen, was der Browser bietet, um den Schaden zu begrenzen, falls etwas schiefgeht:
- Eine Content Security Policy, die eingeschleuste Skripte blockiert, plus Trusted Types, wo unterstützt.
- Subresource Integrity für Skripte von Drittanbietern.
- Session-Tokens in HttpOnly- und Secure-Cookies statt in localStorage.
- Bereinigung jedes von Nutzern gelieferten HTML vor dem Rendern.
- Abhängigkeitsprüfungen und fixierte Versionen in der CI.
- Permissions Policy und Sandbox-iframes für Widgets von Drittanbietern.
- Niemals Secrets im Client-Bundle.
FAQ
Häufig gestellte Fragen
01Sollten wir Next.js verwenden?
Wenn Sie öffentliche Seiten mit Suchmaschinen-Sichtbarkeit und ein App-Erlebnis hinter einem Login haben, passt es oft gut. Liegt Ihr gesamtes Produkt hinter einem Login, ist eine clientseitige App mit schneller statischer Hülle meist einfacher und günstiger im Betrieb.
02Können Sie ein altes Create-React-App-, AngularJS- oder Vue-2-Projekt migrieren, ohne die Feature-Arbeit zu stoppen?
Ja. Wir migrieren Route für Route hinter einem Proxy, sodass alte und neue App parallel laufen, bis die Migration abgeschlossen ist.
03Bevorzugen Sie ein bestimmtes Framework?
Wir bevorzugen das, das Ihr Team warten kann. Das Architecture Decision Record erklärt die Wahl, damit sie später überprüft werden kann.
Nächster Schritt
Beginnen Sie mit einem Review des Bestehenden
Senden Sie uns Ihr Repository oder einen Staging-Link. Wir melden uns mit den drei Änderungen, die den größten Unterschied für Ihre Release-Geschwindigkeit, Performance und Zuverlässigkeit machen würden.