React & Next.js — leistungsstarke Webanwendungen
Wir setzen React 18 und Next.js 15 (App Router) für die gesamte 4lawyers-Plattform ein: die Präsentationsseiten der Kanzlei, den Fristenkalender, die Mandantenakten und das Kanzlei-Dashboard. Der Code ist striktes TypeScript, die Tests sind automatisiert, das Deployment erfolgt ohne Ausfallzeit.
Warum Next.js für unsere Projekte
Next.js 15 mit App Router bietet ein einzigartiges hybrides Modell: Statische Seiten (SSG) werden sofort aus dem CDN ausgeliefert, dynamische Seiten laufen als Server Components, die kein unnötiges JavaScript an den Browser senden, und Echtzeit-Seiten nutzen isolierte Client Components. Das Ergebnis ist ein Lighthouse-Score von 95+ ab Werk, ganz ohne Tricks.
Bilder werden über die `<Image>`-Komponente automatisch optimiert (WebP/AVIF, responsives srcSet, Lazy Loading), Schriften werden mit `next/font` in das kritische CSS eingebettet, und Skripte von Drittanbietern laden mit Prioritätsstrategien. Zusammen drücken diese Optimierungen den LCP in realen 4G-Netzen unter 2,5 Sekunden.
- Server Components für die öffentlichen Seiten der Kanzlei — null Client-JS, sofortiges Crawling
- Streaming-SSR mit Suspense für den Live-Fristenkalender und die Verfügbarkeit
- Incremental Static Regeneration (ISR) für umfangreiche Kataloge juristischer Leistungen und Blogartikel — ohne Rebuild
- Route Groups und Parallel Routes für komplexe Layouts ohne erneutes Rendern
Striktes TypeScript — keine stillen Fehler
Alle unsere Projekte nutzen TypeScript mit `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` und `noUncheckedIndexedAccess`. Diese Einstellungen blockieren ganze Kategorien von Laufzeitfehlern bereits beim Kompilieren: Zugriffe auf undefinierte Werte, unvollständige Typen bei API-Antworten, falsche Vergleiche. Ein typisches Projekt hat in der CI 0 TypeScript-Fehler, noch bevor ein einziger Test läuft.
Für das State-Management nutzen wir Zustand (leichtgewichtig, ohne Boilerplate) oder React Context für lokalen Zustand. Das Laden von Daten übernimmt TanStack Query (automatischer Cache, intelligente Invalidierung, stale-while-revalidate). Formulare mit React Hook Form + Zod-Schemavalidierung — synchrone und asynchrone Validierung ohne doppelten Code.
- ESLint mit eigenen Regeln für verbotene Muster (any, console.log, Magic Strings)
- Prettier mit einheitlicher Konfiguration — kein PR wird wegen Formatierung abgelehnt
- Zod zur Laufzeitvalidierung von Daten aus externen APIs
- Pfad-Aliase (`@/components/...`) — saubere Imports ohne `../../..`
Automatisierte Tests und CI/CD
Unit-Tests mit Vitest (schnell, Jest-API-kompatibel), Komponententests mit React Testing Library, E2E-Tests mit Playwright in 3 Browsern (Chromium, Firefox, WebKit). Die GitHub-Actions-Pipeline führt bei jedem PR alle Tests aus; schlägt einer fehl, wird der Merge blockiert. Mindestens 80 % Abdeckung der Geschäftslogik.
- Lighthouse CI — ein Score unter 90 blockiert das Staging-Deployment
- Automatischer Bundle-Analyzer — Warnung, wenn das Bundle gegenüber main um mehr als 5 % wächst
- Storybook für UI-Komponenten — lebendige visuelle Dokumentation
Vorteile und Grenzen
Vorteile
- Lighthouse 95+ vom ersten Tag an, ohne manuelles Tuning.
- Natives SSR und SSG — vollständiges HTML für Google und KI-Suchmaschinen.
- Striktes TypeScript fängt Fehler beim Kompilieren ab, nicht erst in der Produktion.
- Ausgereiftes Ökosystem: Vercel, Tausende Pakete, riesige Community.
Grenzen
- Die Lernkurve bei App Router und Server Components ist steil.
- Häufige Breaking Changes zwischen Hauptversionen — erfordert Wartung.
- Für eine einfache statische Website kann Next.js gegenüber reinem HTML überdimensioniert sein.
- Große Builds erhöhen Kompilierzeit und CI-Kosten.
Kurzes Fazit
Wählen Sie React & Next.js für Websites und Webanwendungen, die schnell, indexierbar und skalierbar sein müssen. Für eine einzelne statische Landingpage ohne Interaktivität genügt ein einfacheres Werkzeug.
Technische Übersicht
| Fähigkeit | Grenze / Schwelle | Typischer Einsatz | |
|---|---|---|---|
| Rendering | SSR, SSG, ISR, CSR | Server Components schränken Browser-APIs ein | Statisches Marketing + dynamisches Dashboard |
| Performance | LCP < 2,5 s, Lighthouse 95+ | Hydration-JS wächst mit der Interaktivität | Stark frequentierte, SEO-kritische Websites |
| Skalierung | Zehntausende Nutzer, Edge-CDN | Benötigt Node- oder Serverless-Hosting | SaaS, Portale, juristische Plattformen |
| Typische Kosten | Open Source, Hosting ab ca. 0 € | Serverless-Funktionen nach Nutzung abgerechnet | Von kleinen Projekten bis zum Enterprise-Einsatz |
Next.js im Vergleich
| Kriterium | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG in einem Framework | Ja, nativ | Teilweise (Nuxt ja, Vite nein) |
| React-Ökosystem | Vollständig | Vue (Nuxt) oder mehrere Frameworks (Astro) |
| Am besten für rein statische Websites | Gut | Astro ist schlanker |
Häufige Fragen
Warum Next.js und nicht reines React (Vite)?
React mit Vite rendert nur auf dem Client, das initiale HTML ist also leer — schlecht für SEO und GEO. Next.js ergänzt SSR und SSG und liefert vollständiges HTML aus, das Google und KI-Suchmaschinen sofort lesen.
Ist Next.js gut für SEO?
Ja. SSR/SSG liefert indexierbares HTML, Metadaten und JSON-LD werden auf dem Server erzeugt, und die Core Web Vitals sind konstruktionsbedingt grün — allesamt starke Rankingsignale.
Kann ich eine bestehende Website auf Next.js migrieren?
Ja, schrittweise: Die Seiten werden einzeln umgezogen, URLs und 301-Weiterleitungen bleiben erhalten, sodass keine Google-Rankings verloren gehen.
Welches Hosting braucht Next.js?
Statische Seiten laufen auf jedem CDN. Dynamische Funktionen (SSR, API-Routen) benötigen Node.js oder eine Serverless-Laufzeit wie Vercel, Netlify oder einen Docker-Container.