Ok, man kann natürlich behaupten, es sei nicht die Aufgabe von Webdesignern und -entwicklern, die Umwelt zu retten. Man kann auch die Verantwortung für den hohen Energie- und Bandbreitenverbrauch beim Besuch einer Website auf die Endbenutzer abwälzen. Sollen die doch gefälligst ressourcenschonend mit dem Internet umgehen und sich neue energiesparende Geräte kaufen. Diese Einstellung kann man haben – sie ist allerdings mindestens bescheiden.

Einen ähnlichen Ansatz wählte Coca-Cola in den 50er Jahren des vorigen Jahrhunderts, um mit den Käufern ihrer Cola-Dosen zu verfahren. Um dem wachsenden Druck zur Regulierung von Einwegverpackungen entgegenzuwirken, gründeten sie zusammen mit anderen Gleichgesinnten eine gemeinnützige Organisation namens „Keep America Beautiful“ und steckten beträchtliche Geldbeträge in Kampagnen zur Förderung des Umweltbewusstseins. Das polierte ihr Image auf – aka Greenwashing –, aber die eigentliche Genialität lag in der Botschaft hinter den Kampagnen: Der Müll auf den Straßen hat nichts mit uns Herstellern zu tun, stattdessen liegt die Schuld voll und ganz bei den Konsumenten. Den Kampagnen gelang es, die gesamte Debatte über das Müll- und Abfallproblem von der Industrie auf die Verbraucher zu verlagern, und diese Strategie wird seither immer wieder gewinnbringend eingesetzt.

Die Digitalbranche sollte diesen Weg nicht bestreiten. Stattdessen sollten wir uns bewusst machen, dass es unser aller Aufgabe ist, nachhaltige Produkte zu kreieren. Im Gegensatz zu den Webschaffenden haben fast alle Industriezweige bereits Richtlinien und Messwerte zur Umweltverträglichkeit etabliert. Auch die Instrumente und Methoden zur Berechnung dieser Messwerte sind standardisiert. Die Gruppe der Entwickler und Webdesigner ist zurzeit noch an keine spezifischen Umweltstandards gebunden und das muss sich ändern.

Das Hauptaugenmerk bei nachhaltiger (Web-)Entwicklung und UI/UX liegt auf der Reduktion von CO₂-Emissionen. Allerdings gestaltet es sich äußerst schwierig, die von einem Webprodukt erzeugte CO₂-Menge tatsächlich zu messen. Die Emissionen unserer Websites kommen aus Kraftwerken, die Kohle und Gas verbrennen, und das macht das Internet zur größten kohlenbetriebenen Maschine des Planeten.

Viele der großen Internetkonzerne machen bereits einen Schritt in die richtige Richtung und setzen auf nachhaltige Energiegewinnung und Energiestrategien. Google verfolgt bereits seit 2012 diesen Weg und bezieht heute nach eigenen Angaben [1] 100 Prozent seiner Energie aus erneuerbaren Energien. In der Praxis stammen jedoch nur etwa 40 Prozent aus erneuerbaren Energien, die direkt in das Netz eingespeist werden. In Teilen der Welt, in denen das lokale Netz nicht über ausreichende Kapazitäten für erneuerbare Energien verfügt, ist Google nach wie vor auf den Kauf von sogenannten Renewable Energy Credits (RECs) angewiesen.

Betrachten wir Deutschland. Hier braucht „das Netz“ 55 Terawattstunden pro Jahr – die Energie von gut zehn großen Kraftwerken, also so viel Strom wie die ganze Stadt Berlin. Ein Drittel der Energie fließt dabei in Klimaanlagen, die zur Kühlung der Rechenzentren verwendet werden. Ansteigen wird dieses Energiepotenzial noch durch die weitere Verbreitung des Internet of Things. Experten vom Borderstep Institut [2] rechnen mit einem Mehrenergieaufwand von 70 Terawattstunden pro Jahr in der EU. Das sind mehr als 10 Prozent der Bruttostromerzeugung in Deutschland und mehr Strom, als Deutschland gerade mit Wind- und Solarkraft erzeugt. Und das Internet wächst und wächst [3].

Auch was den Datentransfer angeht, schwelgen wir in Superlativen. 2014 gingen weltweit monatlich 40 Exabyte (das entspricht 40 Millionen Terabyte) an Daten über die Leitungen. 2019 waren es bereits knapp 140 Exabyte und für das Jahr 2022 wird ein Anstieg auf über 270 Exabyte prognostiziert. Neuste Zahlen vom März [4] zeigen, dass am Internetknotenpunkt DE-CIX in Frankfurt ein neuer Rekord [5] gemessen wurde: 9,1 Terabit pro Sekunde. Das entspricht mehr als 20 Blu-Rays pro Sekunde. Zwar sind diese Zahlen bedingt durch die immer noch anhaltende Coronapandemie, jedoch soll zukünftig im Rahmen der Digitalisierung ja auch grundsätzlich mehr ins Homeoffice verschoben werden. Wer wissen möchte, wie sich diese Daten zusammensetzen, schaut sich am besten mal den Vortrag von Brad Frost [6] zum Thema Bullshit an.

