Eine Illustration die ein Foto einer Vektor-Illustration gegenüber stellt

Nachhaltig: Webentwicklung bei der GfG

23. September 2024

Nachhaltigkeit und Inklusion – zwei große Begriffe, die wir im GfG-Webentwicklungsteam über unsere Arbeit stellen wollen. Noch sind wir bei der Umsetzung nicht dort angekommen, wo wir gerne wären. Aber wir wollen schon jetzt so viele Menschen wie möglich auf diesen Weg mitnehmen. Kein erhobener Zeigefinger, sondern der Wunsch, dass wir Aufmerksamkeit erzeugen für ein Thema, das diese Aufmerksamkeit verdient.

Warum sich die Mühe für nachhaltige und inklusive Webangebote immer lohnt und wie beides auch noch mit attraktivem Design zusammengeht, erzählt unser Senior Developer und Überzeugungstäter Nils Penner in zwei Beiträgen. Hier im zweiten Teil zum Thema Nachhaltigkeit. 

Nils Penner berät die Kund:innen der GfG zum Thema Webentwicklung mit Schwerpunkten wie digitale Inklusion und Nachhaltigkeit.

Teil 1: Inklusive Webentwicklung

Warum ist Inklusion kein Minderheiten Thema und welche Maßnahmen machen wirklich Sinn?

[...]

Was ist das Problem? 

Jedes Mal, wenn wir eine Mail öffnen, eine Website anklicken oder eine App nutzen, verbrauchen wir Strom und produzieren CO2-Emissionen: auf dem Server, auf dem die Anwendung gehostet wird, und auf dem Gerät, auf dem wir sie konsumieren.  

Das Internet, mit allem, was dazu gehört (Webseiten, E-Mails, Apps, Endgeräte jeglicher Art), ist heute einer der größten Stromverbraucher auf unserem Planeten. Schätzungen zufolge wird die IT-Branche schon kommendes Jahr ca. 20 % des gesamten Stroms der Welt verbrauchen und bis zu 5,5 % der weltweiten Kohlenstoffemissionen ausstoßen. Das ist mehr als die Gesamtemissionen der meisten Länder. Und die rasante Entwicklung von Datencentern zum Training und Betrieb von KI bzw. LLMs ist da noch gar nicht vollständig eingerechnet. 

Es gibt große Unterschiede 

Dabei verbrauchen Webanwendungen sehr unterschiedliche Mengen an Strom – je nachdem, wie sie inhaltlich gestaltet und wie sie programmiert sind.  

Ein Bild zum Verständnis: Mit meinem voll aufgeladen Handy kann ich die Startseite eines Online-Magazins mit vielen Bildern und Videos einhundertmal aufrufen, bevor mein Akku leer ist. Die relativ simple blanke Startseite von Google dagegen fünftausendmal.  

Je mehr Daten heruntergeladen und angezeigt werden müssen, desto höher ist der Stromverbrauch. Videos, große Bilder oder der Einsatz mehrerer Tracking Scripts verbrauchen vergleichsweise viel Strom in der Verarbeitung und Darstellung auf dem Endgerät, sowie auf dem Server. 

Eine Website mit einem einfachen Logo, Text und weißem Hintergrund hingegen braucht für die Darstellung vergleichsweise wenig Strom.  

Wer jetzt gerne wissen möchte, wo die eigene Seite in Sachen Ressourcenverbrauch grob steht, kann sie mit einem Tool wie WebsiteCarbon schnell überprüfen lassen: 
https://www.websitecarbon.com/ 

Eine wesentlich tiefer gehende Analyse mit umfassenden Report bietet Ecograder:
https://ecograder.com/ 

Carbon Footprint der Website „Story-Map“, die wir für die GEWOBA umgesetzt haben.

Auch eine Frage von Verantwortung 

Die gute Erkenntnis ist also: Wir können Einfluss darauf nehmen, wieviel Energie eine Website verbraucht. Und diese Möglichkeit sollten wir – gerade auch wenn man bedenkt, wie viele Menschen inzwischen weltweit das Internet nutzen – auch wahrnehmen.

Wir tragen eine Verantwortung für die digitalen Produkte, die wir mit und für unsere Kund:innen erarbeiten. 

Webteam bei einer Besprechung

Wie können wir das umsetzen? 

Was heißt das aber konkret: Machen wir jetzt nur noch weiße Seiten mit Text und ohne Bilder oder Videos? Selbstverständlich nicht. 

Genau hier kommt nachhaltige Webentwicklung ins Spiel. Es geht, wie so oft, erstmal darum, ein Bewusstsein für diese Mechanismen zu schaffen und sie von Anfang an mitzudenken, wenn wir eine Website entwickeln oder überarbeiten.  

Beispielfragen, die wir uns dafür im Prozess stellen:  

  • Brauchen wir hier ein Video oder reicht nicht auch ein Bild oder eine Vektor-Illustration? (Kurzes Video groß eingebunden: 1 bis 3 MB; großes Bild: 300 - 700 kB; Vektor-Illustration: 30 - 100 kB)  
  • Muss es die interaktive Google Map sein, um einen Standort zu zeigen, oder reicht auch ein Bild einer Karte und ein Link zu Google Maps? (Interaktive Karte mit Google Maps JS SDK: ~100 kB, vektorbasiertes Karten-Bild: 10 - 30 kB) 
  • Brauchen wir einen Slider für unsere Bilder oder können wir sie einfach in einer Liste darstellen? (Kein Slider JavaScript: 20 - 50 kB beim Laden gespart und Browser- Performance entlastet)

 

Browser-Mockup einer Website mit Foto im Header
Header-Element mit Foto.
Browser-Mockup einer Website mit Vektor-Illustration im Header
Header-Element mit Vektor-Illustration.

