Warum wir für unsere Kunden auf Next.js und Headless CMS setzen

Wer heute eine neue Unternehmenswebsite beauftragt, bekommt von den meisten Agenturen dasselbe Angebot: WordPress, ein Theme, ein Page Builder. Das funktioniert. Aber es skaliert nicht — und es kostet langfristig mehr als es spart.

Bei eyedia bauen wir anders. Dieser Artikel erklärt warum, und was „Headless" im praktischen Projektalltag tatsächlich bedeutet.

Das Problem mit dem klassischen CMS-Ansatz

WordPress und vergleichbare Systeme sind monolithisch aufgebaut: Das Backend — also die Datenverwaltung — ist fest mit dem Frontend — der Darstellung im Browser — gekoppelt. PHP rendert serverseitig eine fertige HTML-Seite, die an den Client ausgeliefert wird.

Das hat zwei strukturelle Schwächen:

Performance. Jede Anfrage durchläuft denselben Rendering-Prozess. Caching-Plugins mildern das ab, lösen es aber nicht grundsätzlich. Core Web Vitals — LCP, INP, CLS — sind bei WordPress-Sites ohne erheblichen Zusatzaufwand selten grün.

Flexibilität. Das Frontend ist an das CMS gebunden. Wer dieselben Inhalte auf einer mobilen App, einem digitalen Displaynetzwerk oder einer anderen Domain ausgeben will, steht vor einem Architekturproblem, nicht vor einer Konfigurationsaufgabe.

Was „Headless" architektonisch bedeutet

Ein Headless CMS trennt diese beiden Schichten vollständig. Das CMS — bei uns meistens Sanity v3 — ist ausschließlich für die Datenhaltung und das Content-Management zuständig. Es stellt keine HTML-Ausgabe bereit, sondern eine strukturierte API (GROQ oder GraphQL).

Das Frontend — bei uns Next.js 15 — konsumiert diese API und übernimmt die vollständige Kontrolle über Rendering, Routing und Darstellung.

Die Analogie: Das CMS kennt den Inhalt. Das Frontend entscheidet, was damit passiert. Beide kommunizieren über eine definierte Schnittstelle — und sind unabhängig voneinander deploybar, skalierbar und austauschbar.

Warum Next.js als Frontend-Framework

Next.js bietet ein Rendering-Modell, das monolithische Systeme strukturell nicht replizieren können:

Static Site Generation (SSG) für Seiten, deren Inhalte sich selten ändern. Build-Zeit-Rendering, CDN-Auslieferung, minimale Time-to-First-Byte.

Server-Side Rendering (SSR) für Seiten mit dynamischen oder nutzerspezifischen Inhalten. Rendering auf dem Server pro Request, vollständig SEO-indizierbar.

Incremental Static Regeneration (ISR) — der entscheidende Vorteil für Content-heavy Sites. Seiten werden statisch ausgeliefert und im Hintergrund nach definierten Intervallen neu gebaut, ohne Full-Rebuild. Ein Redakteur speichert einen Artikel in Sanity, ein Webhook triggert die Revalidierung — die Seite ist innerhalb von Sekunden aktuell, ohne dass der Server unter Last gerät.

React Server Components (RSC) im App Router reduzieren das JavaScript-Bundle auf dem Client erheblich. Komponenten, die keine Interaktivität benötigen, werden server-seitig gerendert und als fertiges HTML ausgeliefert.

Das Ergebnis: Lighthouse-Scores, die ohne Post-hoc-Optimierung erreicht werden — weil die Architektur es von Anfang an ermöglicht.

Was das für ein konkretes Projekt bedeutet

Ein typisches Projekt bei eyedia sieht so aus:

• Sanity Studio als redaktionelles Interface — browserbasiert, konfigurierbar, ohne Deployments für Content-Änderungen
• Next.js als Frontend, deployed auf einem eigenen Server (Hetzner, Docker, Traefik) oder auf Vercel
• IONOS SMTP oder Resend für transaktionale Mails
• Supabase wenn Auth oder eine relationale Datenschicht benötigt wird

Der Redakteur arbeitet in Sanity — er sieht kein GitHub, kein Terminal, keine Deployment-Pipeline. Der Entwickler arbeitet in Next.js — er hat vollständige Kontrolle über das Frontend, unabhängig vom CMS.

Wenn ein Kunde in zwei Jahren das CMS wechseln will: Frontend bleibt. Wenn er eine mobile App bauen will: dieselbe Sanity-API, neues Frontend. Kein Re-Build des gesamten Systems.

Wann dieser Stack sinnvoll ist — und wann nicht

Headless + Next.js ist kein Allheilmittel. Für eine einfache 5-Seiten-Unternehmenswebsite ohne Wachstumspläne ist der Aufwand überproportional.

Der Stack zahlt sich aus wenn:

• Die Website Content-getrieben ist und regelmäßig aktualisiert wird
• Performance und Core Web Vitals geschäftskritisch sind (E-Commerce, Lead-Gen)
• Inhalte auf mehreren Kanälen ausgespielt werden sollen
• Das Projekt langfristig skalieren soll, ohne Architektur-Schulden aufzubauen
• Ein Entwicklerteam die Codebasis langfristig warten wird

Für KMUs in Köln und der DACH-Region, die eine professionelle digitale Präsenz aufbauen wollen, ist das in den meisten Fällen gegeben.

Fazit

Der Trend weg vom monolithischen CMS hin zu Headless-Architekturen ist kein Hype — er ist eine logische Konsequenz aus den Anforderungen moderner Web-Projekte. Next.js und Sanity sind dabei nicht die einzige Kombination, aber eine, die wir bei eyedia nach mehreren Produktionsprojekten als solid, wartbar und performant einschätzen.

Wenn du ein Web-Projekt planst und verstehen willst, ob dieser Stack für dein Vorhaben passt — sprich uns an.