Jede Seite, die Du hier liest, wurde genau einmal berechnet. Nicht bei Deinem Aufruf, sondern vorher, auf meinem Rechner. Was der Server ausliefert, ist eine fertige Datei. Bei einem klassischen Redaktionssystem läuft dieselbe Rechnung bei jedem einzelnen Besuch neu: PHP startet, Datenbankabfragen laufen, Templates werden zusammengesetzt, und am Ende steht dasselbe Ergebnis wie beim Aufruf davor. Tausend Besucher, tausend identische Berechnungen.
Die fünf Erfolgskriterien von Guideline 3.14
Angemessene Umsetzung: Wähle Umsetzungswege, die Aufwand, Performance und Umweltwirkung ausbalancieren. Einfachere Lösungen können Komplexität und Laufzeitlast senken, erfordern aber mehr menschliche Arbeit, während vorgefertigte Werkzeuge Bauzeit und Entwicklungsaufwand verringern, dafür aber den laufenden Ressourcenverbrauch erhöhen. Bewerte die Umweltkosten von Build-Prozessen, Asset-Transformationen und externen Abhängigkeiten und stelle sicher, dass jede zusätzliche Schicht den Nutzern echten Mehrwert liefert.
Optimierte Vorgehensweise: Nutze den leistungsfähigsten Ansatz für Deinen Anwendungsfall. Meistens liefert selbst geschriebener Code die beste Performance, aber wo eine gut gepflegte bestehende Lösung verfügbar ist, kann sie besser optimiert sein als das, was Du selbst herstellen kannst. Bevorzuge native Komponenten und Dateisysteme gegenüber WYSIWYG-Editoren, visuellen Seitenbaukästen oder schweren Frameworks. Achte auf Performance, Wartungsaufwand und Umweltwirkung von Drittanbieterlösungen.
Statisch vor dynamisch: Liefere statische Inhalte anstelle dynamischer Inhalte, wo immer das möglich ist. Wenn Code erzeugt werden muss, bevorzuge effiziente Werkzeuge wie Static Site Generatoren. Beachte, dass dynamische, CMS-getriebene Inhalte typischerweise mehr serverseitige Verarbeitung erfordern und auf umfangreichere Bibliotheken angewiesen sind als statische Ansätze.
Erweiterungen und Plugins: Überprüfe Plugins, Erweiterungen und Themes regelmäßig darauf, ob sie mit der Plattform und den übrigen Komponenten kompatibel, effizient und barrierefrei bleiben.
Interface-Komponenten: Setze Benutzeroberflächen-Komponenten ein, die leichtgewichtig, zweckgebunden und effizient sind, und vermeide unnötige Komplexität, die Ressourcenverbrauch, Umweltwirkung oder Wartungsaufwand erhöht.
Meine Einordnung
Das dritte Kriterium ist das folgenreichste, und es steht bei mir hinter der ganzen Website. Diese Seite läuft mit Hugo, einem Static Site Generator. Der Server muss nichts berechnen, keine Datenbank befragen, keine Interpreterumgebung starten. Er reicht eine Datei weiter, mehr nicht. Das spart nicht nur Energie im Rechenzentrum, es beseitigt auch eine ganze Klasse von Sicherheitslücken und macht die Seite unter Last praktisch unerschütterlich.
JavaScript brauche ich dabei an genau zwei Stellen: für die Suche und für den Podcast-Player. Beides lädt ausschließlich dort, wo es zum Einsatz kommt. Wer einen Artikel liest, lädt keine Zeile davon. Das ist die praktische Umsetzung des fünften Kriteriums: zweckgebundene Komponenten statt eines Grundgerüsts, das jede Seite mitschleppt, weil irgendeine Seite es braucht.
Zur Ehrlichkeit gehört aber das erste Kriterium, und es benennt den Preis offen: Einfachere Lösungen brauchen mehr menschliche Arbeit. Das stimmt. Ein Seitenbaukasten ist in einer Stunde eingerichtet, ein Hugo-Setup kostet mich ein Wochenende und setzt voraus, dass ich mit Templates und der Kommandozeile umgehen kann. Wer das nicht will oder nicht kann, trifft mit einem gepflegten System und aktiviertem Seiten-Cache eine völlig vertretbare Entscheidung. Die Guideline verlangt keine Askese, sondern eine bewusste Abwägung.
Das erste Kriterium hat außerdem einen Zusatz bekommen, der mir als Verfechter statischer Seiten unbequem sein müsste: Auch die Umweltkosten von Build-Prozessen, Asset-Transformationen und externen Abhängigkeiten sollen bewertet werden, und jede zusätzliche Schicht soll den Nutzern echten Mehrwert bringen. Das trifft mich direkt. Vorberechnung verschiebt Arbeit, sie löst sie nicht auf. Jeder Build erzeugt die komplette Website neu, wandelt Bilder um, erstellt den Suchindex. Der Unterschied zum dynamischen System bleibt trotzdem groß, weil dieser Aufwand pro Änderung anfällt und nicht pro Aufruf: ein Build für Zehntausende Abrufe statt Zehntausender Berechnungen für dasselbe Ergebnis. Wer allerdings bei jedem Kommafehler die gesamte Seite neu baut und dabei jedes Bild erneut konvertiert, hat einen guten Teil des Vorteils verspielt.
Wo ich weiter gehe
Diese Abwägung wird nur meist falsch gerechnet. Der Aufwand beim Bauen fällt einmal an und ist sofort spürbar. Der Ressourcenverbrauch beim Betrieb fällt bei jedem einzelnen Aufruf an und ist unsichtbar. Deshalb gewinnt in Projektbesprechungen fast immer die Bequemlichkeit: Sie hat einen konkreten Fürsprecher im Raum, der Betrieb hat keinen.
Genau da setze ich an. Die entscheidende Frage lautet nicht, welche Lösung am schnellsten fertig ist, sondern wer die Rechnung dafür bezahlt. Und das sind bei einer Website mit ein wenig Reichweite Millionen von Aufrufen, jeder mit seinem kleinen Anteil an Serverzeit, Datenvolumen und Akkuverbrauch auf fremden Geräten. Zeitersparnis beim Bauen ist eine einmalige Gutschrift. Laufzeitkosten sind ein Abonnement ohne Kündigungsfrist.
Dein erster Schritt heute
Du musst dafür nicht Dein System wechseln. Fang bei der Frage an, ob überhaupt gerechnet wird.
Und der zweite Handgriff, unabhängig vom System: Geh Deine Plugins und Erweiterungen durch und wirf alles raus, was Du nicht benennen kannst. Jede Erweiterung, die niemand vermisst, war ihre Laufzeitkosten nie wert.
Die sparsamste Berechnung ist die, die längst stattgefunden hat, bevor der erste Besucher klickt.
Quelle: W3C-Fassung von Guideline 3.14