# Nachhaltige Websites: weniger bewegliche Teile, weniger Verbrauch

> Statische Seiten, kleine Webserver wie Static Web Server, Caching und statischer Export für WordPress: Wege, Strom, Hardware, Wartung und Kosten zu sparen.

Source: https://www.jpkc.com/db/blog/nachhaltige-websites/

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](#ein-webserver-mit-wenig-beweglichen-teilen-static-web-server) und [die Checkliste](#checkliste-sparen-egal-welcher-weg).

## 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](https://sustainablewebdesign.org/estimating-digital-emissions/) in Version 4, auf dem auch der bekannte [Website Carbon Calculator](https://www.websitecarbon.com/how-does-it-work/) 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](https://almanac.httparchive.org/en/2025/page-weight) 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](https://almanac.httparchive.org/en/2024/sustainability) 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](https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai) 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](https://www.bitkom.org/Presse/Presseinformation/Rechenzentren-Deutschland-verliert-Anschluss) 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](https://www.w3.org/TR/web-sustainability-guidelines/) 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](https://www.php.net/supported-versions.php) nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. [MySQL 8.0](https://www.mysql.com/support/eol-notice.html) bekommt seit dem 21. April 2026 keine neuen Korrekturen mehr (nur noch Oracles „Sustaining Support"), [MariaDB 10.6](https://mariadb.org/about/) seit Juli 2026 keine Community-Updates mehr. WordPress selbst [empfiehlt](https://de.wordpress.org/about/requirements/) 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](https://www.jpkc.com/db/blog/nodejs-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](https://www.jpkc.com/db/blog/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](https://static-web-server.net/)** (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](https://github.com/static-web-server/static-web-server/releases/tag/v2.44.0). 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](https://github.com/static-web-server/static-web-server/releases/tag/v3.0.0-beta.1); 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](https://github.com/static-web-server/static-web-server/releases/tag/v3.0.0-beta.1) und [Migrationsleitfaden](https://static-web-server.net/v3/migration-guide.html):

- 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](#weg-2-aggressives-caching-fuer-systeme-die-dynamisch-bleiben)).
- 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](https://github.com/static-web-server/static-web-server/releases/tag/v2.44.0) 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](https://static-web-server.net/v3/features/markdown-content-negotiation.html). 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](https://github.com/static-web-server/static-web-server/releases/tag/v2.40.0) und ist in v2 nutzbar.

Eingeschaltet wird sie mit einem Schalter:

```bash
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](https://github.com/static-web-server/static-web-server/blob/master/src/markdown.rs) 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](https://static-web-server.net/v2/features/custom-http-headers.html) 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](https://www.jpkc.com/db/blog/schreiben-fuer-ki/) und [GEO: Sichtbarkeit in KI-Antworten](https://www.jpkc.com/db/blog/was-ist-geo/).

## 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](https://de.wordpress.org/plugins/wp-super-cache/) 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](https://de.wordpress.org/plugins/cache-enabler/) und [W3 Total Cache](https://de.wordpress.org/plugins/w3-total-cache/) arbeiten ähnlich, W3 Total Cache zusätzlich mit Redis oder Memcached als Speicher. [LiteSpeed Cache](https://de.wordpress.org/plugins/litespeed-cache/) 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`](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html) 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`](https://httpd.apache.org/docs/2.4/caching.html); 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](https://vinyl-cache.org/)** umbenannt. Hintergrund ist laut der [Ankündigung von Poul-Henning Kamp](https://vinyl-cache.org/organization/20-years.html) 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"](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/) 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](https://developers.cloudflare.com/automatic-platform-optimization/), 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](https://developer.wordpress.org/advanced-administration/wordpress/cookies/). 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](https://developer.mozilla.org/de/docs/Web/HTTP/Guides/Caching) 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`](https://www.rfc-editor.org/rfc/rfc8246.html), 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](https://de.wordpress.org/plugins/staatic/)** (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](https://de.wordpress.org/plugins/simply-static/)** (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](https://simplystatic.com/pricing/) 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](https://pagefind.app/), 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](https://docs.simplystatic.com/article/67-how-to-set-up-basic-auth) 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](https://www.jpkc.com/db/cheatsheets/archives/gzip/) und [zstd](https://www.jpkc.com/db/cheatsheets/archives/zstd/).
- **Cache-Header setzen** (4.2): HTML kurz, Assets lang mit Fingerprint, siehe oben.
- **Ökostrom-Hosting prüfen** (4.1). Der [Green Web Check](https://www.thegreenwebfoundation.org/green-web-check/) der Green Web Foundation zeigt, ob dein Anbieter grünen Strom nachweist; CO₂-Kompensation [akzeptiert die Green Web Foundation seit 1. Oktober 2026](https://www.thegreenwebfoundation.org/support/are-offsets-allowed-as-evidence-for-verification/) nicht mehr als Nachweis. In Deutschland verpflichtet das [Energieeffizienzgesetz](https://www.gesetze-im-internet.de/enefg/__11.html) 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](https://www.purdue.edu/newsroom/releases/2021/Q3/dark-mode-may-not-save-your-phones-battery-life-as-much-as-you-think,-but-there-are-a-few-silver-linings.html) 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](https://www.jpkc.com/db/blog/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](https://www.websitecarbon.com/) und die Bibliothek [CO2.js](https://developers.thegreenwebfoundation.org/co2js/overview/) 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](https://www.jpkc.com/db/blog/warum-11ty/). Wie leichte Seiten auch bei den Core Web Vitals punkten, zeigt [Core Web Vitals & Performance](https://www.jpkc.com/db/blog/core-web-vitals/). Den technischen Unterbau für Suchmaschinen beschreibt [Technical SEO: Das Fundament](https://www.jpkc.com/db/blog/technical-seo/). Und warum der Markdown-Zwilling jeder Seite für KI-Systeme zählt, erklärt [Schreiben für KI](https://www.jpkc.com/db/blog/schreiben-fuer-ki/).