Kriterien & Optimierungs-Schritte für eine klimafreundliche Website

Wie werden Websites auf Klimafreundlichkeit optimiert? Mit unseren Kriterien für klimafreundliche Websites seid ihr auf der sicheren Seite. Wir haben euch zusammengestellt, welche Maßnahmen sinnvoll sind und welche Schritte zur Optimierung ihr angehen solltet.

Manche Punkte sind von Website-Betreiber:innen mit wenig Vorwissen schnell und einfach umsetzbar. Andere bedürfen einer versierteren Hand bei Analyse und Umsetzung.

Ihr könnt alle Aufgaben für Website-Betreibende auch als praktische Liste im PDF-Format downloaden und euch direkt an die Arbeit machen!

Inhaltsverzeichnis

• Bilder, Videos, Animationen
  • Autoplay von Videos
  • Lazy Load für Bilder
  • Verwendung moderner Bildformate wie WebP oder AVIF
  • Responsive Bildgrößen
  • Webgerechte Kodierung der verwendeten Bilder
  • Effiziente Animationen
• Skripte
  • Gesamtgröße aller geladener Skripte
  • Ungenutztes JavaScript
  • Laufzeiten JavaScript
  • Effizienter Einsatz von Modulen in JavaScript Paketen
  • Legacy JavaScript nur an veraltete Browser ausliefern
  • Minimierung der JavaScript Dateien
• CSS
  • Umfang der CSS Dateien
  • Minimierung der CSS Dateien
• Server
  • Energiemix der verwendeten Server
  • Caching auf dem Server einsetzen
• Datenübertragung
  • Text-Kompression am Server
  • Verwendung von HTTP/2
  • Verwendung von HTTPS
  • Anzahl der Netzwerkanfragen
• Weitere Punkte
  • Browser-Cache
  • Gesamtgröße der Website
  • Komplexität und Umfang der Seite über die DOM-Größe
  • Umfang des Hauptablaufs des Rendering-Moduls
  • Gesamtgröße aller geladenen Schriften
  • Redirects
  • Ladezeitpunkt von Drittanbieter-Code

Bilder, Videos, Animationen

Autoplay von Videos

Das solltet ihr vermeiden:

Videos starten automatisch.

Grund:

Videos, egal ob im Hintergrund laufend oder als Video eingebettet oder in einem eigenen Fenster angezeigt, sind meistens die mit Abstand größten Dateien, die auf einer Website eingesetzt werden. Diese teils riesigen Dateien verbrauchen den größten Teil der Energie, wenn sie auf einer Seite eingesetzt werden. Diese automatisch, ohne Zustimmung oder klar darauf ausgerichtete Interaktion des Users abzuspielen, ist nicht nur klimaschädlich, sondern auch rücksichtslos gegenüber Menschen mit schmalen Datentarifen.

Maßnahme:

Kein Video laden oder automatisch starten, wenn die Nutzerin dies nicht klar auslöst. Kurz gesagt: Kein Autoplay bei Videos einsetzen. Ebenso kein automatisches Abspielen des nächsten Videos beim Einbetten eines Videos von einer Video-Plattform.

Aufgaben:

bisherige Autoplay-Videos entfernen oder ersetzen

Videos im Hintergrund durch Grafiken oder einfach zu berechnende Animationen ersetzen

Lazy Load für Bilder

Das solltet ihr vermeiden:

Sämtliche Bilder auf der Website werden direkt bei Seitenaufruf geladen, auch wenn manche dieser Inhalte weit unten auf der Seite sind und erst bei Scroll geladen werden könnten.

Grund:

Durch das Menü an sich, aber auch durch Call to Actions und andere Links im oberen Teil der Website kommt es häufig dazu, dass eine Seite nicht bis zum Ende gescrollt wird, sondern schon vorher die Reise zu anderen Teilen der Website weitergeht. Bilder im unteren Teil wurden dann umsonst übertragen und geladen.

Maßnahme:

