Nachhaltige Websites: weniger bewegliche Teile, weniger Verbrauch

Diese Knowledge Base besteht aus fertigen Dateien. Gut tausend HTML-Seiten, knapp tausend Markdown-Zwillinge, ein Suchindex — alles entsteht beim Build und liegt danach als Ordner auf einem Apache. Auf dem Server läuft für diese Seite kein PHP, keine Datenbank, kein Anwendungsprozess. Bevor ich 2020 von WordPress umgestiegen bin, habe ich lange optimiert, gecacht und Plugins ausgemistet. Was mich am Ergebnis heute am meisten überzeugt, ist gar nicht die Geschwindigkeit. Es ist, wie wenig läuft.

Genau darum geht es hier: um Websites mit wenigen beweglichen Teilen. Weniger Prozesse heißt weniger Strom, weniger Hardware, weniger Updates und am Ende eine kleinere Rechnung. Das ist kein Messbericht, sondern eine Sammlung von Wegen. Drei davon stelle ich vor: die statische Seite samt passendem schlankem Webserver, aggressives Caching für Systeme, die dynamisch bleiben müssen, und den statischen Export für WordPress. Dazu eine Checkliste, die bei jedem der drei Wege greift.

Wenn du wenig Zeit hast: Lies den Abschnitt zu Static Web Server und die Checkliste.

Was eine Website verbraucht — und wo

Strom verbraucht eine Website an drei Stellen: im Rechenzentrum, im Netz und auf dem Gerät deiner Besucher. Das Sustainable Web Design Model (öffnet in neuem Tab) in Version 4, auf dem auch der bekannte Website Carbon Calculator (öffnet in neuem Tab) aufsetzt, verteilt die Energie so: 22 % Rechenzentren, 24 % Netze, 54 % Endgeräte. Seine Autoren schreiben selbst dazu, dass das Modell top-down schätzt, die Emissionen eher überschätzt und sich kaum eignet, um einzelne Teile eines Systems zu bewerten, etwa die CPU-Auslastung eines Servers. Ich nehme die Zahlen deshalb als Richtung, nicht als Messwert.

Die Richtung ist trotzdem klar. Es gibt zwei Hebel: weniger übertragen (das entlastet Netz und Endgerät) und weniger rechnen (das entlastet das Rechenzentrum). Beim ersten Hebel ist noch viel Luft. Laut Web Almanac 2025 (öffnet in neuem Tab) wiegt die mediane Startseite mobil 2,56 MB und am Desktop 2,86 MB, mobil 8,4 % mehr als ein Jahr zuvor. Das Kapitel zur Nachhaltigkeit von 2024 (öffnet in neuem Tab) fand rund die Hälfte aller Text-Ressourcen unkomprimiert und etwa ein Viertel der mobilen Websites ganz ohne Cache-Header.

Und der Rahmen wächst: Die Internationale Energieagentur (öffnet in neuem Tab) schätzt den Strombedarf aller Rechenzentren für 2024 auf rund 415 TWh, etwa 1,5 % des weltweiten Verbrauchs, und erwartet bis 2030 rund 945 TWh. Für Deutschland rechnet der Bitkom (öffnet in neuem Tab) für 2024 mit 20 Milliarden kWh. Eine einzelne Website ändert daran nichts. Aber jede Antwort, die ohne Rechenarbeit auskommt, ist eine, die dieser Kurve nichts hinzufügt — und das multipliziert sich mit jedem Aufruf.

Wer das systematisch angehen will, findet in den Web Sustainability Guidelines (öffnet in neuem Tab) des W3C einen Katalog. Sie sind ein Entwurf einer Group Note (Stand 24. September 2026), also keine Empfehlung des W3C, aber gut gegliedert. Ich verweise unten auf die passenden Nummern.

Weniger bewegliche Teile: was bei statischen Seiten wegfällt

