So können Websites CO2 abspecken

Vielen Menschen ist nicht bewusst, wie groß die Auswirkungen des IT-Sektors auf die Umwelt sind. In einem BBC-Artikel vom März 2020 heißt es: „Wenn wir die geschätzten 1,7 Milliarden Tonnen Treibhausgasemissionen, die bei der Herstellung und dem Betrieb digitaler Technologien entstehen, grob auf alle Internetnutzer weltweit aufteilen, bedeutet dies, dass jeder von uns für 414 kg Kohlendioxid pro Jahr verantwortlich ist.“ Diese Zahl ist ein ungefährer Richtwert, da die Internetnutzung jedes einzelnen sehr unterschiedlich ist, aber sie gibt einen deutlichen Hinweis auf die Auswirkungen. 

Jede Website erzeugt einen CO₂-Fußabdruck, der davon abhängt, wie die Site gestaltet, entwickelt und geplant wurde. Eine optimierte Website ist auch eine schnelle Website. Sind Nutzerinnen und Nutzer vielleicht nicht am CO₂-Fußabdruck interessiert, ist ihnen sicherlich trotzdem eine schnelle und effiziente Website wichtig. 

Was sind praktische Ansätze, um die Umweltauswirkungen einer Webseite zu verringern? Wie und was lässt sich im Entwicklungsprozess ändern, um ein nachhaltigeres Internet zu schaffen?

Ein guter Anhaltspunkt für den CO₂-Fußabdruck einer Website ist das „Gewicht“ des durchschnittlichen Seitenaufrufs und die Anzahl der Anfragen, die zum Erfüllen einer Aufgabe erforderlich sind. Um das „Gewicht“ und die Anzahl der Anfragen zu reduzieren, können Strategien wie Modularisierung, „Lazy Loading“ und statische Code-Analyse eingesetzt werden, um die Website auf Diät zu setzen.

Diät für die Website

Kleinere, häufigere Mahlzeiten (Modularisierung)

Bei einer herkömmlichen Website wird jede Seite und jede Ansicht der Website in einzelnen HTML-Dateien gespeichert. Dabei wird der Code nur dann ausgeführt und die Daten nur für den Teil heruntergeladen, den der Nutzer tatsächlich besucht. Dies spart Daten und Energie. Diese Art der Architektur wird jedoch seit einigen Jahren zunehmend durch Single-Page-Apps verdrängt, die beim ersten Aufruf deutlich mehr Code und Daten – im (am einfachsten umzusetzenden) Extremfall die komplette Website – laden und auf Benutzerinteraktionen hin die Ansicht dynamisch ganz oder teilweise austauschen. Hierbei kommt meist ein interner Routing-Mechanismus zum Einsatz, der zwischen (in der Adresszeile des Browsers sichtbaren) URLs und Zuständen der Anwendung übersetzt – so kann man im Idealfall genauso wie bei herkömmlichen Websites Links und Lesezeichen setzen, die wieder an dieselbe Stelle der App führen statt nur auf die Startseite. 

Ohne geeignete Maßnahmen besteht bei dieser Architektur die Gefahr, unnötige Daten herunterzuladen. Ein Beispiel: Greifen Sie als nicht angemeldeter Benutzer auf Ihre Lieblings-Webanwendung zu, sollten Sie die „Login“-Ansicht sehen, sobald Sie sich auf der Seite befinden. Dann wird eine sehr große main.js-Datei übertragen. Im schlimmsten Fall enthält die main.js-Datei den gesamten Code für den Rest der Anwendung, einschließlich aller Teile der Seite, die beim Aufruf dieser Website möglicherweise nicht zu sehen sind.

Hier schafft die Modularisierung Abhilfe. Das bedeutet, dass der Code einer Single-Page-Website in verschiedene Module unterteilt wird – in zusammengehörende Codeabschnitte, die von anderen Teilen des Codes referenziert werden können.

Module bieten viele Vorteile: Zum Beispiel halten sie den Umfang der App sauber und vermeiden ‚Scope Creeps‘; sie werden automatisch geladen, nachdem die Seite geparst wurde, und bevor das Document Object Model (DOM) gerendert wird – und, was für grünes Design am wichtigsten ist, sie machen Lazy Loading sehr einfach. 

Nur bei Hunger essen (Lazy Loading)

Der Begriff Lazy Loading beschreibt eine Strategie, bei der nur benötigte Ressourcen geladen werden und nicht der gesamte Websiteinhalt. Auf diese Weise wird ein großes Bild am unteren Ende der Seite erst angefordert, wenn der Benutzer nach unten scrollt, damit es sichtbar wird.

Wenn eine Website nur aus einem Routing-Modul und einem App-Modul besteht, das alle Ansichten enthält, wird die Website beim initialen Aufrufen sehr schwer und langsam. Eine intelligente Modularisierung, bei der die Website in kleinere Teile zerlegt wird, kann in Kombination mit dem Lazy Loading dazu beitragen, dass Inhalte nur dann übertragen werden, wenn sie gebraucht werden. Aber auch hier kann man es übertreiben: Wenn beispielsweise in einem Online-Shop jede Produktkachel erst im letzten Moment beim Scrollen nachgeladen wird, kann das jeden zuvor erreichten Performancegewinn zunichtemachen und erzeugt nebenbei mehr Server- und Netzwerklast als eine ausgewogene Portionierung. 