Verzögertes Laden von Bildern, die nicht direkt sichtbar sind (lazy load). Durch das sogenannte lazy loading, das von modernen Browsern auch ohne spezielles Skript genutzt werden kann, werden Bilder immer erst bei Bedarf geladen, also kurz bevor sie in den sichtbaren Bereich gescrollt werden. Das ist für viele Seiten ein großer Hebel für Einsparungen.

Aufgaben:

Lazy Load über sauberen Code oder zur Not via Plugin einsetzen

Verwendung moderner Bildformate wie WebP oder AVIF

Das solltet ihr vermeiden:

Auf der Website ausschließlich auf alte Bildformate wie JPG setzen. Über solche veraltete Bildformate wird die Datenmenge erhöht.

Grund:

Die meisten aktuellen Browser können mit modernen Bildformaten wie WebP oder AVIF umgehen. Diese sparen bei gleichbleibender Qualität zwischen 20 und 35 Prozent an Datenumfang ein.

Maßnahme:

Über Anpassungen der Website, des Servers oder über die Nutzung von externen, darauf spezialisierten Diensten kann eine Website in die Lage versetzt werden, die vorhandenen Bilder zusätzlich zur Auslieferung in den aktuell verwendeten Formaten auch in modernen Bildformaten auszuliefern.

Mehr Infos:

• Webp ganz einfach mit Plugin in Wordpress verwenden

Aufgaben:

Möglichkeiten von Server, Website oder Plugin ausnutzen, um WebP oder AVIF auszuliefern

Responsive Bildgrößen

Das solltet ihr vermeiden: Bilder deutlich größer laden, als sie für das gerade verwendete Endgerät erforderlich sind.

Grund:

Webseiten sollen Bilder in angemessener Größe bereitstellen, gerade auch, wenn es sich um einen Seitenaufruf über ein Smartphone handelt. Dies spart Mobilfunkdaten, verkürzt die Ladezeit und spart damit in Summe Energie ein.

Maßnahme:

Idealerweise sollte die Website stets Bilder bereitstellen, die nur so groß sind, wie die Version, die auf dem Bildschirm des Endgeräts gerendert wird. Ein guter Ansatz ist hier die Verwendung eines <picture> Elements pro Bild - oder zumindest die Verwendung des srcset Attributs im <img>. Dadurch wird das Bild in mehreren Größen zur Verfügung gestellt - und der Browser lädt das kleinstmögliche, mit dem eine perfekte Darstellung bei der aktuellen Bildschirmbreite möglich ist.

Mehr Infos:

• Responsive Images - Optimiert für Groß und Klein
• How to fix the properly size images warning in WordPress (englischsprachig)

Aufgaben:

Bilder responsive einbinden

Webgerechte Kodierung der verwendeten Bilder

Das solltet ihr vermeiden: Bilder mit einer Kodierung bzw. auch Kompressionsrate auf Eurer Website verwenden, die nicht für eine Verwendung im Internet optimiert sind.

Grund:

Bilder müssen für eine Darstellung auf Bildschirmen bei Weitem nicht so gut aufgelöst sein, wie zum Beispiel für den Druck. Dies gilt nicht nur für die Dimension eines Bildes, sondern eben auch für die Kodierung, also unter anderem die Kompression der Bilder.

Maßnahme:

Generell sollten Bilder für das Internet bei JPG maximal mit Qualitätslevel 85 komprimiert werden - eher im Bereich von 60 bis 70. Beim webgerechten Komprimieren können Online-Tools wie squoosh.app, Mac-Applicationen wie ImageOptim.com oder Windows-Applicationen wie riot-optimizer.com helfen. Weitergehende Maßnahmen wären zum Beispiel der Einsatz eines spezialisierten CDNs, das vollautomatisch Bildoptimierungen übernimmt, oder der Einsatz von modernen Bildformaten wie WebP. Um die Auswirkungen von Bildern generell zu minimieren hilft zum Beispiel lazy loading oder eine sinnvolle Begrenzung der Bildmaße.

Aufgaben:

JPG-Bilder vor dem Hochladen optimieren mit Qualitätslevel 60-70