Eine klassische CMS-Seite rechnet jede Seite bei jedem Aufruf neu: PHP startet, fragt die Datenbank, rendert das Theme, lädt Plugins. Eine statische Seite hat diese Arbeit einmal beim Build erledigt. Der Server liest danach nur noch eine Datei und schickt sie los.

	Dynamisch (PHP + Datenbank)	Dynamisch mit Seiten-Cache	Statisch
Arbeit pro Aufruf	Skript + Abfragen + Rendering	Treffer: Datei lesen; Fehlschlag: alles	Datei lesen
Dauerhaft laufend	Webserver, PHP-Prozesse, Datenbankserver	dasselbe + Cache	Webserver
Daten zum Sichern	Dateien + Datenbank	dasselbe	Dateien (bei mir: das Repository)
Kompression	pro Antwort	Treffer: je nach Setup einmal je Eintrag	einmal beim Build möglich
Versionen, die du pflegen musst	Webserver, PHP, Datenbank, CMS, Plugins, Theme	dasselbe + Cache-Schicht	Webserver
Angriffsfläche	Anwendung, Adminbereich, Datenbank	dasselbe	Webserver

Die vorletzte Zeile unterschätzen die meisten. Jede Laufzeit hat ein Ablaufdatum, und das erzwingt Arbeit — ob die Seite sich inhaltlich ändert oder nicht. Stand heute bekommt PHP 8.2 (öffnet in neuem Tab) nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. MySQL 8.0 (öffnet in neuem Tab) bekommt seit dem 21. April 2026 keine neuen Korrekturen mehr (nur noch Oracles „Sustaining Support"), MariaDB 10.6 (öffnet in neuem Tab) seit Juli 2026 keine Community-Updates mehr. WordPress selbst empfiehlt (öffnet in neuem Tab) PHP 8.3 oder höher und „MariaDB 10.11+ oder MySQL 8.0+" — also unter anderem eine Datenbank-Version, die gerade aus der Pflege gefallen ist. Wer also eine WordPress-Seite betreibt, plant Upgrades für drei bis vier Komponenten ein, die nichts mit dem Inhalt zu tun haben. Auf dem Server braucht eine statische Seite davon keine.

Das wirkt bis in die Hardware. Eine Anwendung mit Datenbank will Arbeitsspeicher reserviert haben, auch nachts, wenn niemand kommt. Fertige Dateien laufen auf dem kleinsten Webspace, auf einem kleinen virtuellen Server oder einem Einplatinenrechner. Kleinere Tarife sind billiger, und ältere oder schwächere Hardware bleibt länger brauchbar. Das zählt doppelt, denn das Modell rechnet neben dem Betrieb auch die Herstellung der Geräte ein.

Die ehrliche Kehrseite: Die Arbeit verschwindet nicht, sie wandert an den Build. Meine Toolchain mit Node.js und npm muss ich pflegen, und wie ich sie absichere, steht in Node.js und npm absichern. Der Unterschied: Diese Toolchain läuft ein paar Minuten, wenn ich etwas ändere — lokal oder in einem CI-Runner —, nicht rund um die Uhr öffentlich erreichbar auf einem Server. Warum ich mich damals für 11ty entschieden habe und was das an Wartungszeit gespart hat, beschreibe ich ausführlich in Warum 11ty.

Ein Webserver mit wenig beweglichen Teilen: Static Web Server

Eine statische Seite braucht einen Webserver, und auch der kann klein oder groß sein. Ich nutze Apache, weil die Seite in einem bestehenden Docroot liegt. Wer seine statische Seite aber selbst betreiben will — auf einem kleinen virtuellen Server, im Container, auf einem ARM-Board —, findet in Static Web Server (öffnet in neuem Tab) (kurz SWS) ein Werkzeug, das genau dafür gebaut ist.

Was SWS ist

SWS ist in Rust geschrieben und baut auf den Bibliotheken Hyper und Tokio auf. Das Projekt beschreibt sich als „single ~4MB binary that runs everywhere". Die Zahl entspricht eher dem Download: Entpackt ist die Linux-Datei von 2.44.0 knapp 8,4 MB groß. Die musl-Builds für Linux sind statisch gelinkt und brauchen keine Laufzeitabhängigkeiten, einen Garbage Collector gibt es nicht, die Lizenz ist MIT oder Apache 2.0. Fertige Builds gibt es unter anderem für Linux, macOS, Windows, FreeBSD, NetBSD, Illumos und Android, für x86, x86_64, ARM und ARM64. Das Docker-Image auf Basis von scratch ist laut Docker Hub komprimiert keine 4 MB groß. Eine Zahl zum Arbeitsspeicher nennt das Projekt nicht, nur „low CPU and RAM overhead" — ich gebe deshalb auch keine an.

Was mich daran überzeugt, ist der Zuschnitt. Das meiste, was eine statische Seite vom Server braucht, ist eingebaut und per Schalter oder Konfigurationsdatei zu haben, ohne Module nachzuladen:

Vorab komprimierte Dateien: Liegt neben index.html eine index.html.br, .gz oder .zst, liefert SWS sie aus — laut Doku „with zero CPU cost". Die Kompression passiert einmal beim Build statt bei jedem Aufruf. Wer nicht vorkomprimiert, bekommt gzip, Brotli oder zstd zur Laufzeit.
Caching: Cache-Control-Header und Last-Modified mit bedingten Anfragen, sodass unveränderte Dateien nur noch ein 304 kosten. ETag kommt erst mit v3.
Betrieb: HTTP/2 und TLS, Security-Header, Weiterleitungen und Rewrites, eigene 404- und 50x-Seiten, Basic Auth, ein /health-Endpunkt, Prometheus-Metriken, sauberes Herunterfahren und Socket-Aktivierung über systemd.
Konfiguration: alles als Kommandozeilen-Schalter, Umgebungsvariable oder in einer sws.toml.

v2 ist LTS, v3 ist Beta

Beim Versionsstand lohnt ein genauer Blick. Die stabile Linie ist v2, aktuell 2.44.0 vom 31. Juli 2026 (öffnet in neuem Tab). Mit diesem Release ist v2 in den Langzeit-Support gegangen: Es kommen nur noch Fehler- und Sicherheitskorrekturen, die Entwicklung läuft an v3. Davon gibt es bisher eine Vorabversion, 3.0.0-beta.1 vom 21. Juli 2026 (öffnet in neuem Tab); weitere Betas sind angekündigt, ein Termin für die finale Version nicht. Für den Produktivbetrieb verweist das Projekt selbst auf v2.

Spannend ist v3 trotzdem, weil sich die Voreinstellungen in die richtige Richtung bewegen. Laut Release-Notes zu 3.0.0-beta.1 (öffnet in neuem Tab) und Migrationsleitfaden (öffnet in neuem Tab):

Vorab komprimierte Dateien und Security-Header sind standardmäßig an (die Security-Header gelten, sobald TLS aktiv ist).
Versionierte, dauerhaft cachebare Dateien bekommen ein Jahr max-age, Feeds eine Stunde, alles andere — auch HTML — Cache-Control: no-cache. Das ist genau die Aufteilung, die du für Browser-Caching willst (mehr dazu unten).
Der neue HTTP-Stack ist Hyper 1, TLS und HTTP/2 haben getrennte Schalter, Logs kommen als JSON, der eingebaute Speicher-Cache gilt als stabil.
Der Standard-Port ist in der Beta 8787 statt 80. Im Entwicklungszweig hat sich das seither schon wieder geändert, die Voreinstellungen können sich bis zur finalen Version also noch verschieben.
WebAssembly unterstützt v3 vorerst nicht.

Wer heute aufsetzt, nimmt v2 und schaut sich v3 im Testsystem an. Ein Hinweis noch zur Pflege: Auch ein kleiner Server braucht Updates. Mit 2.44.0 (öffnet in neuem Tab) kamen vier Sicherheitskorrekturen, zwei davon als „moderate" eingestuft: Über vorkomprimierte Dateien ließ sich per Symlink das Web-Root verlassen, und /metrics war trotz Basic Auth offen. Dazu kam eine Path-Traversal-Lücke („low") in der Markdown-Negotiation ab 2.40.0. Der Unterschied zum CMS: Das Update ist eine einzige Datei.