Streamingdienste machen einen Großteil des Datenflusses innerhalb des Internets aus. Der globale Datenverkehr besteht zu 80 Prozent aus Videodaten. Diese Dateien sind besonders sperrig und konsumieren erheblichen Speicherplatz auf den Servern und dementsprechend auch viel Energie bei der Übertragung. Bedingt durch die Coronapandemie konnten die Streamingdienste einen enormen Zuwachs verbuchen. Allein Netflix konnte Anfang 2020 etwa 1,8 Millionen neue Benutzer:innen in Deutschland hinzugewinnen – im ersten Quartal 2020 lag die Zahl der Abonnent:innen bei über 7,2 Millionen. 2019 veröffentlichten Forscher des französischen Shift Project eine verstörende Studie [7]: Allein das Videostreaming hat 2018 mehr als 300 Millionen Tonnen CO₂-Äquivalente verursacht; das entspricht dem CO₂-Jahresausstoß von Spanien. No-Funfact: 27 Prozent entfallen auf pornographische Videos. Diese führten 2018 zu 80 Millionen Tonnen CO₂-Emissionen – so viel wie alle Haushalte Frankreichs im selben Jahr produzierten.

„Einfach“ die Energiegewinnung vollständig auf erneuerbare Energien umzustellen, löst nicht das Problem des Ressourcenhungers im Netz. Zurzeit ist der Anteil regenerativ erzeugten Stroms an der gesamten Stromnachfrage von Informations- und Kommunikationstechnologien immer noch gering [8]. Je mehr stromabhängige digitale Lösungen in alle Lebens- und Wirtschaftsbereiche einziehen, desto größer wird die Herausforderung, die Versorgung der Welt mit 100 Prozent erneuerbarer Energie überhaupt zu realisieren [9]. Erfahrungen zeigen, dass immer wieder Rebound-Effekte auftreten. Das bedeutet, dass technischer Fortschritt, der die effizientere Nutzung eines Rohstoffes erlaubt, letztlich zu einer erhöhten Nutzung dieses Rohstoffes führt, anstatt sie zu senken. Oder mit den Worten von Tilmann Santarius: „Bequemer konsumieren heißt oft mehr konsumieren.“ [10]

Alle News zu Web Design, UX und Digital Marketing

Ein Stück TORTE gefällig?

Ein beträchtlicher Teil des gesamten CO₂-Fußabdrucks des Internets – bis zu 40 Prozent – entfällt auf das Frontend, also den von Designern und Frontend-Entwicklern gestalteten Teil. Die meisten Bemühungen, den Stromverbrauch zu reduzieren, konzentrieren sich jedoch speziell auf Rechenzentren und schenken dem Design oder der Frontendanwendung wenig bis gar keine Aufmerksamkeit. Einfach ein wenig mehr UX draufzupacken hilft an dieser Stelle auch nicht weiter. Eine Website kann schnell laden und hat einen performanten First Meaningful Paint, lädt aber später via Lazy-Load viele großformatige Bilder und Videos nach – tolle Experience, aber schlechte Ökobilanz. Nachhaltiges Webdesign erfordert ein ganzheitliches Herangehen – alle Projektbeteiligten müssen ihren Teil dazu beitragen.

An dieser Stelle sei erwähnt, dass sogar Müll seinen Leitsatz hat – 3R [11] für „Reduce, Reuse, Recycle“. Müll hat also mehr Nachhaltigkeitsrichtlinien als Websites. Somit ist jetzt geklärt, dass Websites auch eine Eselsbrücke brauchen, um den Weg zu einem nachhaltigeren Internet in unserem Langzeitgedächtnis zu verankern: Bühne frei für TORTE: „Testen, Optimieren, Reduzieren, Thematisieren und Engagieren“ (Abb. 1).

Abb. 1: Das TORTEn-Diagramm

TORTE erfordert, dass wir uns zu Beginn selbst ein paar unbequeme Fragen stellen bzw. ein paar unbequeme Antworten akzeptieren müssen: Ist die Ökobilanz unserer Website eher die eines Fahrrads oder die eines SUVs? Dem Prinzip TORTE folgend heißt es also testen, testen, testen, um ein Verständnis unserer Website zu bekommen – getreu dem Motto: „You can’t manage what you can’t measure“ (nach Peter Drucker [12]).

T wie Testen

Wie vorangehend erwähnt, gestaltet es sich äußerst schwierig, verlässliche Messwerte über den CO₂-Ausstoß unseres Digitalgewerkes zu bekommen. Die Verbindung zwischen unserer App und dem Kraftwerk, dem der zugehörige Strom entstammt, kann nicht direkt gezogen werden. Kann man also die tatsächlichen Kohlenstoffemissionen nicht messen, muss man sich einer anderen Metrik bedienen, die wir überwachen können. Die wichtigsten Faktoren, die als Indikatoren für CO₂-Emissionen verwendet werden können, sind die eigentliche Datenübertragung und Kohlenstoffintensität der zugrundeliegenden Elektrizität.

Eine gängige Metrik zur Erfassung des Energieverbrauchs und der CO₂-Emissionen ist Kilowattstunden pro Gigabyte (kWh/GB). Diese Metrik gilt als Maß für die Energieeffizienz einer Website oder App, die über das Internet übertragen wird. Als Faustregel gilt: Je mehr Daten übertragen werden, desto mehr Energie wird im Rechenzentrum, in den Telekommunikationsnetzen und auf den Endgeräten verbraucht. Daten sind Elektrizität und die Gewinnung von Elektrizität verursacht CO₂-Ausstoß (Kasten: „Das Datenmantra“).

Daten ➞ Elektrizität ➞ CO₂

Bei Webseiten lässt sich der Datentransfer für einen Besuch am einfachsten anhand der Seitengröße in Kilobyte abschätzen, d. h. die Übertragungsgröße beim ersten Besuch der Seite. Tools zum Messen dieser Metrik sind bereits in die Entwicklertools integriert und auch unser Webhoster versorgt uns mit den passenden Statistiken zur gesamten Datenübertragung unserer Webanwendung.