Einsatz moderner Bildformate (siehe oben)

Bei sehr umfangreichen Seiten oder Seiten mit Zumindest 60.000 Besucher:innen pro Monat: Einsatz eines CDN mit integrierter Bildoptimierung

sinnvolle Begrenzung von Bildgrößen (Dimensionen) und der Anzahl von Bildern

Effiziente Animationen

Das solltet ihr vermeiden: Sehr aufwändige Animationen, die zu viel Rechenkapazität in Anspruch nehmen.

Grund:

Bestimmte Animationen sind aufwändig zu berechnen und sollten bedacht eingesetzt werden.

Maßnahme:

Im besten Fall auf aufwendige Animationen komplett verzichten. Falls das nicht geht, wenigstens über die Verwendung eines Videos statt vom Browser zu berechnender Animationen den Energieverbrauch reduzieren – so bleibt der Inhalt erhalten aber verbraucht weniger Leistung.

Aufgaben:

Aufwändige Animationen entfernen

zur Not Video der Animation erstellen & einsetzen

Skripte

Gesamtgröße aller geladener Skripte

Das solltet ihr vermeiden: Umfangreicher Einsatz von Javascript.

Grund:

Da Javascript bei der Ausführung am Endgerät mehr Energie verbraucht als die meisten anderen Daten einer Website, sollte hier besonders kritisch hingesehen werden. Wir halten ein Maximum von 300 KB beim Laden der Seite für erstrebenswert. Ideal wäre unter 50 KB.

Maßnahme:

Eine Reduktion von JavaScript hilft dem Klima doppelt. Eine Analyse der Seite kann zeigen, welche Skripte tatsächlich benötigt werden und ob nicht manche Funktionen auch anders verwirklicht werden können. Auch kann geprüft werden, ob nicht manche der Javascript Funktionen erst später geladen werden, wenn diese benötigt werden, bzw. sogar erst, wenn diese durch eine bestimmte Handlung des Users erst angefordert wird. Anregungen hierzu kann die Idee des progressive enhancements geben. Noch radikaler kann in manchen Fällen natürlich insgesamt die Frage gestellt werden, ob ein System, das sehr stark auf Javascript im Frontend setzt, die richtige Wahl für die eigene Website darstellt, gerade wenn diese tendenziell wenige Besucher:innen hat - und von diesen sehr wenige regelmäßig mit der Website arbeiten.

Aufgaben:

Analyse: Welche Skripte sind notwendig und welche Funktionen können anders verwirklicht werden?

Wenn zu viele Skripte notwendig sind für einfache Funktionen: System wechseln.

Notwendige Skripte erst laden, wenn sie gebraucht werden.

Notwendige Skripte erst laden, wenn sie vom User aufgerufen werden.

Größe der Skripte beim Laden auf max. 300 KB reduzieren.

Ungenutztes JavaScript

Das solltet ihr vermeiden: Mehr JavaScript laden als benötigt wird.

Grund:

Unnötig geladene Teile des Codes sind unnötig übertragene und verarbeitete Daten, die dabei Energie verbrauchen - ohne Notwendigkeit.

Maßnahme:

Eine Prüfung, welche Teile des JavaScripts überflüssig sind, kann Auskunft darüber geben, welche Teile der Website (Plugins, externe Bibliotheken, Multi-Purpose-Themes, ...) hier viel unnötiges JavaScript ausliefern. Dies kann dann über diverse technische Maßnahmen reduziert werden.

Mehr Infos:

Wie man unbenutzte JavaScript in WordPress entfernt (englischsprachig)

Aufgaben:

Analyse: Welches JavaScript ist überflüssig?

Ersetzen der Dateien

Laufzeiten JavaScript

Das solltet ihr vermeiden: Lang ausführendes JavaScripts.

Grund:

Die Dauer der Ausführung des gesamten JavaScripts beeinflusst nicht nur die Zeit, die eine Websitebesucher:in auf die Website wartet - und damit indirekt auch die Position der Seite in der Suchmaschine - sondern verbraucht auch einfach mehr Energie am Endgerät.

