The Keep IT Simple Project

Spart eine statische Website Energie?

Am Ende dieses Projekts steht eine Frage, die uns von Anfang an begleitet hat: Ist das, was wir hier bauen, auch sparsamer?

Eine WordPress-Seite baut jede Seite bei jedem Besuch neu zusammen. Der Server startet PHP, fragt die Datenbank, setzt das HTML zusammen und schickt es los. Eine statische Seite liegt dagegen fertig da. Der Server reicht nur noch eine Datei weiter.

Das klingt nach einem klaren Fall. Die Antwort ist spannender.

Was die Messungen zeigen

Das Team von Green Coding Berlin hat genau diesen Vergleich gemessen: eine schlichte WordPress-Seite gegen dieselbe Seite als fertige HTML-Dateien.

Energie
ein Besuch bei WordPressrund 30 Joule
ein Besuch bei der statischen Seiterund 1,7 Joule
einmal die statische Seite erzeugenrund 2,6 Joule

Pro Besuch braucht die statische Seite also etwa ein Achtzehntel der Energie.

Ein älterer Geschwindigkeitstest kommt in eine ähnliche Richtung: Dort lieferte ein Webserver statische Seiten rund 400-mal so schnell aus wie ein WordPress ohne Zwischenspeicher.

Zeig mir, wie gemessen wurde

Green Coding Berlin hat beide Varianten als Container-Setup gebaut: WordPress mit Apache, PHP und MariaDB auf der einen Seite, die mit HUGO erzeugte statische Fassung auf einem Apache auf der anderen. Gemessen wurde ein Aufruf der Startseite, jeweils in einem möglichst minimalen Aufbau, damit der Vergleich fair bleibt. Zusätzlich wurde der Energiebedarf des Build-Prozesses erfasst, also das Erzeugen der statischen Dateien.

Die Messumgebung ist offen dokumentiert und liegt als Beispiel im Repository von Green Coding. Mit dem Green Metrics Tool lässt sich der Vergleich auf eigener Hardware wiederholen.

Eine echte WordPress-Seite mit Theme, Plugins und mehr Datenbankabfragen braucht pro Aufruf vermutlich mehr als die minimale Testseite. Der Unterschied zur statischen Seite wird dadurch eher größer.

Und jetzt die Überraschung

Rechnen wir das auf eine kleine Website mit 10.000 Besuchen im Monat hoch:

pro Monat
WordPress ohne Zwischenspeicherca. 83 Wh
statische Seiteca. 5 Wh
Ersparnisca. 78 Wh

78 Wattstunden. Das ist etwa so viel, wie eine LED-Lampe an einem langen Abend verbraucht.

Ein kleiner Server, der rund um die Uhr läuft und dabei 20 Watt zieht, braucht im Monat etwa 14 Kilowattstunden. Die Ersparnis durch die Besuche liegt bei rund einem halben Prozent davon.

Green Coding Berlin weist selbst darauf hin: Wer nur auf eine statische Seite umstellt und den Server weiter im Leerlauf betreibt, spart unter Umständen sehr wenig.

Die größte Stellschraube ist also die Infrastruktur, die ohnehin läuft. Die einzelnen Besuche sind im Vergleich dazu klein.

Zeig mir die Rechnung
  • 30 J = 30 Ws = 30 ÷ 3.600 Wh ≈ 0,0083 Wh
  • WordPress: 10.000 × 30 J = 300.000 J ≈ 83,3 Wh
  • statisch: 10.000 × 1,68 J = 16.800 J ≈ 4,7 Wh
  • Ersparnis: ≈ 78,7 Wh
  • Leerlauf: 20 W × 24 h × 30 Tage = 14.400 Wh = 14,4 kWh
  • Anteil: 78,7 ÷ 14.400 ≈ 0,55 %

Die 20 Watt Leerlauf sind ein Beispielwert, kein Messwert.

Was das für KISP bedeutet

In diesem Projekt bleibt WordPress auf einem kleinen Heimserver, dem Cube. Der läuft für andere Dienste ohnehin. Ausgeliefert wird die fertige Website bei einem Webhoster, und dort laufen bei einem Besuch nur noch Dateien über die Leitung, kein PHP und keine Datenbank.

