„Carbon-aware" klingt nach der Königsdisziplin: Ist der Strom gerade schmutzig, liefere eine leichtere Seite aus. Nur hat die Idee einen Haken, der leicht übersehen wird. Um zu wissen, wie sauber das Netz gerade ist, muss man fragen – und diese Frage ist selbst eine Anfrage, eine Datenübertragung, ein bisschen Rechenzeit. Pro Besucher gestellt, kann die Heilung teurer werden als die Krankheit. Genau hier trennt sich gut gemeinte von gut gemachter Nachhaltigkeit.
Die fünf Erfolgskriterien von Guideline 4.9 (meine Übersetzung des Originals):
Lastverschiebung nach CO₂-Intensität: Nutze CO₂-bewusstes Computing, um die Ausführung von Arbeitslasten dynamisch zu optimieren, indem Du Aufgaben so planst oder bündelst, dass sie zu Zeiten geringerer CO₂-Intensität laufen – auf Grundlage von Echtzeitdaten zur Netz-CO₂-Intensität – oder Arbeitslasten nach Möglichkeit in Regionen mit geringerer CO₂-Intensität verlagerst, unter Wahrung von Sicherheits-, Performance- und Datenstandort-Anforderungen.
Protokolleffizienz: Wähle Kommunikationsprotokolle, die Nutzerbedürfnisse, Sicherheit und Nachhaltigkeit ausbalancieren, indem sie die Effizienz verbessern und den Ressourcenverbrauch senken. Bevorzuge sichere Optionen wie HTTPS und SFTP/SSH, vermeide unsichere Altprotokolle wie HTTP und FTP und setze auf moderne Standards wie HTTP/2 oder HTTP/3 für bessere Performance und geringeren Netzwerk-Overhead. Erhalte Abwärtskompatibilität nur dort, wo sie nötig ist.
Ereignisgesteuerte Architektur: Setze ereignisgesteuerte Architekturen und Microservices ein, wenn Du Produkte mit Zustandsänderungen baust, die kein vollständiges Neuladen der Seite erfordern. Bevorzuge sie dort, wo sie eine energieeffizientere Alternative zu synchronen APIs im REST-Stil bieten – gemessen an Performance-, Energie- und Verarbeitungsfaktoren – und wähle den Ansatz, der Serverlast und Umweltwirkung reduziert und zugleich die Anforderungen erfüllt.
Effiziente Datenverarbeitung: Vermeide unnötige Datenverarbeitung. Entscheide sorgfältig, ob die Verarbeitung auf dem Client oder dem Server stattfinden sollte – auf Grundlage von Performance, Sicherheit, Nachhaltigkeitskennzahlen und Ressourcenverbrauch.
Effizienter Verarbeitungsort: Führe Datenumwandlungen, -übertragungen und -verarbeitung zwischen den Schichten einer Anwendung so nah wie möglich an der Quelle aus. Das reduziert unnötigen Serialisierungs-Overhead und vermeidet Ressourcenverschwendung.
Meine Einordnung
Diese Guideline bündelt fünf sehr unterschiedliche Fragen unter einem Dach. Für eine statische Website lösen sich die meisten davon in Luft auf – und zwar im besten Sinne. Das Kriterium „Effiziente Datenverarbeitung" verlangt, unnötige Verarbeitung zu vermeiden. Eine statische Seite treibt das auf die Spitze: Sie verarbeitet zur Laufzeit fast nichts. Keine Berechnung pro Aufruf, keine synchronen API-Runden, kein serverseitiges Rendern bei jedem Besuch. Damit erübrigen sich auch die Fragen nach ereignisgesteuerter Architektur und nach dem effizientesten Verarbeitungsort – es gibt schlicht kaum Verarbeitung, die man verteilen müsste.
Ein Kriterium trifft mich dafür direkt: die Protokolleffizienz. Und hier kann ich konkret werden. Ich erzwinge HTTPS, unverschlüsseltes HTTP gibt es nicht. Für die Übertragung zum Server brauche ich kein FTP – mein Deployment läuft über Git über SSH, also über einen sicheren, modernen Kanal. Dazu HTTP/2 für weniger Overhead pro Verbindung. Das ist kein Kunststück, sondern die Summe der korrekten, langweiligen Standardentscheidungen. Genau die will dieses Kriterium.
Bleibt das erste Kriterium, die Lastverschiebung. Und hier lohnt der genaue Blick, denn es wird oft missverstanden.
Wo ich weiter gehe
Carbon-aware im Sinne dieser Guideline meint das Verschieben von Arbeitslasten – Batch-Jobs, Berechnungen, geplante Aufgaben – in Zeiten oder Regionen mit saubererem Strom. Das ist serverseitige Planung, kein Trick pro Besucher. Für eine statische Seite ist die einzige echte Arbeitslast der Build, und den in eine grüne Stunde zu legen, ist bestenfalls ein Randgewinn.
Verlockender klingt die andere Idee: bei schmutzigem Netz automatisch Dark Mode einschalten oder Bilder weglassen. Technisch möglich – aber genau hier greift Dein berechtigter Einwand.
Wer es trotzdem tut, darf die CO₂-Intensität niemals pro Besucher abfragen, sondern höchstens serverseitig einmal je Region und Intervall, gecacht. Aber ehrlich gesagt bevorzuge ich die klarere Schlussfolgerung: Für die allermeisten Seiten schlägt „immer leicht" das „manchmal gedrosselt". Eine Seite, die ohnehin bildarm ist und per prefers-color-scheme schon dunkel kann, muss das Netz gar nicht erst befragen.
Dein erster Schritt heute
Es gibt eine query-freie Form von Energiebewusstsein, die der Browser Dir längst schenkt.
prefers-reduced-data kannst Du datenhungrige Elemente weglassen, wenn der Nutzer sparsames Laden gewählt hat. Mit prefers-color-scheme aktivierst Du den Dark Mode, wenn sein Gerät ihn wünscht. Beides entscheidet das Endgerät – ohne dass Dein Server auch nur eine einzige externe Anfrage stellt.Die nachhaltigste Datenverarbeitung ist die, die gar nicht erst stattfindet. Und die ehrlichste Form von Carbon-Awareness braucht keine zusätzliche Anfrage, um zu wissen, dass weniger fast immer besser ist.
Quellen: W3C-Fassung von Guideline 4.9 · Interpretation bei Sustainable Web Design