Warum statische Webseiten die bessere Wahl sind

Das WordPress-Problem

WordPress betreibt über 40% aller Webseiten weltweit. Es ist ein beeindruckendes Ökosystem mit Tausenden Plugins und Themes. Aber für viele Anwendungsfälle ist es die falsche Wahl — besonders für Unternehmenswebseiten, Portfolios und Blogs, die keine dynamischen Benutzerinteraktionen benötigen.

Die Probleme sind struktureller Natur:

Sicherheit

WordPress ist das meistangegriffene CMS der Welt. Jede WordPress-Installation ist eine laufende PHP-Anwendung mit Datenbankanbindung. Jedes Plugin erweitert die Angriffsfläche. Veraltete Plugins sind der häufigste Einfallsvektor für Hacker.

Eine typische WordPress-Seite hat 20-30 Plugins installiert. Jedes einzelne muss aktuell gehalten werden. Wird ein einziges Plugin nicht gepatcht, ist die gesamte Seite gefährdet. SQL-Injection, Cross-Site-Scripting und Remote-Code-Execution sind keine theoretischen Risiken, sondern tägliche Realität.

Performance

Bei jedem Seitenaufruf einer WordPress-Seite passiert Folgendes:

1. Der Webserver empfängt die Anfrage.
2. PHP wird gestartet und interpretiert den Code.
3. Mehrere Datenbankabfragen werden ausgeführt.
4. Das Theme rendert die Seite.
5. Plugins fügen ihre Funktionalität hinzu.
6. Die fertige HTML-Seite wird an den Browser gesendet.

Dieser Prozess dauert typischerweise 200-800 Millisekunden — bei jeder einzelnen Anfrage. Caching kann das abmildern, fügt aber eine weitere Komplexitätsschicht hinzu.

Wartungsaufwand

WordPress erfordert kontinuierliche Pflege: Core-Updates, Plugin-Updates, Theme-Updates, PHP-Version-Updates, Datenbank-Backups, Security-Monitoring. Wer eine WordPress-Seite betreibt, betreibt im Grunde eine Serveranwendung — mit allem, was dazugehört.

Was Static Site Generators anders machen

Ein Static Site Generator (SSG) verfolgt einen fundamental anderen Ansatz. Anstatt Seiten bei jeder Anfrage dynamisch zu erzeugen, werden alle Seiten einmalig beim Build-Prozess generiert. Das Ergebnis sind einfache HTML-, CSS- und JavaScript-Dateien.

Inhalt (Markdown) + Templates (HTML) → Build-Prozess → Statische Dateien

Es gibt keinen Server, der Code ausführt. Keine Datenbank. Keine Plugins, die bei jedem Request laufen. Der Webserver liefert nur fertige Dateien aus — so wie das Web ursprünglich funktionierte.

Hugo: Der schnellste Static Site Generator

Hugo ist ein in Go geschriebener Static Site Generator und einer der schnellsten seiner Art. Eine Seite mit 1.000 Unterseiten wird in unter einer Sekunde gebaut. Hugo bietet:

• Go-Templates: Ein mächtiges Templating-System für Layouts, Partials und Shortcodes.
• Integrierter Asset-Pipeline: CSS-Verarbeitung (Tailwind CSS, PostCSS), JavaScript-Bundling und Bildoptimierung — ohne externe Build-Tools.
• Mehrsprachigkeit: Natives i18n mit Verzeichnis- oder Dateinamen-basierter Sprachzuordnung.
• Taxonomien: Flexible Kategorisierung durch Tags, Kategorien und benutzerdefinierte Taxonomien.
• Null Abhängigkeiten: Hugo ist eine einzelne Binärdatei. Kein Node.js, kein Ruby, kein Python nötig.

Performance-Vergleich

Die Unterschiede sind drastisch. Ein konkreter Vergleich:

