Warum wir Websites mit Next.js und am Edge bauen

Wir haben sehr viele Stacks ausprobiert. Nach mehr als 40 produktiven Sites und Apps sind wir auf Next.js am Edge als unseren Standard konvergiert. Hier ist die Begründung – einschließlich der Trade-offs.

Warum Next.js

Next.js gibt Ihnen die Möglichkeit, pro Route die passende Rendering-Strategie zu wählen – Static Generation, Server Rendering oder Client Rendering –, ohne das Framework zu wechseln.

Bei einer Marketing-Site sind die meisten Seiten statisch. Der Blog wird statisch generiert. Der Endpoint des Kontaktformulars läuft serverseitig. Die interaktive Demo läuft im Client. Ein Framework deckt all das ab.

Der App Router (eingeführt in v13, ausgereift seit v15) bringt React Server Components. Sie können also Daten serverseitig laden und für Komponenten ohne Interaktivität null JavaScript an den Client schicken. Eine inhaltslastige Seite, die zuvor 200 KB JavaScript ausgeliefert hat, kommt jetzt mit 15 KB aus.

Warum am Edge

Klassische Server laufen in einer Region. Ein Nutzer in Singapur, der einen Server in us-east-1 abruft, addiert 200 bis 300 ms Netzwerk-Latenz auf jede Anfrage, bevor der Server überhaupt mit der Verarbeitung beginnt.

Edge-Laufzeiten – Vercel Edge Functions, Cloudflare Workers – führen Ihren Code an mehr als 30 Standorten weltweit aus. Der Server ist immer in der Nähe des Nutzers. TTFB liegt weltweit konstant unter 50 ms.

Der Trade-off: Edge-Laufzeiten sind eingeschränkt. Kein Dateisystemzugriff, eingeschränkte Node.js-APIs, geringere Speicherlimits. Das zwingt zu architektonischer Disziplin – zustandslose Funktionen, Daten aus APIs oder Edge-gecachten Datenbanken.

Der vollständige Stack

• Framework: Next.js (App Router)
• Styling: Tailwind CSS v4
• Datenbank: Postgres auf Neon (serverlos, Edge-kompatibel) oder Supabase
• Auth: Clerk oder next-auth, je nach Komplexität
• E-Mail: Resend
• Zahlungen: Stripe
• CMS: MDX-Dateien im Repo für inhaltslastige Sites; Sanity für vom Kunden redaktionell pflegbare Inhalte
• Deployment: Vercel

Was wir bewusst nicht nutzen

Wir nutzen kein Client-Side Rendering für Seiten, die es nicht brauchen. Wir nutzen keine REST-APIs, wo eine Server Action oder ein RSC-Fetch einfacher ist. Wir fügen kein Backend-Framework hinzu, wenn Next.js Route Handlers ausreichen.

Komplexität zinst sich auf. Jeder zusätzliche Dienst ist ein weiterer möglicher Ausfallpunkt, eine weitere Authentifizierungsebene, eine weitere Deployment-Pipeline. Der richtige Stack ist der einfachste, der die Anforderungen erfüllt.

Bauen Sie für die Anforderungen, die Sie tatsächlich haben. Fügen Sie Komplexität erst hinzu, wenn Sie die einfachere Lösung tatsächlich überschritten haben.

Warum wir nicht zu PHP oder klassischen CMS zurückgehen

WordPress und ähnliche CMS-Plattformen können einfacher klingen, weil das Modell vertraut ist. In der Praxis bedeuten sie aber ein Plugin-Ökosystem, dessen Sicherheits- und Performance-Profil nur schwer zu beherrschen ist. Bei einer modernen Marketing-Site, die SEO, Conversion und KI-Sichtbarkeit zugleich erfüllen soll, kostet diese Plattform-Wahl jedes Quartal mehr Pflege, als sie Initialaufwand spart.

Mit Next.js am Edge bleibt der Stack klein, der Code prüfbar und das Performance-Budget unter Kontrolle. Das ist auf Sicht die ehrlichste Rechnung.