Ein geringerer Datentransfer führt zu mehr Energieeffizienz. Je effizienter unsere Produkte sind, desto weniger Strom verbrauchen sie und desto weniger fossile Brennstoffe müssen verbrannt werden, um den Strom für ihren Betrieb zu erzeugen. Strom ist die Basis unseres Schaffens. Wenn der Strom ausfällt, verschwindet all das, was wir designt, programmiert und gebaut haben. Die Server, auf denen die von uns erstellten Produkte und Dienstleistungen gehostet werden, benötigen rund um die Uhr Strom – 24/7/365. Daher ist es wichtig, auch die Quellen dieses Stroms und ihre Kohlenstoffintensität zu berücksichtigen.

Neben der Energieeffizienz wird die Nachhaltigkeit digitaler Produkte entscheidend von der Kohlenstoffintensität der verwendeten Energie bestimmt. Die Kohlenstoffintensität bezeichnet die Menge an CO₂ in Gramm, die für jede Kilowattstunde Strom erzeugt wird (gCO₂/kWh). Erneuerbare Energiequellen und Kernenergie haben eine extrem niedrige Kohlenstoffintensität von weniger als 10 gCO₂/kWh (auch unter Berücksichtigung ihrer Konstruktion), während fossile Brennstoffe eine sehr hohe Kohlenstoffintensität von ca. 200-400 gCO₂/kWh haben [13].

Da das Internet ein dezentrales Netz ist, wird ein einzelner Nutzer einer Website oder App Energie aus mehreren verschiedenen Stromnetzen gleichzeitig beziehen. Der heimische PC nutzt Strom aus Deutschland, wohingegen das Rechenzentrum der Website Strom aus einem Netz in den USA bezieht. Erschwerend kommt hinzu, dass die Telekommunikationsnetze Energie von überall zwischen den USA und Deutschland nutzen. Wir haben keine Kontrolle über die gesamte Energieversorgung von Webdiensten, aber wir haben eine gewisse Kontrolle darüber, wo wir unsere Projekte hosten. Wenn wir unser Wissen über die Kohlenstoffintensität mit der Berechnung des Energieverbrauchs kombinieren, können wir die Kohlenstoffemissionen unserer Websites und Anwendungen recht gut interpolieren. Ein guter Anfang ist es daher, nachzufragen, woher die Energie für unser Opus kommt.

Ein Tool hierzu bietet die Green Web Foundation [14]. Damit lässt sich aus einer gut gepflegten Datenbank abfragen, ob unser Hoster regenerative Energien verwendet oder nicht – was ein Grund wäre, über einen Hosterwechsel nachzudenken. Mit diesem einfachen Tool gewinnen wir schon wichtige Einblicke in unsere Website, die wir oft einfach aus Bequemlichkeit ignoriert bzw. als gottgegeben hingenommen haben. Schon an dieser Stelle können wir eine Wirkung erzielen, etwas positiv verändern und die Ökobilanz unserer Website verbessern – nur durch die Auswahl eines „grünen“ Hosters. Die Green Web Foundation liefert auch gleich eine Liste der grünen Hoster mit.

Die Website Carbon Calculator [15] misst die Datenübertragung beim Laden einer Website, berechnet die damit verbundene Strommenge und wandelt diese Zahl in eine analoge CO₂-Menge um. Dabei wird auch berücksichtigt, ob das Webhosting mit erneuerbaren Energien betrieben wird. Auch Ecograder [16] sei an dieser Stelle aufgeführt: Ecograder taucht schon ein bisschen tiefer in die Technik unserer Website ein und unterzieht sie verschiedenen Tests, wie z. B. Google Page Speed Insights und MozRank. Auch hier wird am Ende der Evaluierung ein Score ausgespuckt und es werden gleich ein paar Vorschläge gemacht, was wir noch verbessern können.

Ein weiteres Tool, das mehr Einblick darüber gibt, was wir eigentlich so über die Leitung schicken, ist Pingdom Website Speed Test [17]. Mit diesem Werkzeug lassen sich Ladezeiten testen, analysieren und Engpässe finden. Ein besonderes Feature ist, sich die Seite von unterschiedlichen Standorten aus laden zu lassen, um auch Aussagen über die globale Performanz treffen zu können. Im Gegensatz zum Website Carbon Calculator liefern Ecograder und Website Speed Test keine direkten Angaben zum CO₂-Verbrauch.

Mit der Möglichkeit, die CO₂-Emissionen für unsere Projekte zu berechnen, können wir noch einen Schritt weiter gehen und Kohlenstoffbudgets für unsere Webprojekte festlegen. CO₂ ist keine Metrik, die Entwickler und Designer ständig auf dem Schirm haben. Da passen Kilobytes und Megabytes schon eher. Allerdings sollten wir beginnen, auch in CO₂-Emissionen zu denken, und CO₂-Budgets könnten ein Anfang sein.

Jetzt haben wir einen Anhaltspunkt, wie hoch der Energieverbrauch bzw. der CO₂-Ausstoß unserer Website ist, und wir wissen etwas über unseren Hoster. Wie sieht es allerdings auf Seiten des Benutzers aus? Wer oder was verbraucht dort die ganze Energie?

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Der Großteil der Energie auf (mobilen) Geräten wird von einigen wenigen Hauptkomponenten verbraucht: CPU, GPU, Vernetzung (Wi-Fi und zellulare Funkchips) und Bildschirm. Der Stromverbrauch des Bildschirms ist relativ konstant und unterliegt meist der Kontrolle des Benutzers (z. B. über Einschaltzeit und Helligkeit des Bildschirms), die anderen Komponenten allerdings, wie CPU, der Grafikprozessor und die Netzwerkhardware haben eine hohe Dynamik, was den Stromverbrauch angeht. Das System passt die CPU- und GPU-Leistung auf der Grundlage der aktuell zu bearbeitenden Aufgaben an. Im Großen und Ganzen gilt: Je mehr Leistung von den Chips verlangt wird, desto geringer ist ihre Energieeffizienz. Die Hardware ist in der Lage, sehr schnell Höchstleistung zu erbringen (aber zu hohen Energiekosten) und dann genauso schnell wieder in einen effizienteren Zustand mit geringerem Stromverbrauch zurückkehren.