Maßnahme:

Durch technische Maßnahmen kann die Zeit für das Parsen, Kompilieren und Ausführen von JavaScript reduziert werden:

• Kleinere payloads

• reduzierter Code

• Aufteilung von Code in kleinere Pakete (code splitting)

• nur das Übertragen und Ausführen der notwendigen Teile

• Caching

können hier Ansätze sein, die Entwickler:innen Ihrer Website anwenden können.

Aufgaben:

Payloads reduzieren

Code reduzieren

Code Splitting

Check: auf notwendige Teile reduziert?

Caching einsetzen

Effizienter Einsatz von Modulen in JavaScript Paketen

Das solltet ihr vermeiden: Mehrfach vorhandene Module in JavaScript Paketen

Grund:

Je größer eine Datei, umso höher der Aufwand bei der Übertragung und der Verarbeitung - und damit eben auch umso höher der Energieverbrauch.

Maßnahme:

Dies ist eine sehr technische Maßnahme, die von den Entwickler*innen der Website analysiert und gelöst werden muss. Wenn große Module in JavaScript Paketen mehrfach verwendet werden, sollte dies effizienter gestaltet werden.

Aufgaben:

Analyse, welche Module optimiert werden können

Umsetzung der Analyseergebnisse

Legacy JavaScript nur an veraltete Browser ausliefern

Das solltet ihr vermeiden: Javascript, das speziell für veraltete Browser gedacht ist, auch an moderne Browser ausliefern.

Grund:

Über Techniken wie polyfills und transforms wird oft dafür gesorgt, dass veraltete Browser Javascript-Code ausführen können, der aktuelle Javascript Features verwendet. Dieser dadurch zusätzlich entstehende Code kann die Größe der Javasript-Dateien schnell verdoppeln.

Maßnahme:

95 Prozent aller verwendeten Browser verstehen modernes Javascript. Mit dem Aufwand des oben beschriebenen Umformatierens modernen Codes in eine legacy Variante kann die Abdeckung nur auf etwa 98 Prozent erhöht werden - während sich aber die Dateigröße und damit der Energieaufwand zur Übertragung und Verarbeitung deutlich erhöht. Unter diesen Gesichtspunkten bleibt als Empfehlung, Javascript ausschließlich in der modernen Variante auszuliefern. Insbesondere für Javascript Funktionen, die nicht absolut notwendig sind für die Nutzung der Website.

Aufgaben:

JavaScript, das für veraltete Browser gedacht ist, nicht an moderne Browser ausliefern

Minimierung der JavaScript Dateien

Das solltet ihr vermeiden: Nicht-minimierte oder zu wenig minimierte JavaScript Dateien einsetzen.

Grund:

JavaScript Dateien können für die Verwendung auf Produktivseiten minimiert werden (minify). Dies bedeutet, dass über mehrere Wege der Umfang der Dateien reduziert wird.

Maßnahme:

Eigene Javascript-Dateien sollten bei der Erstellung der Website (build) minimiert werden oder beim Einsatz eines CMS-Systems zur Not durch entsprechende Plugins. Wenn Javascript Dateien von Drittparteien eingebunden werden, sollte stets auf die minimierten Versionen zurückgegriffen werden, die meistens angeboten werden.

Aufgaben:

Eigene Dateien minimieren (minify).

Bei CMS zur Not Plugin dafür einsetzen.

Drittanbieter-Dateien durch minimierte Version ersetzen.

CSS

Umfang der CSS Dateien

Das solltet ihr vermeiden: Mehr CSS laden, als benötigt wird.

Grund:

Unnötig geladene Teile des Codes sind unnötig übertragene und verarbeitete Daten, die dabei Energie verbrauchen - ohne Notwendigkeit.

Maßnahme:

Eine Prüfung, welche Teile des CSS überflüssig sind, kann Auskunft darüber geben, welche Teile der Website (Plugins, externe Bibliotheken, Multi-Purpose-Themes, ...) hier viel unnötiges CSS ausliefern. Dies kann dann über diverse technische Maßnahmen reduziert werden.