Markdown für KI-Systeme, ohne Rewrite-Regeln

Für das Experiment dieser Seite ist eine Funktion besonders interessant: die Markdown-Content-Negotiation (öffnet in neuem Tab). Schickt ein Client — etwa ein KI-Agent — Accept: text/markdown, liefert SWS statt der HTML-Seite die Markdown-Fassung aus, sofern es eine gibt. Die Funktion steht in der v3-Doku, ist aber nicht neu: Sie kam bereits mit v2.40.0 im November 2025 (öffnet in neuem Tab) und ist in v2 nutzbar.

Eingeschaltet wird sie mit einem Schalter:

static-web-server --root ./public --port 8080 --accept-markdown
curl -H "Accept: text/markdown" http://localhost:8080/article

Alternativ per Umgebungsvariable SERVER_ACCEPT_MARKDOWN oder in der sws.toml mit accept-markdown = true im Abschnitt [general]. SWS sucht dann nacheinander pfad.md, pfad.html.md und pfad/index.html.md und antwortet mit Content-Type: text/markdown; charset=utf-8. Die Funktion greift nur bei einem ausdrücklichen text/markdown im Accept-Header. Accept: */* oder text/* lösen sie nicht aus, ein normaler Browser bekommt also weiter HTML.

Warum mir das gefällt, sehe ich an meinem eigenen Setup. Auf Apache läuft dieselbe Negotiation bei mir über Rewrite-Regeln in der .htaccess der Hauptseite. Für die Startseite von /db/ selbst brauchte es zusätzlich eine Sonderregel, weil die geerbte Regel dort die falsche Datei suchte — gefunden habe ich das erst nach einem Deploy. Das funktioniert, ist aber genau die Sorte beweglicher Teil, um die es hier geht. Bei SWS ist es ein Schalter. Ob das zur Ablage dieser Seite passt (/foo/index.html mit dem Zwilling /foo.md daneben), habe ich mit 2.44.0 an einem Testordner nachgestellt: /foo/ und /foo liefern mit Accept: text/markdown die Datei foo.md, ohne Accept-Header weiter das HTML. Prüf trotzdem, wie dein Generator die Markdown-Dateien ablegt.

Einen Punkt solltest du kennen, bevor du einen Cache oder ein CDN davorschaltest: SWS setzt bei dieser Funktion keinen Vary: Accept-Header — weder die Doku noch der Quellcode (öffnet in neuem Tab) tun das. Ein Zwischenspeicher weiß dann nicht, dass unter derselben URL zwei Fassungen liegen, und könnte einem Browser das Markdown oder einem Agenten das HTML ausliefern. Ohne Cache davor ist das egal. Mit Cache setzt du den Header selbst, über die eigenen Header (öffnet in neuem Tab) in der sws.toml ([[advanced.headers]]). Achtung: Ein eigener Vary ersetzt den, den SWS für die Kompression setzt — trag also Vary = "Accept, Accept-Encoding" ein. Meine Apache-Konfiguration schickt Vary: Accept deshalb bei HTML und Markdown mit.

Wie das Markdown-Angebot dieser Seite insgesamt aussieht, mit llms.txt und .md-Zwilling je Seite, steht in Schreiben für KI und GEO: Sichtbarkeit in KI-Antworten.

Weg 2: Aggressives Caching für Systeme, die dynamisch bleiben

Nicht jede Seite kann statisch werden. Dann ist Caching der zweitbeste Weg: Die Seite wird einmal berechnet und danach als fertige Kopie ausgeliefert, bis sich etwas ändert. Die Ebenen bauen aufeinander auf.

Im CMS. Für WordPress gibt es Seiten-Cache-Plugins, die fertige HTML-Dateien auf die Platte schreiben. WP Super Cache (öffnet in neuem Tab) kann diese Dateien im Experten-Modus per mod_rewrite direkt vom Apache ausliefern lassen — dann startet PHP für einen Treffer gar nicht erst. Cache Enabler (öffnet in neuem Tab) und W3 Total Cache (öffnet in neuem Tab) arbeiten ähnlich, W3 Total Cache zusätzlich mit Redis oder Memcached als Speicher. LiteSpeed Cache (öffnet in neuem Tab) ist ein Sonderfall: Das automatische Seiten-Caching setzt einen LiteSpeed-Server oder das QUIC.cloud-CDN voraus.

Auf dem Server. nginx bringt mit fastcgi_cache (öffnet in neuem Tab) einen eigenen Cache vor PHP mit. Mit fastcgi_cache_use_stale updating und fastcgi_cache_background_update liefert er die alte Fassung weiter aus, während er im Hintergrund die neue holt. Gezieltes Löschen einzelner Einträge (fastcgi_cache_purge) gibt es allerdings nur im kommerziellen Abonnement. Apache hat mod_cache (öffnet in neuem Tab); in seinem standardmäßig aktiven schnellen Modus (CacheQuickHandler on) überspringt er dabei auch Authentifizierung und Zugriffsprüfung, geschützte Inhalte gehören also nicht hinein.

Als Reverse-Proxy. Der Klassiker heißt inzwischen anders: Das Open-Source-Projekt Varnish Cache wurde in Vinyl Cache (öffnet in neuem Tab) umbenannt. Hintergrund ist laut der Ankündigung von Poul-Henning Kamp (öffnet in neuem Tab) das Markenrecht: Die Anwälte von Varnish Software beanspruchen den Namen „Varnish Cache" für sich. Das erste Release unter neuem Namen war 9.0.0 im März 2026, aktuell ist 9.1.0; aus varnishd wurde vinyld. Varnish Software bietet unter dem alten Namen eine eigene Distribution an, die auf Vinyl Cache aufsetzt. Funktional bleibt es dabei: ein HTTP-Cache, den du vor jeden Server stellst und mit der Sprache VCL steuerst, einschließlich Purge und Ban zum gezielten Leeren.

Am Rand des Netzes. Ein CDN hält Kopien nahe bei den Besuchern. Cloudflare etwa kann mit „Cache Everything" (öffnet in neuem Tab) auch HTML zwischenspeichern und warnt selbst, dass Besucher dann Informationen sehen können, die nicht für sie bestimmt sind, wenn die Seite personalisierte Teile hat. Für WordPress gibt es die Automatic Platform Optimization (öffnet in neuem Tab), die eingeloggte Nutzer am Cache vorbeileitet.

Wo der Cache leckt

Aggressiv cachen heißt vor allem: wissen, wann der Cache nicht greift. Bei WordPress sind es die Cookies (öffnet in neuem Tab). Wer eingeloggt ist (wordpress_logged_in_…) oder einmal kommentiert hat (comment_author_…), bekommt bei den gängigen Lösungen die Seite frisch berechnet. Dazu kommen URLs mit Parametern, Formulare mit Einmal-Token und alles, was personalisiert ist. Ein Cache, der bei jedem zweiten Aufruf vorbeigeht, spart entsprechend wenig.

Das zweite Problem ist das Leeren. Ändert sich ein Menü, sind auf einen Schlag alle Seiten veraltet. Und was ein fremder Zwischenspeicher — ein Proxy unterwegs oder der Browser — mit langer Lebensdauer einmal hat, bekommst du laut MDN (öffnet in neuem Tab) nicht mehr zurück. Leeren kannst du nur Caches, die du selbst betreibst.

Browser-Caching: die Regel, die immer passt

Daraus folgt die eine Regel, die für jeden der drei Wege gilt (WSG 4.2): HTML kurz, Assets lang. HTML bekommt Cache-Control: no-cache — das heißt nicht „nicht speichern", sondern „vor dem Benutzen nachfragen", was dank ETag meist nur ein 304 kostet. CSS, JavaScript, Schriften und Bilder bekommen ein Jahr Lebensdauer und immutable (öffnet in neuem Tab), und jede Änderung bekommt einen neuen Dateinamen mit Version oder Hash. Auf dieser Seite sieht es so aus: HTML und Markdown laufen sofort ab (max-age=0), CSS, JavaScript, Schriften und Bilder nach einem Jahr. CSS und JavaScript bekommen bei jedem Build eine neue Versionsnummer an die URL gehängt, damit eine Änderung sofort ankommt. immutable setzt diese Seite derzeit nicht.

Bei allem Lob fürs Caching: Es verschiebt die Arbeit, statt sie zu entfernen. Hinter dem Cache laufen weiter PHP, Datenbank und alle Updates aus der Tabelle oben. Wenn du ohnehin dort angekommen bist, dass fast alles aus dem Cache kommt, lohnt der Blick auf Weg 3.

Weg 3: Statisch nachrüsten — WordPress bleibt Redaktionssystem

Du musst WordPress nicht aufgeben, um statisch auszuliefern. Zwei Plugins machen aus einer WordPress-Installation eine statische Kopie: Die Redaktion arbeitet weiter im gewohnten Backend, Besucher bekommen fertige Dateien.

Staatic (öffnet in neuem Tab) (Version 1.13.2, über 2.000 aktive Installationen) durchsucht die Seite laut Beschreibung „like a visitor" — ausgehend von der Startseite plus allen URLs, die du zusätzlich angibst — und legt das Ergebnis als Veröffentlichung ab. Schon die kostenlose Version veröffentlicht in ein lokales Verzeichnis, nach Amazon S3 oder kompatiblen Speicher, zu GitHub, Netlify, per SFTP oder als ZIP. Weiterleitungen, eigene 404-Seiten und HTTP-Header sind enthalten, ebenso Origins hinter Basic Auth. Formulare, Suche, zeitgesteuerte und änderungsbasierte Veröffentlichungen gibt es in der Premium-Version.

Simply Static (öffnet in neuem Tab) (Version 3.8.16, über 30.000 aktive Installationen) exportiert in der kostenlosen Version als ZIP oder in ein lokales Verzeichnis. Die Pro-Version (laut Preisseite (öffnet in neuem Tab) 99 US-Dollar pro Jahr und Site) veröffentlicht unter anderem zu GitHub, AWS S3, BunnyCDN und per SFTP, exportiert nur geänderte Seiten und bringt Formulare, eine statische Suche mit Fuse.js oder Algolia und sogar Kommentare mit. Die Kommentare reicht Simply Static an die WordPress-Installation weiter, die dafür erreichbar bleiben muss.

Beide sagen offen, wo die Grenze liegt: Shops mit Warenkorb und Kasse, Mitgliederbereiche, Logins, personalisierte Inhalte und alles, was zur Laufzeit Daten vom Server holt. Kontaktformulare und Suche brauchen Ersatz — einen externen Formulardienst, einen Webhook oder eine Suche, die im Browser läuft. Dass das trägt, zeigt diese Seite: Ihre knapp tausend Seiten in zwei Sprachen durchsuchst du mit Pagefind (öffnet in neuem Tab), einem Index, den der Build als statische Dateien erzeugt. Ein Suchserver läuft dafür nicht.

Der größte Gewinn liegt aber woanders. Wenn Besucher nur noch die Kopie sehen, muss WordPress nicht mehr öffentlich erreichbar sein. Staatic empfiehlt dafür ausdrücklich eine „separate, preferably protected address", Simply Static beschreibt (öffnet in neuem Tab) die Absicherung per Basic Auth, auch um doppelte Inhalte in Suchmaschinen zu vermeiden. Das WordPress dahinter braucht weiter seine Updates und seine PHP-Version, aber die Angriffsfläche im öffentlichen Netz schrumpft auf den Webserver mit den fertigen Dateien. Und der kann dann auch ein kleiner sein — etwa Static Web Server von oben.

Checkliste: sparen, egal welcher Weg

Diese Punkte greifen bei der statischen Seite genauso wie beim gecachten CMS. In Klammern die passende Leitlinie der WSG.

Bilder zuerst (2.9). Sie sind laut Web Almanac der größte Einzelposten der mobilen Startseite. Moderne Formate wie AVIF und WebP, passende Größen per srcset, loading="lazy" unterhalb des sichtbaren Bereichs. Diese Seite erzeugt AVIF und WebP beim Build.
Schriften selbst hosten und beschneiden (2.11). WOFF2, nur die Schnitte, die du wirklich nutzt, und nur die Zeichen, die du brauchst. Für die Text-Diagramme hier lädt der Browser nur auf Seiten, die eines enthalten, eine eigene Schrift von knapp 24 KB. Sie ist auf die Zeichen beschnitten, die in den Diagrammen vorkommen — Rahmen-, Block- und Formzeichen samt Grundzeichen —, statt eine komplette zweite Schriftfamilie mitzubringen.
JavaScript und Abhängigkeiten sparsam (3.2, 3.5, 3.11, 3.12). Jedes Skript wird übertragen und auf dem Gerät ausgeführt, und das Endgerät ist laut Modell der größte Verbraucher. Drittanbieter-Einbindungen besonders kritisch prüfen.
Kompression einmal statt immer (4.3). Brotli oder zstd beim Build erzeugen und vorab komprimiert ausliefern. Wie die Werkzeuge dafür funktionieren, zeigen die Cheat-Sheets zu gzip und zstd.
Cache-Header setzen (4.2): HTML kurz, Assets lang mit Fingerprint, siehe oben.
Ökostrom-Hosting prüfen (4.1). Der Green Web Check (öffnet in neuem Tab) der Green Web Foundation zeigt, ob dein Anbieter grünen Strom nachweist; CO₂-Kompensation akzeptiert die Green Web Foundation seit 1. Oktober 2026 (öffnet in neuem Tab) nicht mehr als Nachweis. In Deutschland verpflichtet das Energieeffizienzgesetz (öffnet in neuem Tab) Rechenzentren ab 300 kW Anschlussleistung, ihren Strom ab 2027 bilanziell zu 100 % aus erneuerbaren Quellen zu decken. Eine Novelle, die das Kabinett im Juni 2026 beschlossen hat, würde diese Frist auf 2030 verschieben und die Schwelle anheben; der Bundestag hat noch nicht entschieden.
Laufzeiten aktuell halten (3.15), wo es sie gibt. Eine Version im Support bekommt Sicherheitskorrekturen, und ein Upgrade, das du planst, ist billiger als eines unter Zeitdruck nach dem Support-Ende.
Aufräumen. Alte Medien, verwaiste Seiten, nicht mehr genutzte Plugins: Was nicht da ist, muss nicht gesichert, gepflegt und ausgeliefert werden.

Und Dark Mode? Spart Strom, aber weniger, als oft behauptet. Eine Purdue-Studie von 2021 (öffnet in neuem Tab) maß auf OLED-Displays bei üblicher Helligkeit nur 3–9 %, erst bei voller Helligkeit 39–47 %. Auf LCDs, deren Hintergrundbeleuchtung immer leuchtet, bringt es praktisch nichts. Ein schöner Nebeneffekt, kein Hebel.

Was im Geldbeutel ankommt

Die Umwelt und dein Konto profitieren an denselben Stellen. Weniger laufende Prozesse heißen kleinere Tarife oder kleinere Server. Weniger Datenbank heißt weniger Backup-Aufwand. Weniger übertragene Daten heißen weniger Traffic, falls dein Anbieter danach abrechnet. Und statische Dateien lassen sich auf so gut wie jedem Webspace oder Objektspeicher ablegen, was dir bei der Wahl des Anbieters freie Hand lässt.

Der größte Posten taucht aber in keiner Rechnung auf: deine Zeit. Kein Update-Fenster für PHP und Datenbank, kein Nachziehen von Plugins, kein Notfall, weil eine Lücke ausgenutzt wird. In Warum 11ty habe ich beschrieben, wie dieser Aufwand bei mir über sechs Jahre gegen null gegangen ist.

Wo statisch nicht passt

Ein Shop mit Warenkorb, ein Kundenportal, eine Community mit Konten, alles mit Echtzeitdaten: Hier braucht es einen Server, der rechnet. Das heißt aber nicht, dass alles dynamisch sein muss. Oft lohnt eine Trennung: Die Seiten, die alle sehen — Startseite, Produktbeschreibungen, Blog, Hilfe —, werden statisch oder aggressiv gecacht, und nur der kleine Teil, der wirklich personalisiert ist, läuft dynamisch. Die meisten Aufrufe landen dann auf der günstigen Seite.

FAQ

Ist eine statische Website automatisch nachhaltig?

Nein. Sie spart Rechenarbeit auf dem Server, aber eine statische Seite mit 5 MB Bildern und drei Tracking-Skripten belastet Netz und Endgerät trotzdem. Die Architektur ist die gute Ausgangslage, die Checkliste oben entscheidet den Rest.

Wie messe ich den CO₂-Fußabdruck meiner Website?

Der Website Carbon Calculator (öffnet in neuem Tab) und die Bibliothek CO2.js (öffnet in neuem Tab) schätzen ihn auf Basis des Sustainable Web Design Model v4. Es sind Schätzungen über die übertragene Datenmenge, keine Messungen — gut zum Vergleichen vorher und nachher, nicht als absolute Zahl.

Soll ich Static Web Server v3 schon produktiv einsetzen?

Noch nicht. v3 ist Stand Oktober 2026 eine Beta, und die Voreinstellungen können sich bis zur finalen Version noch ändern. Für den Betrieb empfiehlt das Projekt v2, die als LTS-Version weiter Fehler- und Sicherheitskorrekturen bekommt. Die Markdown-Content-Negotiation gibt es dort seit 2.40.0 auch.

Kann ich WordPress behalten und trotzdem statisch ausliefern?

Ja, mit Staatic oder Simply Static. WordPress bleibt dein Redaktionssystem, idealerweise nicht öffentlich erreichbar, und Besucher bekommen eine statische Kopie. Formulare, Suche und Kommentare brauchen dann Ersatz, Shops und Mitgliederbereiche funktionieren so nicht.

Was ist aus Varnish geworden?

Das Open-Source-Projekt heißt seit dem Release 9.0.0 im März 2026 Vinyl Cache. Varnish Software bietet unter dem Namen „Varnish Cache" eine eigene Distribution an, die darauf aufsetzt. Technisch ist es derselbe Reverse-Proxy-Cache mit VCL.

Fazit

Nachhaltigkeit im Web ist zu großen Teilen eine Frage der Architektur: Was nicht läuft, verbraucht nichts, muss nicht aktualisiert werden und kann nicht angegriffen werden. Die statische Seite ist die konsequenteste Antwort, ein kleiner Server wie Static Web Server die passende Ergänzung, wenn du selbst betreibst. Wo das nicht geht, holt aggressives Caching viel heraus, und für WordPress ist der statische Export ein Weg, der die Redaktion nicht umkrempelt. Die Checkliste lohnt sich in jedem Fall — für den Strombedarf, für die Hardware und für deinen Geldbeutel.

Weiterlesen

Warum diese Seite mit 11ty gebaut ist und was das an Wartung gespart hat, steht in Warum 11ty. Wie leichte Seiten auch bei den Core Web Vitals punkten, zeigt Core Web Vitals & Performance. Den technischen Unterbau für Suchmaschinen beschreibt Technical SEO: Das Fundament. Und warum der Markdown-Zwilling jeder Seite für KI-Systeme zählt, erklärt Schreiben für KI.