Seit 2019 integriert der Safari-Browser in der CPU Timeline seiner Developer-Tools eine Anzeige, die Aussagen zum aktuellen Energieverbrauch macht. Auch im eigenen Browser lassen sich somit Messungen zum Energieverbrauch anstellen (Abb. 2).

Abb. 2: Messungen zum Energieverbrauch in Safari

O wie Optimieren

Auf das Messen folgt bei TORTE das Optimieren. Worauf müssen wir in Bezug auf Stromverbrauch achten? Um die Batterielebensdauer zu maximieren bzw. den Stromverbrauch zu minimieren müssen wir die Zeit, die das System im Hochleistungszustand verbringt, reduzieren und die Hardware so weit wie möglich in den Leerlauf zurückkehren lassen. Dazu müssen drei Interaktionszustände genauer betrachtet werden. Die Seite ist

im Fokus und der Benutzer interagiert damit,
im Fokus, aber ohne Benutzerinteraktion, oder
nicht im Fokus.

Daraus ergibt sich eine einfache Faustregel: Am besten ist es, Energie in den Zeiten zu verbrauchen, in denen der Benutzer mit der Seite interagiert. Es bleibt immer unser Ziel, die Seite schnell zu laden und während Interaktion aktiv und performant zu halten. In den meisten Fällen senken dieselben Optimierungen, die die Time to First Paint und Time to User Interactive reduzieren, auch den Stromverbrauch.

Das Nachladen von Ressourcen und die Ausführung von Skripten nach dem initialen Laden der Seite erhöhen den Stromverbrauch. Das Ziel sollte es sein, so schnell wie möglich wieder in den Leerlauf zurückzukehren. Je weniger JavaScript ausgeführt wird, desto energieeffizienter ist die Seite. Skripte erzeugen Arbeit zusätzlich zu dem, was der Browser bereits für das Layout und die Gestaltung der Seite geleistet hat. Sobald die Seite geladen ist, werden durch Benutzerinteraktionen wie Scrollen und Tippen auch die Leistung von CPU und GPU erhöht, um die flüssige Interaktion mit der Seite zu gewährleisten. Endet die interaktive Phase, so müssen wir wieder zurück in den Leerlauf. Dabei sollten wir uns an den schönen Spruch „Paint the Picture not the Frame“ [18] halten: Browser schenken uns so Vieles (und bereits Optimiertes) – normales Scrollen einer Seite ist viel energieeffizienter als Custom Scrolling, das in JavaScript implementiert wurde.

Ich weiß, ich höre mich an wie ein Spielverderber, aber wollen wir nicht alle eine performante Website? Ein beliebtes Spielzeug sind Timer und genau deren Einsatz sollten wir tunlichst reduzieren (wenn nicht gar vermeiden). Timer wecken die CPU. JavaScript-Timer erweisen sich als guter Einstiegspunkt für Entwickler, um mit dem Optimieren zu beginnen.

Auch das noch immer gegenwärtige Polling sollten wir vermeiden, wenn es darum geht, regelmäßige Aktualisierungen von einem Server zu erhalten. Wir befinden uns im Jahr 2022 und dürfen Technologien wie WebSockets [19], Server-sent Events [20] oder Fetch [21] mit einer dauerhaften Verbindung verwenden.

Bling-Bling

Wir alle lieben es, wenn es blinkt und glitzert! Aber auch an dieser Stelle ist weniger oft mehr. Kontinuierlich animierte Inhalte, wie animierte GIFs und automatisch abspielende Videos ziehen fortwährend Strom. Ein kleines Spinner-GIF löst im Browser dauernde Malerei aus, auch wenn wir es nicht sehen können.

Wenn wir Animationen benötigen, sollten wir nach Möglichkeit deklarative Animationen (CSS Animations und Transitions) verwenden. Der Browser kann diese wegoptimieren, wenn das animierte Element nicht sichtbar ist, außerdem sind sie effizienter als skriptgesteuerte Animationen. Wir sollten darauf verzichten, Eigenschaften zu animieren, die Layout oder Paint Events auslösen. Das bedeutet jedoch, die Animationen auf Opacity oder Transform [22] zu beschränken; beides kann der Browser in hohem Maße optimieren [23].

Wenn es uns um die Nachhaltigkeit einer Website geht, darf man sich gerne einmal in Verzicht üben bzw. die opulente Animation ein wenig reduzierter mit CSS konstruieren. Eine Website, die kontinuierlich am Arbeiten ist, auch wenn sie gerade im Leerlauf sein sollte, reagiert auch weniger auf Benutzerinteraktionen. Eine Minimierung der Hintergrundaktivität verbessert die Reaktionsfähigkeit und gleichzeitig die Akkulaufzeit – Win-win!

Tausend Worte statt eines Bildes

Rufen wir uns vorher noch einmal ins Gedächtnis: Daten benötigen Elektrizität und das bedeutet CO₂-Ausstoß. Dementsprechend wichtig ist es, unnötige Bits und Bytes loszuwerden, die letztlich aus unserer Faulheit resultieren. Ein dicker Brocken sind Grafiken und Bilder.

