Ein Stapel gedruckter Hochglanzfotos neben einer komplexen mechanischen Bühne mit beweglichen Teilen.
15 Views
Static Site Generator vs CMS: Zurück in die Zukunft
Bei der Frage Static Site Generator vs CMS denken viele zuerst an einen Rückschritt. Statische HTML-Seiten? Das klingt nach 1998, als wir Webseiten noch mit FrontPage gebaut haben.
Aber der Schein trügt. Die moderne Webentwicklung dreht sich im Kreis – und das aus gutem Grund. Während klassische CMS (wie WordPress) immer fetter und langsamer wurden, entstand eine Gegenbewegung: Der "JAMstack". Keine Datenbank. Kein PHP-Server. Nur pures, rasend schnelles HTML.
Heute klären wir das Duell Static Site Generator vs CMS. Ist es Zeit, die Datenbank auf den Müll zu werfen?
Die Analogie: Das Theaterstück vs. Das Foto
Um den gewaltigen Unterschied bei Static Site Generator vs CMS zu verstehen, stell dir vor, du willst ein Bild zeigen.
Ein Klassisches CMS ist wie ein Theaterstück. Jedes Mal, wenn ein Besucher deine Seite aufruft, muss das Stück neu aufgeführt werden. Der Server (Regisseur) ruft die Schauspieler (Datenbank-Inhalte) auf die Bühne, das Bühnenbild (Template) wird aufgebaut und das Licht (PHP) geht an. Das ist dynamisch und toll – aber es kostet Zeit und Kraft. Wenn 1.000 Zuschauer gleichzeitig kommen, bricht das Theater zusammen.
Ein Static Site Generator (SSG) ist wie ein gedrucktes Foto dieses Theaterstücks. Das Stück wird einmal aufgeführt (beim sogenannten "Build Process"). Dann wird ein Foto gemacht. Wenn nun ein Besucher kommt, drückst du ihm einfach das Foto in die Hand. Es muss nichts mehr aufgebaut oder berechnet werden. Ob ein Besucher kommt oder eine Million – das Foto zu verteilen kostet fast keine Energie.
Runde 1: Geschwindigkeit (TTFB)
Im Rennen Static Site Generator vs CMS gewinnt die statische Seite immer. Punkt. Da keine Datenbank abgefragt werden muss, ist die "Time to First Byte" (TTFB) fast bei Null. Zudem können statische Dateien (HTML, CSS, JS) extrem einfach auf einem CDN (Content Delivery Network) verteilt werden. Deine Seite liegt dann nicht mehr auf einem Server in Frankfurt, sondern gleichzeitig in New York, Tokio und London. Der Nutzer lädt die Seite immer vom nächstgelegenen Knotenpunkt.
Ein klassisches CMS kann da nur mit massivem Caching mithalten – und selbst dann ist es fehleranfälliger.
Runde 2: Sicherheit (Unhackbar?)
Hier wird der Vergleich Static Site Generator vs CMS unfair. Ein klassisches CMS (WordPress, Joomla) hat zwei große Einfallstore:
Das Login-Fenster (/wp-admin).
Die Datenbank (SQL Injection).
Ein Static Site Generator hat beides nicht. Es gibt keine Datenbank, die gehackt werden kann. Es gibt keinen Login-Bereich auf dem Live-Server. Die Seite besteht nur aus dummen Textdateien. Ein Hacker steht vor einer Betonwand. Wo keine Logik ausgeführt wird, kann auch keine Logik manipuliert werden.
Die Schattenseite: Wo ist mein "Speichern"-Button?
Natürlich hat die Sache einen Haken. Wenn Static Site Generator vs CMS so eindeutig wäre, würde jeder SSG nutzen.
Das Problem ist die Redakteurs-Erfahrung. Bei WordPress änderst du einen Text, klickst "Speichern", und er ist live. Bei einem SSG (wie Hugo, Gatsby oder 11ty) änderst du eine Textdatei, dann startet ein "Build-Prozess". Der Computer baut alle HTML-Seiten neu. Das kann bei riesigen Seiten (10.000+ Unterseiten) ein paar Minuten dauern.
Zudem fehlen dynamische Funktionen:
Kommentare? Brauchst du ein externes Tool (Disqus).
Kontaktformular? Brauchst du einen Dienst (Netlify Forms).
Suche? Brauchst du JavaScript (Algolia).
Du baust dir deine Funktionalität aus verschiedenen Services zusammen. Das ist modern, aber komplexer zu managen.
Entscheidungshilfe: Wann lohnt sich der Umstieg?
Hier ist die Checkliste für deine Wahl Static Site Generator vs CMS:
Nimm einen Static Site Generator (Hugo, Gatsby, Next.js), wenn:
Sicherheit: Du baust eine Seite für eine Bank, Versicherung oder Krypto-Projekt.
Performance: Du brauchst 100/100 Punkte bei Google PageSpeed.
Traffic-Spitzen: Du erwartest, dass dein Artikel viral geht (ein SSG hält jedem Ansturm stand).
Wartung: Du hast keine Lust, jede Woche Sicherheits-Updates zu installieren.
Bleib beim klassischen CMS (WordPress, Contao), wenn:
Redakteure: Deine Kunden wollen eine vertraute Oberfläche und sofortige Vorschau.
Häufige Updates: Du veröffentlichst 50 News-Artikel am Tag (die Build-Zeiten würden nerven).
Dynamik: Du brauchst einen komplexen Mitgliederbereich, Foren oder einen großen Shop.
Die Rückkehr des HTML
Der Kampf Static Site Generator vs CMS zeigt: Manchmal ist "weniger" wirklich "mehr". Indem wir den Server-Ballast abwerfen, bekommen wir ein Web, das sicherer, schneller und billiger zu hosten ist. Es ist nicht für jedes Projekt geeignet – ein Social Network wirst du so nicht bauen. Aber für die klassische Firmenwebsite, das Portfolio oder die Dokumentation ist es oft die überlegene Technologie.
Ja. Man verbindet den Static Site Generator oft mit einem sogenannten "Headless CMS" oder Git-basierten CMS (wie Forestry oder Netlify CMS). Der Kunde sieht eine Maske, tippt Text ein, und im Hintergrund wird die statische Seite neu gebaut.
Exzellent. Suchmaschinen lieben sauberes HTML und schnelle Ladezeiten. Da SSGs genau das liefern, hast du oft einen Ranking-Vorteil gegenüber aufgeblähten CMS-Seiten.
Das kommt auf deine Sprache an.
Go: Hugo (extrem schnell).
React/JavaScript: Gatsby oder Next.js.
Vue.js: Nuxt.
Simpel: Eleventy (11ty).
Wie geht es weiter? (Das Finale)
Wir haben jetzt fast alle Optionen durch: Klassisch (WordPress), Maßgeschneidert (Frameworks), Baukasten (Page Builder) und Statisch (SSG).
Aber es gibt noch einen letzten Kandidaten. Einen, der verspricht, alles zu verbinden. Die totale Trennung von Inhalt und Technik. Im letzten Teil unserer Serie schauen wir uns den größten Hype der letzten Jahre an.
Webinteger arbeitet seit vielen Jahren produktiv mit Linux-basierten Entwicklungsumgebungen unter Windows. Der Fokus liegt auf performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen Build-Tools in realen Projekten – nicht auf theoretischen Beispielkonfigurationen.
Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler, Engpässe und bewährte Workarounds.
Webseite besuchen