Mal abgesehen davon, dass die Alternativen teils sehr positive „Neben-Effekte“ auf die Verbesserung der User Experience haben, sparen wir mit dieser Art des Hinterfragens ganz konkret Strom und damit Emissionen. 

Unserer Erfahrung nach führen diese Fragen zu deutlich stabilerem, schnellerem und semantisch besser aufgebautem Code. Das kommt dann spürbar der Performance, der Inklusion (bzw. Barrierefreiheit) und der User Experience zugute.  

Eine gemeinsame Grundlage ist wichtig 

Es gibt hilfreiche Methoden wie z.B. das sogenannte „Page Weight Budget“. Das bedeutet, wir als Entwicklungs-Team verständigen uns mit unseren Auftraggebenden auf die Größe einzelner Seiten im Sinne der Datenmenge. Jede Entscheidung im Design und in der Entwicklung wird daran gemessen.  

Wenn wir uns z.B. vornehmen, mit 250 kB initial für eine Startseite auszukommen, wird es sehr schnell eng, wenn wir im Header mit Video arbeiten. Eine moderne Vektor-Animation auf SVG-Basis oder ein Canvas Script wären aber durchaus möglich. 

Gemeinsam mit unseren Kund:innen suchen und testen wir Möglichkeiten – bis wir zu einem Ergebnis kommen, das gestalterisch überzeugend und ressourcenschonend ist. Dabei sind die 250kB nicht in Stein gemeißelt. Die Idee ist, sich dem Ziel der Datenmenge so weit wie möglich anzunähern. 

Static Site Generation und Headless Content Management System

Eine Technologie, die wir für Content-getriebene nutzen, ist „SSG“, kurz für „Static Site Generation“. Dabei werden alle einzelnen Seiten einer Internet-Präsenz als vollständige HTML-Dateien in einem sog. „Build“-Prozess generiert und dann auf einem ggfs. sehr einfach ausgestatteten Webserver abgelegt.  

Wenn ein:e Besucher:in auf die Seite kommt, wird kein serverseitiger Code (PHP, Java, Node.js o.Ä.) mehr ausgeführt. Alle Datenbank-Abfragen etc. sind im „Build“-Prozess erledigt worden und der Browser muss nur noch das HTML/CSS darstellen und ggfs. JavaScript interpretieren. 

Das bedeutet, dass weder der Server, der das CMS hostet, noch ein zugehöriger Datenbank-Server in diesem Moment arbeiten müssen. Dadurch sparen sie Strom ein – und das bei jedem einzelnen Aufruf. Sauber konfigurierte Caching-Lösungen können in gewissen Fällen eine ähnliche Funktionalität bieten.

In der Theorie sind viele Content Management Systeme für ein solches Modell „headless“ einsetzbar. Es lohnt hier aber auf jeden Fall ein Blick auf die Spezialisten, auch wenn dass erstmal nicht die üblichen Verdächtigen wie WordPress oder Typo3 sein mögen.

Aktuell arbeiten wir sehr gerne mit Kirby. Ein sehr flexibles CMS das im Backend komplett modular aufgebaut ist und sich somit wunderbar an verschiedenste Bedürfnisse anpassen lässt.

Ein Beispiel aus der Praxis: die GEWOBA Story Map 

Ein Beispiel für eine solche statisch generierte Seite ist, die von uns für die GEWOBA entwickelte „Story-Map“. Fast 200 Beiträge aus der Welt der GEWOBA sind zu ihrem 100-jährigem Jubiläum in einer Website dargestellt und können – neben dem normalen Zugriff – über QR-Codes und NFC-Chips, die auf Leitsystem-Stelen und Objekten einer Wanderausstellung angebracht sind, direkt aufgerufen werden. 

Zugrunde liegt hier ein Typo3-CMS, das bei der Kundin bereits etabliert war. Typo3 davon zu überzeugen, headless zu funktionieren und doch parallel noch ein Frontend als Vorschau für die Redakteur:innen bereitzustellen, war nicht ganz trivial.

Screenshot von Lighthouse-Testdaten
Lighthouse Test Mobil / Wir haben es geschafft, dass das Typo3-CMS der GEWOBA auch „headless“ funktioniert.
Screenshot von Lighthouse-Testdaten
Lighthouse Test Desktop / Die dadurch eingesparten Ressourcen wirken sich deutlich positiv auf die Performance aus.

Vorstellung des gesamten Projekts: 
https://www.gfg-id.de/stadtentwicklung/100-jahre-jubilaeum-gewoba-bremen.html 

Direkter Link zur GEWOBA Story-Map: 
https://www.gewoba.de/story-map/ 

Ein kurzes Fazit 

Nachhaltiges Webdesign und nachhaltige Webentwicklung sind für uns Ansätze für die Gestaltung digitaler Produkte, bei denen der Mensch und der Planet an erster Stelle stehen. Das bedeutet, dass wir unsere Auswirkungen auf die Welt verstehen und ernstnehmen und mit nachhaltigen Technologien – und gemeinsam mit unseren Kund:innen – einen positiven Impact schaffen. 

Ihr wollt mehr wissen? 

Euch interessiert das Thema nachhaltige Webentwicklung oder ihr betreibt selbst eine Website und wollt wissen, wie diese in Sachen Nachhaltigkeit abschneidet oder weiterentwickelt werden kann? Dann sprecht uns gerne an! 

Kontakt:

Nils Penner
Team Webentwicklung

T 0421 80 71 84 19
penner@gfg-id.de

Teil 1: Inklusive Webentwicklung

Warum ist Inklusion kein Minderheiten-Thema und welche Maßnahmen machen wirklich Sinn?

[...]