Dazu ein kleines Rechenbeispiel in Anlehnung an [24]: Zu Beginn der Coronapandemie war die Seite der Johns Hopkins University (nachfolgend JHU) eine der populärsten Seiten im Netz. Jeder wollte die neuen Fallzahlen sehen. Schauen wir uns also das Logo der JHU ein wenig genauer an. Ein SVG mit 21,67 KB und ein paar Angaben darüber, mit welchem Programm es erstellt wurde etc. Genau dieses SVG habe ich mit einem Webtool namens SVGOMG (siehe unten) ein wenig optimiert. Dabei konnten 12,15 KB eingespart werden, das sind immerhin fast 44 Prozent. Die JHU wurde im April 7,9 Millionen Mal pro Tag aufgerufen – das entspricht einer Zahl von 237 Millionen Aufrufen im Monat. Multiplizieren wir die Views pro Monat mit unserer Ersparnis, so kommen wir auf eine Gesamtersparnis von 2 948,7 Gigabyte. Um auf einen realistischen Wert zurückzugreifen und eine gewisse Vergleichbarkeit zum Website Carbon Calculator herzustellen, veranschlagen wir einen Energieaufwand von 1,8 kWh pro Gigabyte [25].

Multiplizieren wir diesen Wert mit unserer Gesamtersparnis, kommen wir auf 5 307,66 kWh. Ok, es wird ja auch einiges gecacht, gerade bei wiederkehrenden Besuchern. Also muss dieser Faktor noch herausgerechnet werden. Da gerade bei diesem Beispiel täglich neue Besucher dazu kamen, ziehen wir einen geschätzten Wert von 25 Prozent Caching ab und landen dann immer noch bei einer Zahl von 3 980,7 kWh. Das entspricht dem Energieverbrauch von mehr als 2,5 Singlehaushalten pro Jahr und etwa 2,3 Tonnen CO₂.

Diese Rechnung unterstreicht sehr gut die Weisheit „Kleinvieh macht auch Mist“. Übrigens kann man diese Rechnung auch mit Tracking-Pixeln [26] (100-130 Byte) durchführen, diesen kleinen Plagegeistern, die wir nur allzu häufig mit zugehörigen Skripten untergeschoben bekommen. Ein weiterer Grund, darauf zu verzichten.

Das Netz bietet eine Vielzahl an Tools und Ressourcen, die uns beim Optimieren unserer Grafiken unter die Arme greifen können. Hier seien exemplarisch SVGOMG, Squoosh, ShortPixel und ImageOptim erwähnt. Diese Tools helfen dabei, das letzte bisschen überflüssigen Ballast aus Bildern herauszupressen. Squoosh oder ImageOptim kommen mit einer Vielzahl an Web-Image-Formaten zurecht und kombinieren nahtlos einige Bildoptimierungstools, wie z. B. MozJPEG, pngquant, Pngcrush, 7zip, SVGO und Google Zopfli. Ein netter Nebeneffekt bei ImageOptim ist, dass auch private EXIF-Metadaten von Digitalkameras weggeworfen werden. Man macht also auch noch was für den Datenschutz.

Als Faustregel gilt: Die Bildqualität so weit herunterschrauben, bis es anfängt, weh zu tun. Unsere Bilder sollten in der kleinsten Größe gespeichert werden, die sowohl in Bezug auf die Auflösung als auch auf die Bildqualität noch tolerierbar ist. Wenn wir jetzt noch unsere HTML-Lektion gelernt haben und die Bilder je nach Viewport ausliefern, lassen sich noch mehr Einsparungen erzielen (Listing 1).

<img srcset="elsa-anna-480w.jpg 480w, elsa-anna-800w.jpg 800w"
  sizes="(max-width: 600px) 480px, 800px"
  src="elsa-anna-800w.jpg"
  alt="Elsa und Anna im Schnee">

Auch der Einsatz alternativer Bildformate kann einen erheblichen Unterschied machen. WebP ist ein modernes Bildformat, das eine hervorragende verlustfreie und verlustbehaftete Komprimierung für Bilder im Web bietet. WebP ist im Vergleich zu PNG um 26 Prozent schlanker, verlustbehaftet ist es rund 25-34 Prozent kleiner als ein vergleichbares JPEG bei gleichem SSIM-Qualitätsindex. WebP rückt nun endlich dank verbessertem Browsersupport wieder in den Fokus und wird von vielen Online- und Offlinetools unterstützt [27], [28].

Ich gehe an dieser Stelle bewusst nicht tiefer auf Videos ein, das würde den Rahmen sprengen. Allerdings können wir uns jetzt alle vorstellen, was Optimierungen von Videoinhalten ausmachen, wenn schon ein kleines SVG einen so großen Impact haben kann. Videos bringen, im Gegensatz zu Bildern, den Zeitfaktor mit. Daher sollte man sich die Frage stellen: „Brauche ich wirklich das ganze Video oder tut’s auch ein Loop“ (gerade, wenn das Video nur im Hintergrund verwendet wird)? Wir müssen auch die Art und Weise hinterfragen, wie wir unsere Videos einbetten. Verwenden wir doch besser <video></video> statt YouTube Embeds. Vielen von uns ist nämlich nicht bewusst, dass wir durch das Embedden auch einiges an Skripten erben, die auch mal größer sein können als das eigentliche Video selbst.

Wer findet, muss nicht suchen