Eine statische Seite, die über ein CDN (Content Delivery Network) wie Cloudflare Pages oder Netlify ausgeliefert wird, erreicht TTFB-Werte von unter 20 Millisekunden weltweit. Keine WordPress-Installation kann das erreichen, egal wie viel Caching man einsetzt.

Wann ist ein SSG die richtige Wahl?

Statische Webseiten sind ideal für:

• Unternehmenswebseiten: Firmenauftritt mit Leistungen, Team, Kontakt.
• Blogs und Magazine: Regelmäßig veröffentlichte Inhalte ohne Benutzerinteraktion.
• Dokumentationen: Technische Docs, API-Referenzen, Handbücher.
• Portfolios: Projekte und Referenzen präsentieren.
• Landing Pages: Conversion-optimierte Einzelseiten.

Statische Seiten sind nicht ideal für:

• Web-Applikationen: Wenn Benutzer Daten eingeben, bearbeiten oder in Echtzeit interagieren.
• E-Commerce: Shops mit Warenkorb, Bezahlung und Bestandsverwaltung (obwohl Headless-Ansätze das teilweise lösen).
• Soziale Plattformen: Benutzergenerierte Inhalte, Kommentarsysteme, Feeds.

Der JAMstack-Ansatz

Das Konzept geht über einzelne Webseiten hinaus. JAMstack (JavaScript, APIs, Markup) beschreibt eine Architektur, in der das Frontend statisch ausgeliefert wird und dynamische Funktionalität über APIs eingebunden wird:

• Formulare: Dienste wie Formspree oder Netlify Forms verarbeiten Kontaktformulare ohne eigenen Server.
• Suche: Algolia oder Pagefind bieten clientseitige Volltextsuche für statische Seiten.
• Kommentare: Systeme wie Giscus (GitHub Discussions) oder Utterances fügen Kommentarfunktionen hinzu, ohne die Seite dynamisch zu machen.
• Analytics: Datenschutzkonforme Lösungen wie Matomo oder Plausible laufen unabhängig von der Webseite.

Ein reales Beispiel: ion-solutions.at

Diese Webseite — ion-solutions.at — ist selbst ein Beispiel für den Ansatz. Als Teil unseres Web-Auftritt-Angebots wird sie mit Hugo gebaut, nutzt Tailwind CSS für das Styling und wird als statische Seite ausgeliefert. Das Ergebnis:

• Lighthouse-Score: 100/100 in Performance.
• Ladezeit: Unter 500 Millisekunden bei Erstaufruf, unter 100 ms bei wiederholtem Besuch.
• Hosting-Kosten: Praktisch null, da keine Serverinfrastruktur nötig ist.
• Wartung: Kein WordPress-Update, kein Plugin-Patching, keine Datenbank-Pflege.
• Sicherheit: Keine Angriffsfläche, da kein serverseitiger Code ausgeführt wird.
• Mehrsprachigkeit: Deutsch und Englisch mit vollständiger i18n-Unterstützung.

Der Inhalt wird in Markdown-Dateien geschrieben — einem einfachen Textformat, das sich mit jedem Editor bearbeiten lässt. Änderungen werden über Git versioniert und nachverfolgt. Ein Commit löst den automatischen Build und das Deployment aus.

Fazit

Statische Webseiten sind kein Rückschritt in die Vergangenheit. Sie sind eine bewusste Entscheidung für Performance, Sicherheit und Einfachheit. Für die Mehrheit der Webprojekte — Unternehmensseiten, Blogs, Portfolios — bieten sie objektiv bessere Ergebnisse als ein CMS wie WordPress.

Der Kompromiss ist real: Ohne Redaktionssystem ist die Inhaltspflege technischer. Nicht jeder Kunde möchte in Markdown schreiben oder Git benutzen. Headless-CMS-Lösungen wie Decap CMS oder CloudCannon schließen diese Lücke zunehmend. Aber für Teams, die mit diesen Werkzeugen vertraut sind, gibt es wenig Gründe, zu einem traditionellen CMS zurückzukehren.