Mehr Infos:

Wie man unbenutzte CSS in WordPress entfernt

Aufgaben:

Analyse: Welches CSS ist überflüssig?

ggf. Plugins konfigurieren

Minimierung der CSS Dateien

Das solltet ihr vermeiden: Nicht-minimierte oder zu wenig minimierte CSS Dateien einsetzen.

Grund:

CSS Dateien können für die Verwendung auf Produktivseiten minimiert werden (minify). Dies bedeutet, dass über mehrere Wege der Umfang der Dateien reduziert wird.

Maßnahme:

Eigene CSS Dateien sollten bei der Erstellung der Website (build) minimiert werden oder beim Einsatz eines CMS-Systems zur Not durch entsprechende Plugins. Wenn CSS Dateien von Drittparteien eingebunden werden, sollte stets auf die minimierten Versionen zurückgegriffen werden, die meistens angeboten werden.

Aufgaben:

Eigene Dateien minimieren (minify).

Bei CMS zur Not Plugin dafür einsetzen.

Drittanbieter-Dateien durch minimierte Version ersetzen.

Server

Energiemix der verwendeten Server

Das solltet ihr vermeiden: Server verwenden, die nicht mit grünem Strom laufen. Auch bei den Servern, von denen Drittanbieter-Code wie Euer Analyse-Tool, Tracking, CDN, eingebettete Inhalte, etc.

Grund:

Die Erzeugung des Stroms zum Betrieb der Server ist ein sehr relevanter Faktor, wie klimabewusst Webseiten betrieben werden können. Da bestimmte Formen der Stromerzeugung – grau – je nach Berechnung ein Vielfaches der CO₂e (CO₂ Äquivalente) Erzeugung bedeuten, wird selbst eine gut optimierte Seite deutlich weniger ökologischer als möglich.

Maßnahme:

Erster Schritt: Beim aktuellen Hoster nachfragen, mit welchem Energiemix dort die Server betrieben werden.

Der zweite Schritt wäre im Fall, dass der aktuelle Hoster tatsächlich graue Energiequellen verwendet, die Website zu einem Hoster umzuziehen, der einen grünen Energiemix nutzt.

Aufgaben:

Beim aktuellen Hoster nachfragen, mit welchem Energiemix dort die Server betrieben werden.

Falls graue Energiequellen genutzt werden: Website zu anderem Hoster umziehen.

Caching auf dem Server einsetzen

Das solltet ihr vermeiden: Wegen fehlendem Caching erzeugt jeder Seitenaufruf Berechnungsaufwand für das Erstellen der Seite.

Grund:

Wenn eine Website aufgerufen wird, die vom verwendeten System (wie WordPress, Typo3 oder Drupal) dynamisch erzeugt wird, muss einiges an Arbeit verrichtet werden wie z.B. etliche Datenbankabfragen und das Ausführen von Funktionen. Solche Arbeit verbraucht Strom und vergrößert damit den ökologischen Fußabdruck einer Website.

Maßnahme:

Um diese aufwändigen Arbeiten möglichst selten auszuführen, empfiehlt sich ein Page Cache am Server. Dieser speichert beim ersten Aufrufen einer bestimmten Seite die Ergebnisse der dynamischen Erstellung der Seite und liefert dann für einige Zeit beim erneuten Aufrufen einfach direkt die zwischengespeicherte Seite sofort aus. In Fällen, in denen ein Zwischenspeichern der gesamten Seite nicht geht, gibt es unter anderem auch spezielle Caches für Datenbankabfragen, Ergebnisse von Funktionen oder Teilbereichen der Seite.

Mehr Infos:

WordPress Cache: Gute Übersicht mit Erklärungen, welche Caches der Hoster Cloudways einsetzt (englischsprachig, Link führt zum Abschnitt "Server-Level Caching")

Aufgaben:

Page-Cache einsetzen