Ein weiterer Aspekt, mit dem wir uns beschäftigen müssen, ist die Auffindbarkeit unserer Seite. Auffindbarkeit ist ein grundlegender Pfeiler positiver UX. Wir müssen uns mit Search Engine Optimization befassen. SEO hat auf den ersten Blick nichts mit der Energieeffizienz von Websites zu tun, dabei steckt die Optimierung schon im Titel. Das Ziel von SEO ist inhärent mit dem Ziel der Reduzierung des Energieverbrauchs verbunden. Ist unsere Website in Suchmaschinen leichter auffindbar, helfen wir Menschen dabei, die gewünschten Informationen schneller und einfacher zu finden. Erfolgreiches SEO führt dazu, dass die Menschen weniger Zeit damit verbringen, im Web nach Informationen zu suchen und dadurch weniger irrelevante Seiten besuchen, die nicht ihren Bedürfnissen entsprechen. Das bedeutet, dass effektiv weniger Energie für unnötiges Surfen verbraucht wird. Klares und zielgerichtetes Texten trägt dazu bei, die vergeudete Zeit im Internet und damit auch die vergeudete Energie zu reduzieren. Ein (sinnvoller) Trend sind die sogenannten Lite-Websites – Text-only-Websites, die einem Zweck dienen: zu informieren. Und ja, auch Facebook, Twitter und Reddit gibt es in einer Lite-Version [29]. Denkt daran: „When information is cheap, attention becomes expensive“ (James Gleick).

Auch der Einsatz von statischen Websitegeneratoren, um statt dynamischer und unnötig rechenintensiver bereits vorgefertigte statische Seiten zu liefern, erfreut sich wachsender Popularität. Back to the Roots: Webseiten lassen sich noch immer als statische Dateien in HTML, CSS und JS schreiben oder eben durch statische Websitetools wie Jekyll, HUGO, Eleventy usw. generieren; zusammen mit JAMStack lässt sich hier einiges erreichen. Eine gute Gedankenstütze, die einige dieser Punkte zusammenfasst, bietet die Green-UX-Checkliste von Manoverboard [30].

Dunkle Websites waren schon vor vielen Jahren eine der ersten Techniken, die zum Energieeinsparen im Web eingesetzt wurden. Allerdings verschwanden sie wieder mit dem Aufkommen von LCD-Bildschirmen, die im Gegensatz zu CRT-Bildschirmen eine permanente Hintergrundbeleuchtung hatten. Mit der Verbreitung von OLED-Bildschirmen, die jedes Pixel einzeln beleuchten, ist die Verwendung des Dark Modes wieder eine praktikable Technik, um den Energieverbrauch von Endgeräten zu reduzieren. Mit nur wenigen Zeilen Code und dem Einsatz von CSS Custom Properties lässt sich schnell ein minimalistischer Dark-Mode-Switch [31] mit Farbschemaabfrage auf Betriebssystemebene generieren. Das CSS-Media-Feature prefers-color-scheme lässt uns erkennen, ob der Benutzer auf Betriebssystemebene ein helles oder dunkles Farbschema verwendet und dementsprechend unsere Custom Properties anpassen (Abb. 3).

Abb. 3: Mini-Dunkelkammer-Experiment

R wie Reduzieren

Stellen wir uns einfach wie Marie Kondō die Frage „Does it spark joy“? Das kleine Wörtchen „nein“ als Designtool hilft uns immens beim Energiesparen. Die daraus folgende Datensparsamkeit hilft nicht nur beim nachhaltigen Einsatz von Ressourcen, sondern auch bei der Umsetzung der DSGVO.

Anfang 2020 lag die durchschnittliche Seitengröße laut HTTP-Archiv für Desktopwebsites bei 1,97 MB und bei 1,77 MB für mobile Websites, wobei sich die Größe von Desktopseiten seit Januar 2016 um 36 Prozent gesteigert hat. Die Größe von mobilen Seiten hat sich im gleichen Zeitraum fast verdoppelt. Wir haben zwar inhaltlich weniger zu sagen, das aber mit immer mehr Megabytes.

Hier ein Framework, da ein paar Videos inkl. Autostart, ein paar Webfonts für drei unterschiedliche Icons und zu guter Letzt die ultrahochauflösenden Bilder des Firmenvorstandes für die Thumbnails. Wir haben durch die steigende Bandbreite verlernt, achtsam mit unseren Assets umzugehen. Das müssen wir allerdings wieder lernen, am besten, indem wir uns ein bisschen Selbstdisziplin auferlegen. Das Stichwort heißt Performancebudgets.

Performancebudgets

Ein Performancebudget ist eine Obergrenze für Webseiten, die von uns nicht überschritten werden darf. Es kann eine maximale JavaScript-Bundle-Größe, die Gesamtgröße von Bildern, eine bestimmte Ladezeit (z. B. Time to Interactive in unter 5 s bei 3G) oder ein Schwellenwert für eine beliebige Anzahl anderer Metriken sein. Aber Performancebudgets sind nicht nur Schwellenwerte. Ähnlich wie ein finanzielles Budget zwingen sie uns, bewusster auszugeben. Man könnte es als Währung betrachten, die wir im Sinne der Benutzererfahrung ausgeben bzw. mit der wir handeln. Performancebudgets sind eines der wenigen wirklich erfolgversprechenden Tools. Allerdings benötigen sie eine Metrik, mit der wir unseren Erfolg messen können. Diese kann mengen- oder regelbasiert sein:

Mengenbasierte Metriken basieren auf Größen (z. B. Größe des verwendeten JavaScript (KB/MB), Anzahl der HTTP-Anfragen). Sie konzentrieren sich auf die Erfahrung innerhalb des Browsers.
Regelbasierte Metriken stützen sich auf Bewertungen, die von Tools wie Lighthouse oder WebPageTest generiert werden. Häufig eine einzelne Zahl oder eine gesamte Reihe zur Bewertung Ihrer Website.