Die Einsparung entsteht also dort, wo die Last tatsächlich wegfällt: beim Hoster, bei jedem einzelnen Besuch.

Und wenn WordPress zwischenspeichert?

Viele WordPress-Seiten nutzen ein Caching-Plugin. Das legt fertige Seiten ab und liefert sie beim nächsten Besuch direkt aus. PHP wird dabei in der Regel noch kurz gestartet, die aufwendige Arbeit mit Datenbank und Theme entfällt.

Damit landet eine WordPress-Seite mit Zwischenspeicher irgendwo zwischen den beiden Messwerten, deutlich näher an der statischen Seite. Noch näher kommt ein Zwischenspeicher, der schon im Webserver sitzt, bevor PHP überhaupt ins Spiel kommt.

Zeig mir, wie es geht

Plugin-basierte Caches wie WP Super Cache oder W3 Total Cache arbeiten über eine Datei namens advanced-cache.php, die WordPress sehr früh lädt. Findet sie eine fertige Seite, wird diese ausgeliefert, bevor Theme, Plugins und die meisten Datenbankabfragen geladen werden.

Serverseitige Caches, etwa im Webserver Caddy oder nginx, beantworten wiederholte Anfragen direkt aus ihrem Speicher. PHP bleibt dann ganz außen vor.

Der Breakeven-Punkt

Eine statische Seite entsteht nicht von selbst. Das Plugin Simply Static ruft beim Export jede Seite einmal über WordPress auf und speichert das Ergebnis als Datei.

Ein Export kostet damit ungefähr so viel Energie wie ein Besuch pro Seite ohne Zwischenspeicher, dazu kommt das Hochladen.

Daraus ergibt sich eine einfache Faustregel:

Die statische Seite lohnt sich energetisch, sobald zwischen zwei Exporten jede Seite im Schnitt etwa einmal besucht wird.

Eine kleine Seite, die selten geändert und regelmäßig besucht wird, erreicht diesen Punkt schnell. Eine große Seite mit vielen Unterseiten, häufigen Komplett-Exporten und wenig Besuch kann mit der statischen Variante sogar mehr verbrauchen.

Simply Static Pro kann auch nur die geänderten Seiten neu erzeugen. Das verschiebt den Breakeven deutlich zugunsten der statischen Seite.

Zeig mir die Formel

Besuche zwischen zwei Exporten > Anzahl Seiten × E_WP ÷ (E_WP − E_statisch)

Mit den Messwerten von Green Coding Berlin:

30 J ÷ (30 J − 1,68 J) ≈ 1,06

Pro Seite reicht also im Schnitt etwas mehr als ein Besuch zwischen zwei Exporten, damit sich der Export energetisch ausgleicht. Energie für das Hochladen der Dateien ist in dieser Faustregel nicht enthalten.

Die Formel geht davon aus, dass ein Export pro Seite etwa so viel kostet wie ein ungecachter WordPress-Aufruf. Eigene Messungen auf dem Cube können das bestätigen oder korrigieren.

Unsere1 ehrliche Antwort

Pro Besuch spart eine statische Seite viel. In der Summe entscheiden zwei andere Dinge: wie viel Infrastruktur dauerhaft mitläuft und wie oft die Seite neu erzeugt wird.

Für KISP heißt das: Die statische Seite beim Hoster ist sparsam, der Cube läuft weiter. Die größere Wirkung liegt darin, Dienste zusammenzulegen und Server nicht ungenutzt laufen zu lassen.

Ein Gedanke für Kundenseiten: Das WordPress läuft dort beim Hoster, in der Regel auf Shared Hosting, und nur die fertige statische Seite wird ausgeliefert. Das entlastet die anderen Nutzer auf demselben Server. Je mehr Seiten so laufen und das echte WordPress nur noch selten anfassen, desto besser lässt sich das Ganze skalieren.

Quellen

Abgerufen am 6. Oktober 2026.

1 Das ist nicht das adlige „Unsere“, sondern Claude.AI und ich, René, von terruhn.it 🙂 ↩