ggf. weitere Cache einsetzen

Datenübertragung

Text-Kompression am Server

Das solltet ihr vermeiden: Textbasierte Dateien vom Server unkomprimiert an den Browser übertragen.

Grund:

Textkompression alleine mit dem absolut etablierten GZIP spart zum Beispiel bei CSS und JS Dateien schnell 75 bis 85 Prozent an Datenmenge ein, die übertragen werden muss. Mit dem moderneren Brotli wird regelmäßig noch mehr eingespart.

Maßnahme:

In der Webserver-Konfiguration muss die Kompression mit zumindest GZIP konfiguriert sein. Besser wäre hier, GZIP als Fallback zu verwenden und zusätzlich das deutlich bessere Brotli zu verwenden. Der Webhoster, bei dem die Website liegt, sollte hier sehr einfach helfen können.

Aufgaben:

Einsatz von GZIP und idealerweise Brotli am Server konfigurieren

Verwendung von HTTP/2

Das solltet ihr vermeiden: Keine Verwendung von HTTP/2

Grund:

Für die Übertragung von Daten vom Server zum Browser gibt es ein Übertragungsprotokoll: HTTP. Dieses gibt es in unterschiedlichen Versionen und HTTP/2 geht deutlich effizienter mit den Netzwerkressourcen um. Das ist natürlich ökologischer.

Maßnahme:

Es handelt sich hier lediglich um eine Server-Einstellung, die bei jedem halbwegs aktuellen Server sehr einfach eingestellt werden kann. Dies ist eine Aufgabe für den Systemadministrator oder Hoster. Sollte bereits HTTP/3 zur Verfügung stehen, umso besser!

Aufgaben:

Server auf HTTP/2 einstellen.

Falls bereits unterstützt, gerne auch schon HTTP/3 einsetzen.

Verwendung von HTTPS

Das solltet ihr vermeiden: Teile der Website über HTTP laden.

Grund:

HTTPS ist nicht nur der sichere Weg der Datenübertragung, sondern auch effizienter als HTTP und sollte daher bevorzugt werden.

Maßnahme:

Es sollte überprüft werden, welche Assets über HTTP geladen werden und diese auf HTTPS umstellen. Wenn ein Asset nicht über HTTPS zugänglich ist, sollte es entfernt oder ersetzt werden.

Aufgaben:

prüfen, ob Assets über HTTP geladen werden

diese entfernen oder ersetzen

Anzahl der Netzwerkanfragen

Das solltet ihr vermeiden: Zu viele Netzwerkanfragen beim Aufbau der Website.

Grund:

Für die Seite selbst und für jedes Element, das geladen werden muss, wie Bilder, Schriften, Skripte, CSS-Dateien und so weiter, fragt der Browser bei einem Server an. Dieser Vorgang ist ein gewisser Aufwand, zusätzlich zu dem, was danach übertragen wird. Wir halten es für erstrebenswert beim Seitenaufbau unter 50 solcher Netzwerkanfragen zu bleiben.

Maßnahme:

Im Kern gibt es zwei Möglichkeiten, die Anzahl der Netzwerkanfragen zu reduzieren, sowie eine, um die Auswirkungen zu reduzieren:

Die Methode, die Auswirkungen zu reduzieren ist HTTP Caching, damit nicht jede Anfrage bei jedem Seitenbesuch tatsächlich neu ausgeführt werden muss.

Die beiden Methoden zur Reduktion der Anfragen:

• Zusammenlegen von Dateien, wo dies sinnvoll möglich ist (also mehrere Dateien in einer einzelnen zusammenzuführen)

• Reduzieren von Inhalten – also das Weglassen von bestimmten Bildern, Schriftarten, Skripten und so weiter

Aufgaben:

HTTP Caching einsetzen

Dateien zusammenlegen

Bilder reduzieren

Schriftarten reduzieren

Skripte reduzieren

Weitere Punkte

Browser-Cache

Das solltet ihr vermeiden: Der Browser-Cache für statische Dateien wird mit geringer Laufzeit verwendet.