Performancebudgets lassen sich sehr gut in Continuous-Integration-Prozesse integrieren, indem eine Warnung oder ein Fehler beim Build-Prozess ausgegeben wird, wenn gegen das Performancebudget verstoßen wird. Valide Beispiele für Budgets sind:

Unsere Detailseite muss weniger als 170 KB JavaScript auf mobilen Endgeräten enthalten.
Unsere Suchseite darf nur maximal 2 MB an Bildern auf Desktoprechnern enthalten.
Unsere Homepage muss in weniger als 5 s bei Slow 3G/Moto G4 laden und interaktiv sein.
Unser Blog muss bei den Lighthouse-Performance-Audits mindestens 80 Punkte erzielen.

Oftmals gehen die Budgets miteinander einher, wie in den Beispielen zu sehen ist. Seiten, die bei schlechten Verbindungen nicht gut performen, wenn zu viel Ballast über die Leitung geschickt wird, werden im Umkehrschluss auch nicht gut in einem Tool wie Lighthouse abschneiden.

Wenn man mit Performancebudgets beginnen will, bietet das Onlinetool Performance Budget Calculator [32] gute Unterstützung. Allein über Performancebudgets ließe sich schon ein ganzer Artikel schreiben. Eine schöne Sammlung an Links zum Thema findet sich ebenfalls auf der genannten Seite.

Auch beim Continuous Integration lässt sich Energie sparen. Nicht jede geänderte Farbe im Frontend oder jedes Komma im Text muss nach dem Push sofort die komplette Kaskade in Gang setzen, die zuletzt noch etliche Gigabyte in Docker-Container verpackt. So bequem es auch sein mag, hier gibt es kräftiges Einsparpotenzial.

Lean HTML

Auch was den HTML-Code angeht, lassen sich mengenmäßige Einsparungen vornehmen. Semantisches HTML ist die Antwort, geht es um Zugänglichkeit, Auffindbarkeit oder schlichtweg um schlanken Code:

<div tabindex="0" role="button" aria-pressed="false">Save</div>
<!-- vs. -->
<button>Save</button>

Das obige Beispiel zeigt, wie viel Ornamentierung notwendig ist, um eine vom Browser geschenkte Funktion und Ausprägung schlecht zu imitieren.

Auch was die Layoutstruktur unserer Seiten angeht, lassen sich mit CSS-Grids komplexere Gestaltungsraster konzipieren als je zuvor – bei gleichzeitig weniger Code. Weder Floats noch FlexBox erlauben wirklich komplexe Grid-Strukturen, immer fehlen ein paar Features. CSS Grids wirken direkt auf dem Elternelement. Darauf werden das Raster definiert und die Kindelemente positioniert. Es bedarf nur der Angabe display:grid; auf dem Elternelement und der Eigenschaften grid-template-columns und grid-template-rows und fertig ist die Rasterlaube [33].

Fontspartag

Fonts sind des Designers Lieblinge. Designer lieben Typografie – wir alle lieben Typografie (danke Peppa Wutz …). Aber warum müssen gleich alle Schriftschnitte in unserer Website referenziert werden, wenn wir doch nur Regular und Bold brauchen? Auch Dynamikfonts sind da nicht die Lösung, sondern eher der Beginn eines neuen Rebound-Effekts. Überlassen wir die Typografie doch den Betriebssystemen. Deren Designer haben die schönsten Fonts für die Anzeigen in den jeweiligen Systemen bereits für uns ausgesucht – von San Francisco bis Roboto. Diese Fonts kann man sich einfach und schnell mit dem sogenannten System-Font-Stack ausleihen:

font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",
sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji“;

Da ist nun wirklich für jeden was dabei. Tolle Fonts erhalten und gleichzeitig noch die Performance steigern. Und wenn es denn mal unbedingt etwas anderes sein muss, finden sich im Artikel von Joshua Stopper unter [34] ein paar gute Tipps, wie sich mit Custom Web Fonts Ressourcen sparen lassen.

Alle News zu Web Design, UX und Digital Marketing

Noch Fragen?

Formulare spielen bei der Computer-Benutzer-Interaktion eine zentrale Rolle. Allerdings erheben wir in diesen Formularen sehr häufig Daten, die für den Benutzer im aktuellen Kontext nicht verständlich sind bzw. die Frage aufwerfen, warum diese eigentlich benötigt werden. Vielleicht sind wir auf Businessebene über das Ziel hinausgeschossen oder haben, in vorausschauender Manier, Daten abgefragt, die wir irgendwann einmal brauchen könnten. Diese liegen jetzt ungenutzt auf dem Webserver und im CRM und wandern allnächtlich ins Back-up.

Eine Möglichkeit, wie wir dem entgegenwirken können, sind Frageprotokolle [35]. Frageprotokolle ermöglichen es, bestehende Formulare und auch Formulare, die gerade erst entworfen werden, gezielt zu analysieren. Ein Frageprotokoll listet auf:

jede Frage die wir stellen,
wer innerhalb unserer Organisation die Antworten zu der Frage verwendet,
wozu wir die Antworten verwenden,
ob eine Antwort notwendig oder optional ist und
was passiert, wenn ein Benutzer nur veraltete oder falsche Angaben macht, um durch das Formular zu kommen.

Wenn wir merken, dass wir eine Frage nicht beantworten können, bzw. die Antwort keinen ersichtlichen Nutzen für uns, unser Produkt oder den Benutzer generiert, dann können wir auf die Erhebung des jeweiligen Datensatzes verzichten. Es muss uns klar sein, dass alle Daten, die wir erheben, auch Kosten generieren.