Kalorien zählen (Monitoring der Build-Größe)

Nicht nur zur Laufzeit, sondern auch auf statischer Ebene gibt es viele Techniken, um Builds so schlank wie möglich zu halten. Typischerweise besteht eine Webanwendung aus einer Sammlung verschiedener Typescript-Dateien. Um eine Website zu erstellen und den Code von Typescript in JavaScript zu kompilieren, kommt ein Web-Präprozessor zum Einsatz: ein Dienstprogramm, das Frontend-Builds kompiliert und andere Aufgaben übernimmt, wie beispielsweise Webpack.

Präprozessoren wie Webpack verhindern die Fertigstellung eines Builds, wenn die Dateien größer als ein variabler Schwellenwert sind. Sowohl für das Haupt-Boot-Skript als auch für die einzelnen CSS-Blöcke lassen sich Grenzwerte festlegen, die nach der Kompilierung eine bestimmte Byte-Größe nicht überschreiten dürfen. Jeder Build, der größer ist als der festgelegte Schwellenwert, schlägt mit einer Warnung fehl.

Ist ein Build verdächtig groß, kann eine Webdesignerin oder ein Webdesigner (z. B. mit dem Webpack-Node-Inspector) prüfen und das Modul oder den Teil der Website identifizieren, das am meisten dazu beiträgt, inklusive aller Abhängigkeiten. Mit diesen Informationen lassen sich dann die fraglichen Teile der Website optimieren.

Versteckte Kalorien vermeiden (toter Code)

Es ist möglich, dass ein Build Dutzende von Konfigurationsdateien und Code für bestimmte Szenarien enthält, die nie benötigt werden. Dieser nicht ausgeführte Code ist sogenannter toter Code. Die bloße Existenz beansprucht jedoch Speicherplatz und verbraucht Energie.

Toter Code lässt sich in selbstgeschriebenen Quellen finden. Noch häufiger stammt er aus externen Bibliotheken, die als Abhängigkeiten eingebunden werden. Über eine Technik namens “Tree Shaking” lässt sich der Code statisch analysieren und die Teile markieren, die von anderen Teilen des Codes nicht referenziert werden. 

Moderne Präprozessoren führen ein “Tree Shaking” durch, um toten Code zu identifizieren und ihn automatisch vom Build auszuschließen. So ist es möglich, nur die Teile des Codes zu verwenden, die zur Laufzeit wirklich benötigt werden – allerdings nur, wenn der Code modularisiert ist.

Convenience-Produkte richtig auswählen (Code von anderen Leuten) 

Um die Entwicklungsprozesse zu beschleunigen, werden häufig externe Bibliotheken verwendet: Sie bieten gebrauchsfertige Hilfsprogramme, die von anderen Leuten programmiert wurden. Einige dieser Bibliotheken können jedoch unerwartet umfangreich sein und den eigenen Code belasten. 

Ein beliebtes Beispiel ist Moment.js. Dabei handelt es sich um eine Legacy-Bibliothek, die bei der Datumsformatierung für mehrere Standorte oder Zeitzonen sehr vielseitig ist. Aus diesem Grund wird sie von vielen Entwicklern verwendet. Leider ist sie auch recht umfangreich. Vor allem ist sie weder kompatibel mit der typischen Typescript-Welt noch ist sie modular. So können auch die besten Präprozessoren das Gewicht, das es dem Code hinzufügt, nicht durch „Tree Shaking“ reduzieren.

Das Auge isst mit (Look and Feel)

Auch beim Design lässt sich optimieren: Zu vermeiden ist ein übermäßiger Einsatz von Bild- und Videomaterial – wie beispielsweise das klassische Full-HD-Stock-Video, das bei jedem Aufruf der Startseite abgespielt wird. Auch ein massenhafter Einsatz von Animationsgimmicks wie Parallax Scrolling wirkt sich negativ aus. Je nach Implementierung können solche Animationen die CPU- und GPU-Last beim Client massiv erhöhen.

Ein Tipp zum Schluss: Websites sollten zusätzlich auf einem 5 bis 10 Jahre alten Rechner getestet werden – nicht nur die Startseite, sondern die gesamte Funktionalität. Wenn es beim Scrollen stark ruckelt und/oder die Lüfter auf Maximaldrehzahl springen, ist das ein sehr gutes Indiz für Optimierungspotential.

Die Bilanz

Wie viel Energie eine Website verbraucht und wie groß der daraus resultierende CO₂-Fußabdruck ist, hängt unter anderem von den zu übertragenden Daten ab, um dem Nutzer die gewünschten Inhalte anzuzeigen. Als goldene Regel für das Erstellen leichterer und umweltfreundlicherer Websites dient das YAGNI-Mantra: You Ain’t Gonna Need It. (übersetzt: Du wirst es nicht brauchen.)

Autoren: Roberta Haseleu, Practice Lead Green Technology bei Reply, Fiorenza Oppici von Live Reply sowie Lars Trebing von Vanilla Reply – beides Practice-Mitglieder Green Technology