Grund:

Wenn auf einer Website Anweisungen für den Browser bestehen, statische Dateien in seinem Zwischenspeicher aufzubewahren, ist das großartig, weil diese Dateien eben nicht bei jedem Seitenaufruf neu geladen werden müssen. Wenn die Anweisung aber nur für einen kurzen Zeitraum gilt, ist die positive Auswirkung der Maßnahme deutlich geringer, als es möglich wäre.

Maßnahme:

Statische Dateien sollten für zumindest ein Jahr in den Cache gelegt werden. Sie können ja jederzeit über eine Änderung des Namens erneuert werden, was eine viel verlässlichere Variante eines Cache-Managements darstellt. Anstatt einer sehr kurzen cache duration sollte in Fällen, in denen dies Sinn ergibt, auf eine no-cache policy gesetzt werden.

Aufgaben:

Statische Dateien für mindestens ein Jahr in den Cache legen.

Gesamtgröße der Website

Das solltet ihr vermeiden: Beim erstmaligen Aufruf der Website sehr viele Daten laden.

Grund:

Da der Umfang der geladenen Daten in direktem Zusammenhang mit dem ökologischen Fußabdruck einer Website steht, sollte die Datenmenge natürlich als wichtiger Hebel gesehen werden. Wir halten ein Maximum von 1.500 KB beim Laden der Seite für erstrebenswert.

Maßnahme:

Eine Analyse der Bestandteile der Website kann Aufschluss über Bereiche geben, die besonders groß sind. Ist dies zum Beispiel der Bereich Bilder, kann die Anzahl und die Größe der Bilder reduziert werden, die beim Aufrufen der Seite sofort geladen werden. Auch moderne Bildformate, starkes Komprimieren und Minimieren von Dateien und während der Übertragung so wie starkes Caching kann die Auswirkungen großer Seiten zumindest reduzieren. Auch Maßnahmen wie z.B. weniger Vorschau-Artikel auf Übersichtsseiten oder ein lazy loading des Kommentarbereichs auf Blog-Seiten kann hier helfen.

Aufgaben:

Bilder reduzieren, die direkt beim Aufrufen der Seite geladen werden. Diese in modernen Formaten einbinden.

Caching einsetzen.

Lazy Loading einsetzen.

Gesamtgröße der Website auf unter 1.500 KB reduzieren.

Komplexität und Umfang der Seite über die DOM-Größe

Das solltet ihr vermeiden: Ein sehr umfangreiches DOM ist zu vermeiden.

Grund:

Das DOM (Document Object Model) ist vereinfacht gesagt die technische Struktur der Website. Bestehend aus allen Objekten, die der Browser berechnen und erzeugen muss, wenn er die Seite lädt. Je umfangreicher dieser ist, umso aufwändiger ist dies.

Maßnahme:

• Reduktion der Inhalte auf der Seite

• Reduktion der Komplexität des Codes

• Verzögertes Laden von Teilen der Seite, zu denen erst gescrollt werden muss

Mehr Infos:
Reduzieren der DOM-Größe in WordPress

Aufgaben:

Inhalte reduzieren, wo es geht und sinnvoll ist

Komplexität des Codes drosseln

Umfang des Hauptablaufs des Rendering-Moduls

Das solltet ihr vermeiden: Umfangreicher Hauptablauf des Rendering-Moduls.

Grund:

Das Rendering-Modul des Browsers erstellt über verschiedene Analyse- und Berechnungsschritte aus den übermittelten Daten wie HTML-Code, CSS, Skripten usw. die anzuzeigende Website. Dieser Prozess sollte relativ kurz gehalten werden.

Maßnahme:

Ein umfangreicher Hauptablauf kann das Ergebnis unterschiedlicher Faktoren wie zum Beispiel großer Seitengröße, umständlichen Codes, vieler Plugins, schlechter Multi-Purpose-Themes, zu umfangreichen CSS- und Javascript-Dateien, usw. sein. Das Rendering wird also eher indirekt optimiert.