Benutzerkosten		Businesskosten
Aufmerksamkeit	Was könnte ein Nutzer übersehen, wenn das Formular mühsam ist?	Datenspeicherung	Wo werden wir die ganzen Daten aufheben?
Zeit	Wieviel Zeit benötigt ein Benutzer wirklich, um die Formularfelder abzuarbeiten?	Datenpflege	Wie hoch sind die Kosten für die Aktualisierung, Änderung und eventuelle Entsorgung von Daten?
Vertrauen	Was passiert, wenn Benutzer nicht verstehen, warum bestimmte Daten benötigt werden?	Datenqualität	Wie lange wird es dauern, sich durch die Datensätze zu sieben, um an die gewünschten Daten zu kommen?
Physische Kosten	Was braucht der Benutzer, um das Formular auszufüllen?	Vertrauensbruch	Wie werden Benutzer reagieren, wenn Daten missbraucht oder verkauft wurden?

Tabelle 1: Datensparsamkeit mit Frageprotokoll

Datensparsamkeit hilft uns nicht nur beim nachhaltigen Einsatz von Ressourcen, sondern auch bei der Umsetzung der DSGVO. Also besser mal nachfragen.

T wie Thematisieren

Genauso wichtig wie unsere technischen und inhaltlichen Optimierungen und Reduzierungen ist es, up to date zu bleiben und sich kontinuierlich eine Vorstellung darüber zu machen, wie Technologien sich in Bezug auf Nachhaltigkeit verändern. Wir brauchen einen verständlichen Kontext, der uns Webschaffende anleitet, vermehrt nachhaltig zu denken und entsprechend zu handeln. Wir müssen wissen, wie viel CO₂-Emissionen das Internet erzeugt, wenn man surft, kommuniziert, ein Video streamt oder eine Website designt. Solide Informationen über die CO₂-Bilanz von Onlineaktivitäten sind schwer zu finden, aber es werden Tag für Tag mehr. Das Thema tritt in den Fokus und wir fangen jetzt an, zu verstehen, dass das Internet die größte kohlenbetriebene Maschine auf dem Planeten ist. Nicht nur „die“ müssen etwas tun, sondern auch wir. Das betrifft unsere eigenen privaten Surfgewohnheiten sowie auch unsere professionelle Arbeit. Neben dem Schaffen eines Verständnisses für ein nachhaltiges Internet ist es wichtig, unsere Erfahrungen und Learnings zu kommunizieren, zu thematisieren und damit den Ball weiter am Rollen zu halten.

Ein guter Anfang und etwas Futter für die Leseliste ist der Artikel von James Christie zum Thema Sustainable Web Design aus dem Jahr 2013(!) [36]. Damit hat alles angefangen. Wenn wir tiefer in die Materie einsteigen wollen, bietet sich „Designing for Sustainability“ von Tim Frick an. Von dort aus geht es zum hervorragenden Artikel von Eric Bailey [37], der zwar nicht im Nachhaltigkeitskontext steht, aber trotzdem ein paar wichtige Aspekte zum Thema enthält. Auch bei Wholegrain Digital, den Machern hinter dem Website Carbon Calculator finden sich sehr lesenswerte Beiträge [38]. Ergänzt wird das Schaffen von Wholegrain Digital durch das lesenswerte neue Buch ihres Mitgründers Tom Greenwood [39] aus dem Jahr 2021.

Wie bei jeder guten Bewegung braucht es auch ein Manifest, an dem wir uns orientieren können. Das Sustainable Web Manifesto [40] ist dafür eine ideale Anlaufstelle und braucht noch ein paar Unterstützer, denn nachhaltiges Webdesign ist eine Notwendigkeit für uns alle.

E wie Engagieren

Wenn wir von einer Sache überzeugt sind, wollen wir uns auch dafür ins Zeug legen und andere davon begeistern bzw. selbst ein Teil der Bewegung werden. Auch Kunden lassen sich von einem nachhaltigen Webdesignkonzept überzeugen – jeder mag TORTE!

Nachhaltiges Webdesign ist eine Win-win-Situation für alle direkt und indirekt Beteiligte und liefert uns sehr gute Argumente: Wir verbessern die Usability und User Experience, erzeugen klare und erfassbare Designs, verzichten auf Bullshit [6], erzielen bessere SEO-Rankings, benötigen kürzere Ladezeit und kommen gleich mit einer Content- und damit auch Mobile-optimierten Seite um die Ecke. Und zu guter Letzt, wir tun etwas für die Umwelt [41]! Es gibt viele sinnvolle Initiativen zum Thema, die unsere Unterstützung brauchen, um mehr Awareness für ein nachhaltiges Internet zu schaffen. Dazu zählen u. a. die Tech Impact Makers [42], ClimateAction.tech [43], UnternehmensGrün [44] und Bits & Bäume [45].

Wir Webdesigner und -entwickler spielen eine maßgebliche Rolle dabei, wie sich das Web der Zukunft entwickelt. Sowohl bei der Konzeption, dem Design der Programmierung und auch der Nutzung können wir damit beginnen, das Internet bewusster und achtsamer zu nutzen. Am besten sollten wir gleich versuchen, beim Redesign oder beim nächsten neuen Projekt Nachhaltigkeit – genau wie UX – im Projekt zu verankern. Wir müssen unsere Kollegen, Kunden und uns selbst davon überzeugen, Nachhaltigkeit zu einem Designprinzip zu machen.

Deshalb: Testet, optimiert, reduziert, thematisiert und engagiert euch! Dann klappt’s auch mit der TORTE.