Webprojekte bewegen sich heute im Spannungsfeld zwischen Nutzererwartungen, redaktioneller Flexibilität, technischer Komplexität und wirtschaftlichen Anforderungen – und genau hier setzt Dual-Site-Serving (DSS) als wiederholbarer, praxiserprobter Architekturansatz an.

Webprojekte bewegen sich häufig im Spannungsfeld aus Bedienbarkeit für Endnutzer, redaktionellen Anforderungen, technischen Möglichkeiten und wirtschaftlichen Rahmenbedingungen. Nutzer erwarten schnelle und verlässliche Websites, wohingegen Redakteure auf flexible Vorschau- und Arbeitsabläufe angewiesen sind. Und moderne Frontend-Frameworks sowie Headless CMS schaffen zwar viele Freiheitsgrade, führen aber auch zu neuer Komplexität und Kosten im Betrieb.
Dual-Site-Serving – DSS – ist der Architekturansatz, den wir bei neteleven entwickelt und bereits in mehreren Projekten erfolgreich umgesetzt haben, um genau dieses Spannungsfeld aufzulösen. Wir haben den Begriff geprägt, weil wir eine Lösung wollten, die sowohl technisch solide als auch wiederholbar ist – und nicht jedes Mal neu erfunden werden muss. Heute sehen wir: DSS schließt eine Lücke, die viele Unternehmen spüren, die aber selten klar benannt werden kann.
Moderne Frameworks wie Next.js, Nuxt, SvelteKit oder Astro bieten beeindruckend flexible Rendering-Modelle. Sie können statisch generieren, serverseitig rendern oder hybride Mischformen nutzen. Doch jede dieser Varianten bringt langfristig wirkende Architekturentscheidungen mit sich. Nicht alle Modi sind gleich ausgereift, und der Wechsel zwischen ihnen ist selten trivial.
Auf der CMS-Seite zeigt sich ein ähnliches Bild.
Klassische CMS liefern bewährte Modelle, erzeugen performantes HTML und bieten ein integriertes redaktionelles Arbeiten. Gleichzeitig sind sie darauf ausgelegt, ein Auslieferungsszenario zuverlässig zu bedienen – nicht mehrere parallel. Vorschau-Funktionen lassen sich umsetzen, erfordern aber häufig technische Erweiterungen oder Workarounds.
Headless CMS lösen diese Einschränkungen, verlagern aber Preview, Rendering und Auslieferung vollständig in das Frontend. Und genau dort entstehen neue Abhängigkeiten und zusätzliche Betriebslogik, die sorgfältig orchestriert werden will.
Kurz: Die Systeme haben sich weiterentwickelt, die Komplexität ist aber nicht verschwunden, sie ist lediglich an andere Stellen gewandert.
In Webprojekten treffen meist zwei Erwartungen aufeinander:
Nutzer erwarten in erster Linie eine Website, die schnell lädt, zuverlässig erreichbar ist und technisch sauber funktioniert. Sie wollen Inhalte ohne Verzögerung und eine stabile Plattform.
Redakteure haben einen anderen Fokus: Für sie zählt, dass die Vorschau verlässlich ist, Änderungen sofort sichtbar werden und der gesamte Arbeitsprozess ohne technische Hürden abläuft.
Diese Zielsetzungen verlaufen nicht immer parallel:
Statische Auslieferung bietet hohe Performance, Stabilität und eine extrem kleine Angriffsfläche. Gleichzeitig ist sie nicht für ständig wechselnde Inhalte oder vollwertige Echtzeit-Previews gebaut.
Dynamische Auslieferung ist flexibel und aktuell, bringt aber Laufzeitlogik, erhöhte Sicherheitsanforderungen, komplexere Infrastruktur und ggf. ungünstig skalierende Cloud-Kosten mit sich.
Eine separate Preview-Anwendung zu entwickeln löst das Grundproblem nicht, sie verdoppelt Wartungsaufwand und Fehlerpotenzial.
DSS basiert auf einer einzigen Anwendung, die auf zwei unterschiedliche Arten ausgeliefert werden kann. Für die öffentliche Website wird sie statisch generiert, schnell, sicher, belastbar und kosteneffizient. Für redaktionelle Nutzer und interne Prozesse läuft sie dagegen dynamisch, sodass Inhalte aktuell gerendert werden und Preview sowie Tests ohne Einschränkungen möglich sind.
Welcher Modus aktiv ist, entscheidet sich bereits beim Deployment. Dadurch bleiben Frontend und Templates durchgehend identisch, die Vorschau entspricht exakt der späteren Live-Auslieferung und zusätzliche, oft komplexe Preview-Konstruktionen werden überflüssig.
Statische Auslieferung bedeutet nicht, dass eine Website unbeweglich ist oder auf moderne Interaktivität verzichten muss. Moderne Frameworks bringen solide Möglichkeiten mit, Komponenten clientseitig nachzuladen oder zu rendern. Dadurch lassen sich interaktive Module und dynamische Inhalte in klar abgegrenzten Bereichen oder personalisierte Elemente problemlos integrieren, ohne serverseitigen Rendering-Aufwand. Einzelne Bereiche können sich aktualisieren, ohne dass die gesamte Anwendung dynamisch betrieben werden muss.
DSS schließt Dynamik also nicht aus, sondern strukturiert sie bewusst. Der statische Kern bleibt dominant und sorgt für Stabilität und Performance, während dynamische Elemente gezielt dort eingesetzt werden, wo sie fachlich oder technisch wirklich sinnvoll sind, ohne die Architektur unnötig aufzublähen.
DSS entfaltet seine Stärken vor allem dort, wo Inhalte redaktionell gepflegt werden und langfristig stabil bleiben sollen, ohne auf moderne Interaktivität verzichten zu müssen:
Corporate Websites
Marken- und Produktauftritte
Kampagnen- und Landingpages
Dokumentations- oder Wissensportale
Headless-basierte Content-Websites ohne starke Personalisierung
Besonders geeignet ist DSS für Websites, die überwiegend statisch ausgeliefert werden können, aber gezielt dynamische Funktionen benötigen.
DSS ist kein Allzweckmodell. Für bestimmte Szenarien passt eine voll dynamische Architektur besser:
stark personalisierte Bereiche
E-Commerce mit Live-Preisen oder Verfügbarkeiten
datenintensive oder interaktive Anwendungen
Systeme mit Echtzeit-Anforderungen
In solchen Fällen ist eine rein statische Auslieferung ungeeignet oder würde die Vorteile neutralisieren.
Dual-Site-Serving verbindet zwei Welten, die lange als Gegensätze wahrgenommen wurden: effiziente statische Auslieferung und moderne redaktionelle Arbeitsabläufe.
Der Ansatz setzt nicht auf Hype oder Speziallösungen, sondern auf eine klare Trennung der Betriebsmodi, reduzierte Komplexität und verlässliche Performance. Gleichzeitig bleibt genug Raum für moderne, clientseitig dynamische Komponenten, wo sie sinnvoll und notwendig sind.
Für viele Unternehmenswebsites ist DSS die logische Weiterentwicklung des Headless-Prinzips: technisch solide, wirtschaftlich vernünftig und redaktionell angenehm zu bedienen.
neteleven begleitet Unternehmen dabei, zu bewerten, ob DSS zum Projekt passt und wie der Ansatz sauber umgesetzt werden kann.
Christian ist Senior Software Architect bei neteleven mit über 15 Jahren Erfahrung in der Softwareentwicklung. Sein Schwerpunkt liegt auf Backend Architekturen, Systemintegration und Automatisierung. Er steht für pragmatische, kundenorientierte Lösungen, die bewusst nicht von der Stange kommen.

Chistian Eiden
Senior Software Architect