Mehr Infos:

15 Ways To Minimize Main-Thread Work In WordPress (englischsprachig)

Aufgaben:

Indirektes Optimieren durch Reduzieren der Seitengröße, umständlichen Codes, vieler Plugins, schlechter Multi-Purpose-Themes, zu umfangreicher CSS- und Javascript-Dateien, usw.

Gesamtgröße aller geladenen Schriften

Das solltet ihr vermeiden: Schriften in größerem Umfang laden.

Grund:

Datenübertragung hängt direkt zusammen mit Energieverbrauch und damit mit der Belastung des Klimas. Wir halten ein Maximum von 200 KB beim Laden der Schriften für eine Website für erstrebenswert. Ideal wäre unter 50 KB.

Maßnahme:

Eine Analyse der Seite kann zeigen, welche Schriften geladen werden und ob diese gesamten Schriften in all ihren Schnitten (kursiv, fett, ...) tatsächlich benötigt werden. Auch kann noch radikaler insgesamt die Frage gestellt werden, ob solche Webfonts überhaupt genutzt werden oder man zumindest teilweise auf sogenannte System-Schriften zurückgreift – also Schriften, die am Endgerät sowieso schon installiert sind und daher keinerlei Datenübertragung benötigen.

Aufgaben:

Analyse, welche Schriften geladen werden und welche davon benötigt werden.

Unnötige Schriften entfernen

Gesamtgröße aller geladenen Schriften auf unter 200 KB reduzieren.

Redirects

Das solltet ihr vermeiden: Viele Redirects beim Aufbau der Seite

Grund:

Wenn Dateien, wie zum Beispiel Bilder, auf Eurer Seite verwendet werden, müssen diese beim Aufbau der Website geladen werden. Daher werden diese im Code Eurer Seite verlinkt. Wenn so ein Link nun aber mit einer Weiterleitung antwortet, der Server also dem Browser mitteilt, dass dieser Inhalt mittlerweile woanders liegt, dann muss der Browser eine weitere Verbindung zur nun korrekten Adresse aufbauen. Solche unnötigen "roundtrips" verbrauchen unnötig Energie.

Maßnahme:

Grundregel: Haltet Euren Code sauber. Dazu kann helfen, im Rahmen einer halbjährlichen Prüfung der Website auch gezielt nach Redirects zu suchen und diese zu korrigieren, indem direkt die richtige Adresse verlinkt wird.

Aufgaben:

Die aktuelle Zieladresse eines Links verwenden

Wenn diese sich im Lauf der Zeit ändert, den eigenen Link korrigieren, anstatt sich auf die Weiterleitung zu verlassen

Ladezeitpunkt von Drittanbieter-Code

Das solltet ihr vermeiden: Drittanbieter-Code direkt bei Seitenaufruf laden.

Grund:

Gerade Drittanbieter-Code wie beispielsweise Video-Einbettungen laden teilweise sehr viel Daten, schon alleine für das Darstellen des Players und das Vorbereiten ihrer gewünschten und unerwünschten Funktionen. Unabhängig davon, ob ein User das Video dann im Lauf seines Websitebesuchs ansehen wird oder nicht. Das ist ein Idealbeispiel für unnötig übertragene Daten - also unnötige Klimabelastung.

Maßnahme:

Über unterschiedliche Maßnahmen kann hier der CO₂e-Fußabdruck der Website klar reduziert werden. Radikal wäre natürlich zu hinterfragen, ob der Drittanbieter-Inhalt überhaupt benötigt wird. Falls ja, kann dieser zum Beispiel erst geladen werden, wenn sich die Nutzer:in der Seite der Position des Inhalts auf der Seite durch scrollen nähert oder noch besser, erst wenn die Nutzer:in durch klare Interaktion wie einen Klick auf einen (vermeintlichen) Play-Button die Anforderung des Inhalts startet.

Mehr Infos:

Best practices for using third-party embeds

Aufgaben:

Drittanbieter-Code auf eine Weise einbetten, die Datenmenge reduziert