INNOQ.com dekarbonisieren

Lucas: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute wollen wir darüber sprechen, wie wir die Webseite innoq.com weniger CO2 intensiv gestaltet haben. Und dazu habe ich mir gleich zwei Leute eingeladen. Einmal die Daphne. Hallo Daphne.

Daphne: Hallo zusammen.

Lucas: Und einmal den Daniel:.

Daniel: Hallo.

Lucas: Ich wollte euch erst einmal kurz vorstellen, bevor wir mit dem Thema anfangen. Daphne, magst du mal anfangen?

Daphne: Hi, ich bin Daphne und ich bin Consultant bei INNOQ und ich habe mich seit längerem im Website Team herumgetrieben. Und das in Ruby on Rails.

Lucas: Cool. Und du, Daniel?

Daniel: Ich bin seit 2013 bei INNOQ und auch seit ein paar Jahren im Website Team aktiv und habe die letzten ein, zwei Jahre vermehrt auch mit dem Thema Nachhaltigkeit in der Softwareentwicklung und IT beschäftigt. Und vor allem im letzten Jahr angefangen, das Thema bei INNOQ ein bisschen zu pushen.

Lucas: Sehr cool. Ihr habt Daniel auch schon zweimal gehört. Wir haben uns nämlich schon mal über das Thema unterhalten. Einmal in der Folge 105 und auch einmal in der Folge 114. Da haben wir über nachhaltige Softwareentwicklung und nachhaltige Web Architektur gesprochen. Wenn ihr die Folge noch nicht gehört habt, dann ist es aber auch nicht schlimm. Wir setzen das nicht voraus, dass ihr das alles mitgehört habt. Aber wir werden auch nicht die Sachen alle wiederholen, die wir da erzählen, weil heute wird es ein bisschen praktischer. Die Folgen waren ein bisschen theoretischer, ein bisschen abstrakter. Und jetzt wollen wir mal konkret über einen Fall reden, wie man das denn bei so einer Webseite hinbekommt. Aber bevor wir jetzt auf die Seite eingehen, würde ich einmal noch mal kurz auf die Motivation eingehen. Wenn man jetzt überlegt, man möchte als Firma dafür sorgen, dass man weniger CO2 verursacht, ist da die Webseite so direkt der erste Ort? Ist das das, was am meisten verursacht? Oder wie schätzt ihr das ein? Daniel.

Daniel: Nein, die Website ist auf keinen Fall der größte CO2-Emittent bei INNOQ als Firma. Wir haben auch schon einige andere Dinge getan. Zum Beispiel haben wir in allen Büros auf Ökostrom umgestellt. Wir haben auch zum Teil intelligente Heizsysteme in Büros. Viele von uns reisen auch mittlerweile nicht mehr oder kaum noch mit dem Flugzeug, sei es jetzt zu internen Veranstaltungen, zu Kunden oder auch zu Konferenzen, sondern nehmen dann den Zug. Und wir machen noch mehr remote natürlich. Von daher haben wir auch viele andere Dinge getan, mit dem man wahrscheinlich deutlich mehr CO2 Emissionen vermeiden kann. Aber die Website trägt natürlich trotzdem auch ihren Teil zu den Gesamtemissionen bei. Da man dort was einsparen kann, haben wir uns gedacht, sollte man das auch tun, egal wie klein der Anteil vielleicht sein mag.

Lucas: Und wie viel ist das? Was habt ihr eingespart? Wieviel war es vorher? Wie viel war es nachher, Daniel?

Daniel: Wir haben die CO2 Emissionen, die die Website verursacht, natürlich nicht ganz präzise messen können, sondern anhand eines Models annäherungsweise schätzen müssen. Aber demnach hätten wir in den letzten zwölf Monaten, das war Stand Juli 2022, 180 Kilo an CO2 Äquivalenten emittiert, die durch die Website verursacht sind. Wir haben ein paar Maßnahmen umgesetzt nach Juli 2022 bis November 2022. Und haben dann noch mal mit dem gleichen Modell noch mal geschaut: Was hätten wir dann verbraucht, wenn wir diese Maßnahmen schon für diese Seitenaufrufe gehabt hätten? Dann wären wir noch auf 96 Kilo an CO2 Äquivalenten gekommen. Es ist also eine Einsparung von fast 50%. Man kann sich vorstellen, das entspricht ungefähr einer Fahrt von Berlin nach Oldenburg mit einem Benziner oder einem Flug von Kopenhagen nach München, was wir da also eingespart haben.

Lucas: Sehr cool. Da kann man sich vorstellen, dass das jetzt nicht der größte Teil ist, den INNOQ irgendwie ausstößt. Aber ich persönlich finde, es ist immer wichtig, nicht in diese Falle zu tappen und zu sagen, etwas ist ein kleiner Gewinn, deswegen lohnt es sich nicht, den zu machen, weil die großen Gewinner sind meistens die, die auch wesentlich schmerzhafter sind. Dann ist es auch ein bisschen so eine Frage. Wenn man mit relativ wenig Aufwand eine kleine Einsparung machen kann, dann ist es schon mal gut. Weil schlussendlich müssen wir quasi auf Null kommen, weil alles was darüber ist, müssen wir irgendwie ausgleichen. Und diese Technologien sind auch noch nicht so richtig ausgereift. Deswegen ist es auf jeden Fall eine gute Idee, alles, was nicht notwendig ist, aufs Minimum zu reduzieren. Aber um das jetzt trotzdem mal irgendwie in Vergleich zu setzen. Wenn ich mir vorstelle, man würde diese Arten von Techniken auch auf andere Sachen anwenden, dann würde man vielleicht auch in dem gesamten Internetsparte was sparen. Was ist denn da so das Potenzial? Wie viel CO2 Äquivalente verursacht denn aktuell die Internetsparte oder die digitale Welt, Daphne?

Daphne: Zurzeit macht die digitale Welt etwa 4% der Treibhausgasemissionen aus und das sind ungefähr 5,5% des Stromverbrauchs, also global betrachtet. Und diese Tendenz ist steigend. Bis 2030 wird ein Anstieg um bis zu 21% weltweit erwartet, zumindest was den Stromverbrauch angeht. Und das entspricht auch einem Anstieg von 2.000 Terawattstunden auf 8.000. Und das geht natürlich auch mit einem Anstieg der CO2 Emissionen einher. Und vor allem dann, wenn der Strommix nicht weiter nennenswert weniger CO2 intensiv ist. Wenn wir nicht weiter in grüne Energie investieren. Wenn man das mit anderen Sektoren vergleicht, da haben wir mal versucht, etwas Vergleichbares auch herauszufinden, was das eigentlich bedeutet, um das mal so ein bisschen konkreter zu machen. Und da haben wir zumindest herausgefunden, dass das Gebäude 9% der Emissionen ausmachen. Und wir haben uns gefragt: Worauf könnte es bezogen sein, weil das nicht näher spezifiziert wurde? Aber wir vermuten, dass es sich dabei um Emissionen bei zum Beispiel dem Bau und den Materialien handelt. Und das Heizen wäre dann vermutlich Teil der Energieindustrie, die dann noch mal separat gemessen wird. Und ich finde, das ist schon eine krasse Relation, wenn die digitalen Emissionen quasi die Hälfte der Gebäudeemissionen ausmachen. Und Wohnen ist auch so ein essenzielles Ding, genauso wie der Zugang zu Informationstechnologie. Und beides sind Sektoren, die wachsen werden und die wir immer mehr brauchen und auch in Anspruch nehmen.

Lucas: Definitiv. Ich glaube, das ist einfach wichtig im Kopf zu behalten, weil das hatten wir glaube ich auch in eine der anderen beiden Folgen besprochen, Daniel, dass diese CO2 Verursachung so ein bisschen unsichtbar ist. Man kriegt das nicht so alles mit, was das bedeutet, gerade wenn man irgendwie auf seine Stromrechnung guckt. Der Großteil von dem, was man so an Internet CO2 verursacht, ist nicht das, was man auf der Stromrechnung nachher bei sich sieht, weil man dann irgendwie auf einen grünen Tarif wechselt, dann ist das leider nur ein Teil von der ganzen Rechnung. Weil wenn man Netflix schaut, verursachen die auch Strom in ihren Rechenzentren.

Daniel: Ja, genau. Du meinst, wenn man als Endverbraucher:in schaut?

Lucas: Genau, das meine ich.

Daniel: Ja, das ist tatsächlich so, dass bei Tablets zum Beispiel die Emissionen, die beim Verbrauch verursacht werden durch Laden des Akkus, machen da wirklich nur einen ganz geringen Teil aus im Vergleich zu dem, was man an CO2 Emissionen verursacht bei Server, Netzwerkinfrastruktur usw.

Daphne: Genau. Nur ganz kurz zu Netflix, wo du das gerade so einwirfst. Mich hat das Ganze auch total sensibilisiert, wenn ich einfach so YouTube Videos aufrufe. Ich habe da so ganz oft, dass ich vielleicht einfach etwas laufen lasse, wo mich die Audiospur eigentlich eher interessiert, und dann wird das irgendwie in HD mindestens standardmäßig ausgeliefert. Und da habe ich dann auch mal genauer reingeschaut, auch in die Browser Console und geschaut, was da eigentlich so passiert. Und es ist eigentlich total unnötig für meine Use Cases. Und dann habe ich auch tatsächlich mal angefangen, die Qualität bewusst auch runterzustellen, weil ich es gar nicht gucke. Ich persönlich habe da einfach wenig Mehrwert, wenn ich dann einfach noch ein Video bekomme. Aber das fand ich auch eine interessante Beobachtung in meinem Internetkonsum.

Lucas: Ja, ich finde es auf jeden Fall auch eine sehr interessante Sache, dass wenn man bei YouTube die Videospur ausschalten möchte, also nur die Audiospur haben möchte, muss man das Premium von YouTube kaufen, was irgendwie ironisch ist. Aber egal. Auf jeden Fall sehe ich das auch als eine Herausforderung. Aber wir machen gar nicht so viel mit Videos bei INNOQ. Wir haben ja doch eher eine Informationsseite, die viel mit Text, aber auch viel mit Bildern arbeitet. Wie war denn der Stand, bevor wir damit losgelegt haben, Daphne?

Daphne: Wir waren eigentlich schon im Sommer, als wir damit angefangen haben, das Thema Nachhaltigkeit bewusst zu implementieren und bewusst zu reflektieren, schon ganz gut aufgestellt. Wir haben da schon ein paar Techniken angewandt, hatten dabei aber erstmal andere Ziele. Erstmal hatten wir andere Qualitätsziele. Wir wollten unsere Performance steigern, also die Performance der Seite. Wir wollten auch die Accessability verbessern und natürlich auch Datenschutzmaßnahmen implementieren. Und Nachhaltigkeit war da erst mal gar nicht so unser primäres Ziel. Aber wir haben dann festgestellt, während wir das alles gemacht haben, dass sich das eben auch positiv auf unsere CO2 Effizienz ausgewirkt hat. Und angefangen haben wir zum Beispiel mal zu schauen: Wo liegen wir denn mit unserem JavaScript, dass wir so ausliefern? Und da haben wir gesehen: Wir liegen laut Web Almanac 2022 im untersten 10er Perzentil und liefern zum Beispiel komprimiert nur 35 Kilobyte JavaScript aus. Und im Durchschnitt in diesem Perzentil werden bis zu 87 Kilobyte ausgeliefert. Und das war dann schon eine ziemlich gute Bilanz, dass wir da so gut aufgestellt sind. Und der Median liegt zum Beispiel auch bei 460 Kilobyte, also da sind wir weit, weit drunter. Und wir haben auch noch eine ganze Reihe andere Dinge gemacht.

Lucas: Aber kurz zu dem JavaScript. Weil du darauf jetzt eingehst. Warum ist das relevant, wie viel JavaScript man hat? Ist JavaScript besonders schlimm oder wie?

Daphne: Ganz, ganz schlimm (lacht) Es ist so, einerseits, wenn viel JavaScript ausgeliefert wird, das ist immer ein Nebeneffekt, wird natürlich das Netzwerk belastet. Aber viel wichtiger ist eigentlich, was auf dem Endgerät passiert. Und zwar hat der Web Almanac zum Beispiel festgestellt, dass es im Vergleich zum Jahr 2021 einen Anstieg von ungefähr 8% gab und dass sich die Menge an ausgelieferten JavaScript für mobile Anwendungen, an die für Desktop Anwendungen annähert. Und das ist natürlich eine Belastung für das Endgerät, weil die Verarbeitung von JavaScript auf dem Endgerät einfach mehr Energie verbraucht als zum Beispiel das Rendern von HTML oder CSS. Und das wirkt sich natürlich auf Dauer auch auf die Akkulebensdauer aus und letztendlich auch auf die Lebenszeit des Endgeräts. Und wenn wir davon wegkommen wollen, alle zwei Jahre ein neues Smartphone anzuschaffen. Ich weiß auch gar nicht, wer das festgelegt hat, dass es alle zwei Jahre sein muss, dann müssen wir da eben auch optimieren und effizienter damit umgehen und uns überlegen: Brauchen wir das an der Stelle oder können wir das auch mit anderen Mitteln erreichen?

Lucas: Definitiv, ja. Man merkt das, wenn man eine gängige Webseite mit einem älteren, vielleicht auch Budget Smartphone aufruft. Da merkt man schon, dass dann manchmal das Scrollen stottert, weil da irgendwie doch viele Sachen noch im Client passieren. Das fällt einem dann nicht so auf, wenn man das allerneuesten iPhone Pro benutzt. Da wird das alles einfach weg gerechnet von dem Super Prozessor. Aber gerade, wenn man dafür sorgen will, wie du sagst, dass man eben diese alten Geräte auch weiterhin noch benutzen kann… Ältere, was heißt das denn? Vier Jahre. Das ist jetzt auch nicht super alt. Dann muss man einfach dafür sorgen, dass die Webseite eben auch auf solchen Geräten immer noch performant funktioniert. Das ist, glaube ich, tatsächlich vielleicht sogar noch die größere Auswirkung im Endeffekt, dass man eben die Geräte länger benutzen kann. Aber damit wollen wir auf jeden Fall nicht sagen, dass ihr kein JavaScript benutzen sollt. Das ist mir immer wichtig, da mal kurz zu betonen. Aber man sollte einfach noch mal darüber nachdenken, an welchen Stellen das sinnvoll ist. Und gerade eine Webseite wie unsere, die ist eine Informationsseite, die Informationen überträgt. Da kann man sich überlegen, wie viel JavaScript braucht die eigentlich, um das zu machen? Wenn man jetzt Miro baut oder Figma oder so, ist es irgendwie klar, dass man da mehr JavaScript braucht, aber dann muss man es auch eher schon mit einer Desktop Anwendung vergleichen, die das dann verbrauchen würde. Vermutlich ist die Desktop Anwendung dann trotzdem noch effizienter, weil sie anders implementiert ist. Aber das ist dann der Vergleich, den man da machen sollte. Nicht, dass das in den falschen Hals gerät.

Daniel: Das ist dennoch erstaunlich. Der Median von ein paar 100 Kilobyte JavaScript sieht man sehr oft auch bei solchen Informationsseiten, wo man sich fragt: Wofür wird das jetzt hier gebraucht?

Lucas: Absolut. Das hatten wir auch zum Beispiel in einer anderen Folge besprochen. Die Homepage von Angular, die einfach fünf Textblöcke ausliefert, die führt schon jede Menge JavaScript aus, um diese fünf Textblöcke anzuzeigen. Und da sollte man sich einfach mal die Frage stellen, ob ein Blog oder so eine Seite tatsächlich so viel JavaScript braucht oder ob er vielleicht auch mit Progressive Enhancement arbeiten kann, um das vielleicht ein bisschen schlauer zu machen. Neben dem JavaScript haben wir aber auch andere Sachen gemacht, zum Beispiel mit den Bildern. Daniel, kannst du da was zu den Bildern erzählen?

Daniel: Ja, klar. Wir haben eine Reihe von CSS Hintergrundbilder. Da haben wir ein bisschen was optimiert. Und im Wesentlichen erst einmal eigentlich alle Bilder von JPEG zu WebP konvertiert, was ein moderneres Format ist und etwas stärker komprimiert. Das hat schon zu relevanten Einsparungen in der Dateigröße geführt. Das konnten wir natürlich machen, weil wir geschaut haben, wie stark mittlerweile die Verbreitung von diesem Format ist. Da kann man auf caniuse.com ganz schön schauen, eigentlich für jedes Webfeature, wie stark das verbreitet ist. Wir hatten schon gesagt, dass es sinnvoll ist, auch noch ältere Geräte zu unterstützen. Das heißt natürlich eigentlich oft auch, dass man nicht immer die neuesten Sachen nutzen kann. In diesem Fall ist WebP aber so stark verbreitet tatsächlich, dass wir da ruhigen Gewissens für diese Hintergrundbilder exklusiv auf WebP gehen konnten. Bei anderen Bildern, die jetzt zu unserem redaktionellen Content gehören, da nutzen wir ein Image CDN namens Cloudinary. Da werden die Bilder in verschiedenen Formaten dann bereitgestellt, je nachdem, was der Browser unterstützt. Das wird dann in den meisten Fällen auch als WebP ausgeliefert. Aber wenn doch noch mal jemand mit einem Uralt-Browser kommt, würden diese Bilder dann zum Beispiel als JPEG ausgeliefert.

Lucas: Da finde ich auch noch eine Sache wichtig zu betonen: Wenn man neuere Features benutzt, dann ist das jetzt erst mal grundsätzlich kein Grund, warum man ältere Geräte nicht mehr benutzen kann. Das sind zwei unabhängige Dinge aus meiner Sicht. Da ist es auch die Verantwortung von vor allem Apple und Google, dafür zu sorgen, dass auch ältere Geräte eben die aktuellen Browser bekommen. Weil auch WebP ist jetzt nicht etwas, was ein älteres Gerät nicht könnte, sondern der einzige Grund, warum es das nicht kann ist, weil es vielleicht keine Updates bekommt auf einen Browser, der es unterstützt. Und darauf haben wir natürlich nicht so direkt Einfluss. Aber ich wollte einfach nur mal das auseinanderhalten, weil ich finde es wichtig, das im Hinterkopf zu behalten. Leider ist es eben so, gerade wenn man über iOS spricht, dass dort die Version des Browsers an die Version des Betriebssystems gebunden ist. Und dadurch ist das eben nicht ganz wahr. Das ist eben bei Android meines Wissens anders, wo man beispielsweise den Chrome updaten kann, obwohl man vielleicht ein älteres Android hat, weil das Apps sind, die man aktualisieren kann. Aber da haben wir nicht so viel Einfluss drauf.

Daniel: In der Realität ist es eben doch nicht so. Wenn ich neue Features benutze, schließe ich manchmal doch Leute aus, die noch auf älteren Geräten sind, weil sie die neueren Browser nicht bekommen.

Lucas: Das müsste nicht so sein. Das ist mein Hauptpunkt. Das ist nicht etwas, was zwangsläufig so ist, sondern das liegt einfach daran, wie das die Hersteller der Telefone und Betriebssystemen machen.

Daniel: Genau. Aber noch mal zurück zu den Bildern. Cloudinary als Image CDN benutzt dann auch Fingerprinting auf diesen Bildern. Das heißt, ein Bild hat eigentlich immer eine einzigartige URL, die sich nicht ändert, wenn sich das Bild ändern würde, zum Beispiel. Und dadurch kann es eben auch super lange gecached werden, was Cloudinary auch mit seinen Cache Controller Headern so macht. Es sorgt dann auch dafür, dass tendenziell eher wenige Daten überhaupt übertragen werden müssen, wenn Leute wiederholt die Seite aufrufen. Außerdem hilft uns Cloudinary damit responsive Images auszuliefern, weil es das sehr leicht macht, so beliebige Transformationen auf den Bildern über URL-Parameter anzufordern. Und so können wir dann für Mobilgeräte zum Beispiel deutlich kleinere Bilder ausliefern, ohne dass wir da jetzt einen super komplexen Buildprozess für haben, wo wir uns erst alles schon vorberechnen müssen, welche Bilder wir in welchen Größen haben wollen. Das hatten wir so an Bildoptimierung eigentlich aus Performance Gründen gemacht. Das sorgt aber natürlich auch dafür, dass wir die Emissionen reduzieren.

Lucas: Cool. Und wie laden wir die Bilder? Da gibt es auch verschiedene Möglichkeiten, damit umzugehen, dass die vielleicht nur dann geladen werden, wenn sie auch benötigt werden. Wie haben wir das gemacht, Daniel?

Daniel: Ohne JavaScript. Da gibt es auch beliebte Lösungen, wahrscheinlich auch aus der Zeit, als es noch nicht anders möglich war, so ein Lazy Loading über JavaScript zu implementieren. Wir nutzen aber das „loading“ Attribut aus dem HTML Standard, wo man den Wert „lazy“ übergeben kann und das ist ein Hint an den Browser, zu sagen: Die Bilder sollen nicht geladen werden, wenn sie nicht zu sehen sind. Sondern erst, wenn man in den Viewport reinscrollt und das Bild zu sehen ist, bzw. kurz davor wahrscheinlich würde der Browser das machen. Ist wie gesagt ein Hint und der Browser entscheidet, wann er dann genau ein Bild lädt. Wir nutzen das Lazy Loading Attribut bei redaktionellen Inhalten eigentlich überall. Bei anderen Bildern, die jetzt nicht zum redaktionellen Content gehören, tun wir das natürlich nicht, weil wir genau wissen, zum Beispiel, ob ein Bild schon im Viewport ist. Dann sollten wir es nämlich nicht lazy laden. Das wäre sogar nachteilig für die Performance. Bei dem redaktionellen Inhalt können wir das jetzt natürlich nicht genau sagen, wann ein Bild schon im Viewport standardmäßig ist. Deswegen sind die alle mit diesem Attribut versehen. Und für einzelne Bilder ist das dann vielleicht zwar nachteilig, aber insgesamt heißt das, dass wir viel weniger Bilder schon sofort laden, wenn sie vielleicht sogar nie zu sehen sein werden, weil ein Besucher den Blogpost, den ich geschrieben habe, so langweilig findet, dass er gar nicht runter scrollt.

Lucas: Das wollen wir nicht hoffen.

Daniel: Wir haben auch noch andere Use Cases für dieses Attribut. Da kommen wir vielleicht nachher noch mal drauf.

Lucas: Ich finde es auch deswegen wichtig, weil es kann auch mal sein, dass jemand einen Artikel aufmacht und sagt: So, der ist ganz schön lang. Ich lese ihn später, macht ihn zu und macht ihn dann später auf einem anderen Gerät auf. Dann ist es Quatsch, auf dem Gerät schon alle Sachen herunterzuladen. Ich lese zum Beispiel längere Artikel lieber auf dem Tablet als auf dem Telefon. Dann sehe ich, es ist ein langer Artikel, dann mache ich den zu und mache ihn auf dem Tablet auf und dann werden die Bilder nochmal heruntergeladen. Das ist eigentlich auch Quatsch. Aber ein anderes Thema als Bilder ist noch dieser ganze Themenblock von Third Party Content. Das ist auch etwas, was man auf Seiten auch relativ oft findet. YouTube Videos oder Slide Decks, die man von einer anderen Seite einbindet. Wie sind wir damit umgegangen, Daphne?

Daphne: Ja, genau. Da haben wir auch die Strategie der Consent Abfrage implementiert. Wir haben so ein Consent Banner und den muss man natürlich erst dann aktivieren, um die Inhalte dann zu sehen. Und das machen wir bei YouTube Videos, zum Beispiel wenn wir Vorträge verlinken, die mal gehalten worden sind oder auch bei Twitter Cards von Kollegys, die irgendwo embedded werden. Und da muss erst durch explizites Anfordern von dem User oder der Userin dieser Content dann nachgeladen werden. Speaker Deck haben wir mal benutzt, aber jetzt nicht mehr und haben dafür ein eigenes Element gebaut, unseren Slide Viewer. Und da benutzen wir auch die Lazy Loading Strategie. Das war die einfachste Strategie, wird vom Browser nativ unterstützt, wie Daniel auch schon erklärt hat. Und das hat für unsere Zwecke total ausgereicht.

Daniel: Es gab hier auch keine andere Motivation. Bei den Twitter und YouTube Videos Embeds ging es auch um Privacy, um das Vermeiden von Tracking, weil externes JavaScript usw. geladen wird.

Lucas: Aber das ist bei Speaker Deck auch erst mal so, oder?

Daniel: Genau, aber wir haben kein Speaker Deck mehr.

Lucas: Ja, genau, das stimmt.

Daniel: Wir haben nun eine eigene Lösung, wo die Folien bei uns gehostet sind.

Lucas: Ja, cool. Wo wir jetzt gerade so einen Podcast aufnehmen. Im Bereich der Podcasts haben wir auch eine relativ einfache Maßnahme, meiner Meinung nach. Wir haben Transkripte. Da war unser Ziel eigentlich immer hauptsächlich Accessability, weil manche Leute Podcast Folgen nicht hören können, entweder in der Situation, in der sie gerade sind oder allgemein nicht hören können oder das einfach auch bevorzugen. Manche Leute lesen lieber als sie hören. Das ist auf jeden Fall ein Accessability und auch darüber hinaus einfach ein Usability Feature aus meiner Sicht. Ist aber auch sehr praktisch, wenn man auf der Website sucht: In welcher Folge habe ich noch mal bei Redis gesprochen? Dann kann man da Redis eintippen und dann wird das im Transkript gefunden und zack ist es halt da. Das geht eben bei Audio schlechter. Wenn Leute das Transkript lesen statt zu hören, dann laden sie keine große MP3 oder AAC Datei runter. Das ist eben auch ein Vorteil. Und als letztes haben wir hier noch aufgeschrieben, die Durchsuchbarkeit allgemein, Daniel. Was hattest du dazu noch im Kopf?

Daniel: Wir hatten auch, bevor wir uns explizit um die Nachhaltigkeit der Website gekümmert haben, angefangen unsere Tags, die wir an Inhalte dranheften, etwas umzustrukturieren, damit Leute die Inhalte besser finden können, den wir auf unserer Website bereitstellen. Das Ziel war, dass unnötige Requests natürlich vermieden werden, wenn man die Inhalte schneller findet, nach denen man sucht. Und dadurch können natürlich dann auch Emissionen vermieden werden. Man muss aber sagen, wir haben uns mal angeschaut, dass diese Tags tatsächlich nicht besonders viel bisher genutzt werden, auch wenn wir die bereitstellen. Das ist also ein Feature, was wir zwar gebaut haben, was aber in der Praxis tatsächlich bisher noch nicht so viel Verwendung findet. Außer natürlich für Suchmaschinen. Für die ist das eine gute Sache, diese Topic oder Tag Übersichtseiten. Die helfen uns in der Hinsicht schon insgesamt besser gefunden zu werden.

Lucas: Okay, gut. Das waren jetzt die Sachen, die passiert sind, bevor wir losgelegt haben, explizit darauf zu optimieren. Aber kannst du, Daniel noch mal kurz erklären, wo wir dann standen und wo vielleicht auch die Grenzen unserer Möglichkeiten, das zu erfassen waren oder sind?

Daniel: Ich hatte schon zu Beginn gesagt, dass wir mal bei 180 Kilogramm CO2 Äquivalenten für die Page Views der letzten zwölf Monate standen. Und die Frage ist natürlich: Wie kommen wir auf diese 180 Kilogramm? Wir haben das Tool Website Carbon Calculator als Grundlage genommen. Das habe ich, glaube ich, auch schon einmal in einer anderen Folge erwähnt. Dieses Tool hat als Grundlage die Page Weight der Seite. Also im Grunde die Anzahl an Kilobyte, die übertragen werden, wenn ich die Seite aufrufe. Es bezieht aber auch Emissionen in Rechenzentren und auf Endgeräten ein und sogar auch Embodied Carbon in der beteiligten Hardware. Und es berücksichtigt auch, dass Menschen eine Seite wiederholt aufrufen. Aber es ist trotzdem ein Modell, das bei bestimmten Faktoren mit Durchschnittswerten arbeiten muss. Zum Beispiel verwendet es für die Ermittlung der Emission für einen Seitenaufruf die durchschnittliche globale CO2 Intensität. Und es hat einen hart kodierten Faktor, wie hoch der Anteil der Wiederholungsaufrufe an allen Aufrufen für eine Seite ist. Und auch, wie groß die Datenmenge bei einem Wiederholungsaufruf im Vergleich zu einem Erstaufruf ist. Das sind hart kodierte Faktoren. Wir könnten eigentlich über unser Analytics Tool herausfinden, wie hoch die Anzahl der Wiederholungsbesuche tatsächlich ist. Und wir könnten auch herausfinden, wie viele Daten wir bei einem Wiederholungsbesuch einsparen. Das ist hier nicht berücksichtigt. Das sind die Grenzen dieses Website Carbon Calculator. Man könnte die Emissionen also deutlich genauer noch ermitteln, wenn man wollte, zum Beispiel mit der Library CO2.js. Die kann bisher diese Faktoren, die hart codiert sind, im Website Carbon Calculator auch nicht überschreiben, aber es wird gerade daran gearbeitet, dass man da mehr konfigurieren kann und dann könnte man präzisere Aussagen treffen. Man weiß dann immer noch nicht, wie effizient man zum Beispiel auf seinem Server bestimmte Sachen berechnet. Wir sind mit Ruby on Rails unterwegs. Das ist möglicherweise nicht so effizient, wie wenn wir das in Rust geschrieben hätten. Wobei es eigentlich keine großen Berechnungen bei uns gibt. Es geht im Wesentlichen darum, Daten aus einer Datenbank zu holen. Von daher glaube ich, dass das nicht so der Hauptgrund für höhere Emissionen wäre. Aber theoretisch könnte man natürlich komplizierte Berechnungen in einer Webanwendung im Backend haben. Die kann man sehr ineffizient oder sehr effizient machen. Und das könnte dieser Website Carbon Calculator nie merken, wie effizient das jetzt.

Lucas: Wir kommen da bestimmt nachher noch mal darauf zurück. Aber theoretisch hätte man auch einen statischen Seitengenerator für die Webseite benutzen können, dann hätte man noch weniger Berechnungen. Aber das kann ein Tool von außen ja nicht sehen, was da genau passiert. Gut, dann haben wir so ungefähr den Stand. Wir haben um die 180 Kilo jährliche Emissionen geschätzt und dann ging das Projekt los. Daphne, wie habt ihr denn da losgelegt?

Daphne: Daniel hat ja gerade von den meist aufgerufenen Seiten gesprochen und eine dieser meist aufgerufenen oder High Impact Seiten ist natürlich unsere Startseite. Und da haben wir dann überlegt: wie können wir die denn optimieren? Denn wir hatten da längere Zeit ein 3D Video, das in Kooperation mit einem Medienkünstler entstanden ist. Und dann haben wir uns überlegt: Vielleicht nehmen wir einfach dieses Video runter und ersetzen das durch ein statisches Bild. Und vor dieser Maßnahme war die Seite ungefähr 8 MB groß. Und nachdem wir dann dieses Video runtergenommen und durch ein Bild ersetzt haben, haben wir ungefähr 25% page weight eingespart. Um die 2,3 MB konnten wir dadurch sparen. Und natürlich haben wir das Hintergrundbild auch vorher noch mal ein bisschen getweakt. Das CSS Hintergrundbild haben wir dann auch noch vorher von JPEG zu WebP konvertiert und konnten da noch mal so eine zweistellige Einsparung in der Dateigröße mit erreichen. Das war so eine radikale Maßnahme. Da fragt man sich auch: Und was sagt die Marketingabteilung dazu? Aber tatsächlich war es bei uns so, dass Head of Marketing das Ganze mit abgesegnet hat.

Lucas: Cool. Aber ich finde, das ist auch ein sehr gutes Beispiel für eine Maßnahme, wo man merkt, dass man als Person, die jetzt nur in der Entwicklung tätig ist, nicht alle Entscheidungen einfach treffen kann, die da großen Impact machen. Man muss dann schon mit anderen Leuten zusammenarbeiten, mit der Marketingabteilung und an anderen Stellen, um zu überlegen: Was bedeutet das eigentlich für uns, wenn wir jetzt hier was Kleineres ausliefern? Das muss nicht schlechter sein. Es muss nur vielleicht was anderes sein.

Daniel: Grundsätzlich war unsere Strategie natürlich schon zu schauen: Welche Seiten werden am meisten besucht und haben die größten Emissionen? Die dann als erstes anzugehen, weil man da den größten Impact hat. Aber natürlich spielte auch eine Rolle: Wie einfach lässt sich das denn ändern? Lässt es sich überhaupt ändern oder gibt es da irgendwelche Constraints warum wir das nicht ändern können, weil Marketing nein sagt.

Daphne: Technisch war das wirklich kein großer Aufwand. Das stimmt.

Lucas: Aber da merkt man, dass die Maßnahmen, die nachher viel bringen, nicht unbedingt aufwendig sind. Sondern vielleicht ist es auch einfach nur eine Frage von Priorität oder auch Kreativität. Vielleicht findet man ja auch was, was weniger verbraucht, aber trotzdem cool ist. Ich könnte mir vorstellen, dass man vielleicht an bestimmten Stellen vielleicht ein cooles CSS Art einbaut, was nachher weniger verbraucht als ein riesiges JPEG oder PNG Bild oder so was. Das kann man sich auch vorstellen. Okay, aber habt ihr denn da jetzt Ziele definiert und gesagt: Das wollen wir erreichen oder wie habt ihr das gemacht, Daphne?

Daphne: Wir haben da jetzt keine, wie man das so macht, Smart Ziele definiert. Wir haben uns nur angeschaut: Was brauchen wir denn wirklich und wo können wir quasi Schrauben drehen? Und natürlich dann auch im Kontext, der meist aufgerufenen Seiten, wie gesagt. Und haben dann mal geschaut, was es da so gibt. Und neben diesem Startseitenvideo haben wir dann auch gesehen, zum Beispiel unsere Podcasts sind beliebt. Und da haben wir dann gemerkt: Da gehen wir auch irgendwie ineffizient vor, weil in jeder Vorschau pro Folge gibt es angeschnittene Porträts der Sprechenden. Und da haben wir dann festgestellt: Wir holen jedes Mal das Bild von neuem, also machen jedes Mal neue Requests und legen diese Bilder dann auch noch mal ab. Wir speichern das alles doppelt und dreifach. Und da haben wir dann zum Beispiel auch angesetzt und haben uns stattdessen diese Porträts aus einem Staff Member Model unserer Datenbank geholt, wo das dann einmal abgelegt ist und konnten uns dadurch eben diese Mehrfach-Requests und diese Speicherplätze dadurch auch sparen. Und dadurch haben wir auch noch mal eine große Einsparung erzielt. Daniel, hast du gerade die Zahl parat?

Daniel: Nein, leider nicht, aber ich glaube, es war schon so ein Faktor von irgendwas zwischen zwei und vier, wenn ich das richtig in Erinnerung habe. Das waren zwei Maßnahmen. Und was Daphne gesagt hat, dass wir diese Bilder de-dupliziert haben. Besonders Lucas, du tauchst da sehr häufig auf und da war es immer das gleiche Bild von dir, was aber unter der unterschiedlichen URL geladen wurde. Das andere war, dass wir bei der Episodenübersicht eine Paginierung eingebaut haben, weil vorher sämtliche, über 100 Folgen mittlerweile, auf einer Seite geladen wurden. Es war schon sehr viel. Da haben wir jetzt eine Paginierung. Die neuesten sind erst mal 10 oder 20, ich weiß ich nicht, wie viel wir da gerade laden. Beide Maßnahmen zusammen haben das wirklich deutlich reduziert.

Daphne: Ich habe es gefunden. Wir haben 88% der Emissionen eingespart.

Lucas: Okay, das ist wirklich viel.

Daphne: Genau, das ist der Punkt, an dem ich mich selber total gewundert habe. Stimmt das so? Stimmt unsere Grafik? Das ist ja total krass. Das hat sich sehr gelohnt.

Lucas: Erst mal danke, dass ihr meinen Footprint verbessert habt, dadurch das ich nicht so oft ausgeliefert werde. Aber das andere, was ich daran auch interessant finde, ist, dass es auch eine Auswirkung hatte, die subtil ist, aber trotzdem da ist, nämlich dass es vorher so war, dass wenn sich das Avatar Bild einer Person über die Zeit verändert, das dann in den alten Folgen das alte Bild da war und in den neuen Folgen das neue Bild. Und jetzt ist es eben so, dass man in allen Folgen das aktuelle Bild bekommt. Erst mal möchte ich betonen, ist es einfach kein Refactoring ist, weil es ist nicht exakt dasselbe Outcome, was dabei passiert. Aber man muss dann überlegen, ob das gut oder schlecht ist. Da sieht man, dass ich bei den Folgen, obwohl ich da noch gar kein Bart hatte, dann auf einmal einen Bart in den Folgen. Das ist dann so. Aber das wollte ich nochmal betonen, weil manchmal muss man auch darüber nachdenken, ob so eine subtile Verhaltensänderung der Webseite akzeptabel ist oder nicht. Und da sind wir dann wieder in diesem Bereich, wo man dann vielleicht auch mal mit anderen Stakeholdern spricht. Bei uns ist es tatsächlich sehr einfach, weil die Marketingabteilung ist Teil des Webseiten Teams. Die arbeiten Hand in Hand, aber wenn man sich jetzt eine Firma vorstellt, wo das vielleicht zwei unterschiedliche Teams sind, muss man das einfach im Hinterkopf behalten, dass es da dann einen Abstimmungsaufwand gibt zu schauen: Ist das in Ordnung? Können wir das so was machen oder geht das nicht? Bei der Sache würde wahrscheinlich jetzt keiner nein sagen, aber es könnte ja trotzdem sein.

Daniel: Ja, es könnte ja Gründe dafür geben, warum man dann die alten Bilder, die ursprünglich mal dran waren, an den Folgen, haben will. Es gibt eben auch Vorteile, dass es insgesamt konsistenter wirkt.

Daphne: Wenn man irgendwie einen Staffelübergang visuell kommunizieren möchte.

Lucas: Stimmt. Guter Punkt. Oder wenn man zum Beispiel auch den Stil seiner Bilder verändert. Das würde dann auch auf die Alten zutreffen und das muss man dann auch überlegen, ob das passt. Podcast Seiten konnten wir ganz schön stark optimieren mit einer gefühlt relativ kleinen Maßnahme. Das finde ich auch immer eine Sache, die einem Mut gibt, dass man jetzt nicht Tage investieren muss, um da was einzusparen, sondern das ist gerade so der Punkt für uns am Anfang gewesen, dass obwohl das natürlich jetzt relativ gesehen wenig CO2 Ausstoß ist, dafür auch die Maßnahmen, um das zu verhindern, eben kleiner sind, weil sein Auto durch ein Elektroauto zu ersetzen ist wesentlich aufwändiger als das, was wir hier gemacht haben. Und das finde ich, irgendwie muss man das auch nochmal im Hinterkopf behalten. Eine andere Maßnahme, die wir da ergriffen haben, waren die Caching Header zu verbessern. Daniel, was habt ihr da für Schräubchen gedreht?

Daniel: Ja, bei statischen Ressourcen, die kommen im Wesentlichen aus unserem INNOQ Styleguide. Und die sind sowieso schon Fingerprinted gewesen. Das heißt wiederum, wenn sich der Content ändert, ändert sich die URL. Das hatten wir eben auch schon mal bei den Cloudinary Bildern. Da habe ich jetzt nur eine kleine Änderung vorgenommen, weil die sowieso eigentlich immutable sind, habe ich auch die Cache Control Direktive immutable noch mitgeschickt. Das heißt, wenn ich das richtig Erinnerung habe, dass ein Browser auch gar keinen Conditional Request mehr macht, um zu prüfen, ob sich was geändert hat. Weil bekannt ist, dass sich hier nie irgendwas ändern wird. Das heißt, da werden auch einfach Requests eingespart. Außerdem habe ich für redaktionellen Content, also für Blogposts, Artikel oder so getrennte Caching Direktiven für Browser und für Proxies eingeführt. Vorher hatten wir da in dem Cache Control Header nur die Max Age Direktive. Die wurde dann sowohl von einem Proxy, in unserem Fall Cloudflare, als auch vom Browser ausgelesen. Und jetzt benutzten wir eben für Proxys die separate „s-maxage“ Direktive und die hat dann einen deutlich längere Zeiten als die Max Age Direktive, die sich an die Browser richtet. Das heißt das Cloudflare unserer Seiten im Prinzip ewig cachen kann. Zumindest sehr, sehr lange, weil wir in der Lage sind über die Cloudflare API bestimmte URLs im Cloudflare Cache wieder zu invalidieren, was wir natürlich mit einem Browser nicht machen könnten. Deswegen sind wir da etwas konservativer bei der Max Age Direktive. Und im Grunde heißt das, dass unserer Cloudflare Cache so ein bisschen was wir Static Site Generation dann, nur dass es lazy passiert. Nur wenn jemand eine URL aufruft, landet sie dort.

Lucas: Sagen wir mal, im CMS wird eine neue Navigation eingeführt. Dann würdet ihr mit einem Befehl quasi den gesamten Cache leeren im Cloudflare, weil das jetzt HTML Änderungen auf allen Seiten bedeuten?

Daniel: Das wäre so eine Änderung im Styleguide zum Beispiel. Das ist etwas, da können wir den ganzen Cache lehren. Das müssen wir auch tun. Wenn wir nur jetzt einen Blogpost zum Beispiel ändern, dann schauen wir: Welche URLs müssen wir jetzt konkret im Cloudflare Cache invalidieren? Das ist auch gar nicht so trivial, wie es sich vielleicht anhört. Einerseits haben wir mehrere Sprachen und oft ist der Inhalt trotzdem der gleiche. EN und DE in den URLs zum Beispiel. Die müssen dann beide invalidiert werden, beide URLs für einen Artikel. Manchmal werden aber solche Inhalte auch noch auf anderen Seiten als Kachel oder in einer Übersichtsseite angezeigt. Und auch solche Seiten müssen dann invalidiert werden. Es gibt diese Staff Member Übersichtsseiten, wo man zum Beispiel meine Artikel sehen kann. Nicht die kompletten Artikel, aber eben die Überschrift. Das heißt, wenn ich da was an der Überschrift ändere, hat das einen Effekt nicht nur auf die Artikelseite selbst, sondern potenziell noch eine ganze Reihe anderer URLs. Das ist relativ komplex, das korrekt zu invalidieren.

Lucas: Ja, das kann ich mir vorstellen. Und neben dem Caching Header habt ihr aber auch noch die die Bilder noch mal weiter optimiert? Was habt ihr da gemacht, Daniel?

Daniel: Genau. Wir haben schon responsive Images für redaktionellen Inhalt gehabt, wo wir dieses srcset Attribut benutzen. Das war aber nicht so optimal bisher. Wir haben einfach nur für verschiedene Bildschirmauflösungen verschieden große Bilder ausgeliefert. Das ist schon mal nicht schlecht. Aber eigentlich spielt eben auch noch eine Rolle, wie groß der Viewport dieses Gerätes jetzt gerade ist. Und so haben wir jetzt verschiedene Break Points, wo wir dann verschieden große Bilder ausliefern. Es ist komplexer als einfach nur für eine Bildschirmauflösung von 1X, 2X oder so weiter die entsprechende Größe auszuliefern. Aber das sorgt dafür, dass wir oft nicht deutlich größere Bilder ausliefern als notwendig.

Lucas: Weil das vor allem auch relevant ist, weil die Mobilgeräte häufig über mobiles Internet gehen, was auch energieintensiver ist. Auch da große Bilder auszuliefern ist besonders schädlich.

Daniel: Genau, das hat schon einiges gebracht. Man wird da natürlich nie die perfekte Lösung finden. Perfekt wäre wirklich für jedes Gerät zur Auflösung und zur Breite des Viewports genau die passende Bildgröße auszuliefern. Das geht natürlich nicht. Man muss schauen, dass man einen guten Mittelweg findet. Man möchte nicht zu viele verschiedene Varianten eines Bildes haben. Aber man möchte auch nicht zu oft deutlich größere Bilder ausliefern.

Lucas: Ich meine das extrem wäre ja, wirklich für jede Auflösung ein Bild zu erzeugen. Das ist nicht nur unpraktikabel, das andere Problem wäre auch, dass man dann häufig noch viel mehr Bilder in der richtigen Auflösung erzeugen muss und noch mal neu komprimieren, das würde wahrscheinlich dann auch ein Teil des Vorteils auch wieder auffressen, wenn man da so weit gehen würde. Daphne, du hast es schon mal kurz über die Slideview gesprochen, die ist jetzt selbst gebaut. Und welchen Trick habt ihr da noch angewendet, um die noch cooler zu machen?

Daphne: Da haben wir quasi einfach das erwähnte Lazy Loading dran gehangen. Das war wirklich gar nicht aufwendig und hatten das Problem damit quasi abgefrühstückt.

Lucas: Okay. Das heißt also, wenn ich nur auf die ersten drei Slides von einem Slidedeck anschaue, lade ich auch nur die drei runter und alle anderen werden nicht runter geladen?

Daphne: Unser Slideviewer funktioniert so, dass man in einem separaten Embedded Fenster scrollen muss und immer wenn man scrollt, dann werden Images nachgeladen. Wenn man gar nicht diesen Punkt auf der Seite erreicht, dass diese Slides überhaupt im Viewport sind, natürlich, weil es irgendwas interessanteres gibt, wie ein Audio Stream oder ein Video oder so was, dann wird es gar nicht erst ausgelöst.

Lucas: Cool. Und das war nicht so die Hauptmaßnahmen, die ihr ergriffen habt. Da kann man jetzt schon sehen, dass man mit dieser Anzahl von Sachen fast die Hälfte einsparen kann. Das finde ich schon irgendwie erstaunlich. Das ist schon krass. Aber habt ihr denn auf eurer Todo Liste noch Sachen, wo ihr darüber nachdenkt, dass man die machen könnte? Oder habt ihr es sogar schon fest vor, Daphne?

Daphne: Da gibt es einige Sachen auf der Todo Liste. Ich kann mit einer Sache anfangen und zwar geht es da um das Asset Bundling. Unsere CSS und JavaScript Bundles. Wir pflegen jeweils einen Bundle – also einmal für CSS und einmal für JavaScript. Und beides bekommt auch den Fingerprint, von dem Daniel schon gesprochen hat, auch analog zu den Images. Und so kann man davon profitieren, dass die sehr lange gecached werden können. Wenn es jetzt zum Beispiel beim Styleguide ändert, wird der Fingerprint erneuert. Wie gesagt, man kann das sehr lange cachen und das bedeutet, dass pro Session keine weiteren Requests anfallen und keine weiteren Requests nötig sind, um diese Assets dann auch zu holen. Aber der Nachteil ist, dass wir eventuell auch sehr viel unbenutzten Code mit ausliefern. Da haben wir uns überlegt, vielleicht könnte man das Ganze noch optimieren, indem man es feiner aufsplittet. Das Problem wäre, es gibt dann wieder Trade Offs. In der Session würden dann wieder mehrere Requests anfallen, um die verschiedenen Assets dann zu holen. Aber wie gesagt, das ist nur auf eine Session bezogen. Natürlich kann man global betrachtet auch seine Assets oder seine Bundles feiner aufsplitten und die jeweils mit einem Fingerprint versehen. Da spricht überhaupt nichts gegen. Allerdings, wenn wir jetzt die Dinge dann wieder zusammenbauen, dann könnte es wieder eine Komplexität im Build Prozess geben. Und da müssen wir noch evaluieren, was wir da genau machen können. Welche Teile liefern wir aus, die wir vielleicht in einer Session nicht brauchen. Da müssen wir selbst noch schauen, ob es sich für uns lohnt.

Daniel: Man müsste eigentlich erst mal schauen, was eine typische Session ist. Es kann zum Beispiel sein, dass viele Leute sich einfach nur einen Artikel anschauen und dann nichts mehr. Da könnte es sich potenziell lohnen, das CSS, was nur für Artikel verwendet wird und den Rahmen zusammen auszuliefern und andere Dinge, die gar nichts mit Artikeln zu tun haben, in einem anderen Bundle.

Lucas: Da kann ich mir sehr gut vorstellen, dass so eine Webseite, wo viele von Suchmaschinen oder von Social Media kommen, dass die Leute nicht unbedingt alle über die Startseite kommen, die auf die Seite gehen. Klar, die Use Cases gibt es bestimmt auch. Jemand hält einen Vortrag und man sagt: Was ist eigentlich INNOQ? Tipp die Domain ein und guckt sich das an. Klar, auf jeden Fall. Aber ist halt ein Bauchgefühl. Man müsste das messen. Aber ich glaube auch, dass viele Leute nicht über die Startseite kommen, sondern direkt auf irgendeinen Inhalt kommen. Und wie viele weitere Sachen sie sich dann angucken, ist dann eben die Frage. Das ist schwer zu sagen, aber auf der anderen Seite finde ich, sollte man das auch noch mal im Hinterkopf behalten. Wenn man hier sowieso relativ wenig JavaScript hat, dann lohnt sich das JavaScript Splitting natürlich weniger, als wenn man jetzt sehr viel JavaScript hat. Da lohnt es sich sehr früh darüber nachzudenken. Das ist auch noch so eine Sache, die man im Hinterkopf halten muss. Gibt es da noch weitere Sachen, die ihr vorhabt, Daniel, um da noch besser zu werden?

Daniel: Eine Sache, die wir eigentlich sehr wichtig finden, wo wir zugegebenermaßen aber noch nicht so richtig mit angefangen haben, ist, dass wir die Leute, die Content ins CMS einpflegen, auch für das Thema sensibilisieren. Dass sie zum Beispiel bei Artikeln oder Blogposts keine unnötigen Bilder verwenden. Man kann nicht alles mit Technologie lösen, sondern es ist nun mal eine sehr inhaltsgetriebene Seite, wo viel auch dadurch eigentlich gesteuert wird, was an Inhalten eingepflegt wird. Ich kann da nur begrenzt durch Maßnahmen wie responsive images steuern. Denn die Leute, die die Inhalte einpflegen müssen, könnten auch entscheiden, dass sie bestimmte Bilder gar nicht erst nutzen, um die Emissionen auch zu sparen.

Lucas: Absolut.

Daniel: Wir hatten da einen sehr erfolgreichen Blogpost im letzten Jahr bei dem zwei Stock Fotos eingebunden waren. Das war so ein schönes Beispiel dafür. Da haben wir mal geschaut. Wenn wir diese Stock Fotos entfernen würden, was hätten wir dann an CO2 Emissionen gespart? Es war ganz interessant. Das waren zwei Bilder, die kamen zusammen auf 130 Kilobyte. Und dann konnte man ausrechnen, wie viel Kilogramm CO2 Äquivalente eingespart werden könnten, wenn man diesen Blogpost ohne diese Bilder veröffentlicht hätte. Weil dieses Beispiel ein sehr erfolgreicher Blogpost war, der sehr oft aufgerufen wurde. Ich habe aber leider gerade die Zahlen nicht parat.

Daphne: Ich habe sie parat. Wir sind darauf gekommen, hätte man in den ersten zwölf Monaten nach Erscheinen dieses sehr erfolgreichen Blogpost diese Bilder von Anfang an nicht dabei gehabt, dann hätten wir 2,7 Kilogramm CO2 gespart und mit dieser gesparten Energie hätte man 450 Liter Wasser kochen können.

Lucas: Krass.

Daniel: Das ist eine Menge Kaffee.

Lucas: Das stimmt, obwohl da auch noch der Energiebedarf von dem Kaffeeröster auch noch eine Rolle spielt. Aber egal, das ist ein anderes Thema. Aber ich finde das sehr anschaulich, sich das vorzustellen, wie viel das ausmachen kann. Weil ich meine, gerade ein 130 Kilobyte Bild klingt jetzt auch nicht so super viel. Es ist jetzt nicht eine riesige Zahl. Und dass das so viel ausmachen kann, finde ich doch schon wieder erstaunlich. Gerade wenn das Dekorationsbilder sind.

Daniel: Ja, es kommt halt immer darauf an, wie oft so eine Seite aufgerufen werden kann. Manche Seiten, die einfach extrem häufig aufgerufen werden, die können dann eben entsprechend große Effekte haben. Ganz ähnlich wie ich das in einer der letzten Folgen dieser Podcast Serie glaube ich schon mal erzählt hatte. Von einem Entwickler aus den Niederlanden, der eine JavaScript Dependency aus einem WordPress Plugin entfernt hat. Er hatte da einen Blogpost zu geschrieben, wie viel CO2 Emissionen das verhindert hat, weil sein Plugin bei 2 Millionen Websites irgendwie verwendet wurde.

Lucas: Ja, genau. Das finde ich auch noch mal klar, dass man darüber nachdenken muss. Vielleicht bei der eigenen Homepage, die nicht so oft aufgerufen wird, ist das was anderes als bei der Startseite von irgendeinem großen Konzern auf den Tausende von Pageviews pro Stunde haben. Das ist doch noch zu beachten. Sehr cool.

Daphne: Ich will noch ganz kurz hinzufügen. Wir haben uns auch überlegt, vielleicht könnten wir auch unsere Mitarbeitys unterstützen. Weil es ist auch nicht immer so vorhersehbar, wie gut jetzt so ein Blogpost durch die Decke geht oder wie viel Emission man gerade mit seinem Design und so auslöst. Und deswegen haben wir auch überlegt, ob wir vielleicht so eine Art Carbon Budget pro Seite irgendwie umsetzen könnten, das unseren Redakteurys dann unter die Arme greift und zeigt: Hör mal, so wie dein Blogpost gerade aufgebaut ist, emittierst du so und so viel. Und vielleicht auch an speziellen Punkten mal darauf hinzuweisen, lieber Vektorgrafiken zu nutzen, zum Beispiel bei Diagrammen oder so was. Kleine Nudging Hints zu geben, um so ein bisschen das Verhalten dann in die richtige Richtung dann zu entwickeln. Aber jetzt müssen wir auch noch evaluieren, inwieweit das dann möglich wäre.

Lucas: Vor allem, weil es einfach auch bedeutet, dass man als Mensch, der da einen Artikel schreibt, man einfach selbst sich darüber bewusst werden kann. Und dann kann man sagen: Mir ist das Bild das wert. Das Bild ist wichtig, das Bild muss drin bleiben. Klar, das verursacht CO2, aber ich finde es wichtig und das könnt ihr nicht als Leute, die das CMS schreiben einfach global entscheiden: Ab sofort jetzt keine Bilder mehr. Das wäre irgendwie glaube ich keine gute Entscheidung.

Daphne: Ja, wir haben da keine Metrik für unnötige Bilder festgelegt.

Lucas: Genau.

Daphne: Ich vermute auch, dass es vielen wichtig ist, was der Footprint ist, den sie damit verursachen. Aber ich glaube, wie du schon sagtest, es ist immer besser, wenn man eine bewusste Entscheidung dann treffen kann und sagt: Ja, das ist es mir wert, das unterstützt mein Inhalt und dann ist es auch okay. Besser als wenn man Stock Fotos reinhaut für den Dekor und sich darüber keine Gedanken macht.

Lucas: Absolut. Cool. Und eine Maßnahme, die ihr noch so im Betamodus, ist dieser Eco Mode. Magst du dazu noch was erzählen, Daniel?

Daniel: Ja, gerne. Das ist natürlich nicht so leicht, den Eco Mode zu bewerben, ohne dass die Leute sehen können. Aber ich versuche es mal zu beschreiben.

Lucas: Wir können auch ein Link in die Shownotes packen.

Daniel: Wir haben einen Proof of Concept bisher. Es geht eben darum, dass man sich bewusst entscheiden kann, sich eine Version der Website anzuschauen, die weniger Emissionen verursacht. Und was wir da bisher umgesetzt haben, ist eigentlich nur, dass diese Porträts, die wir bei den Podcastfolgen haben, die wurden schon mal erwähnt, dass wir die vektorisiert ausliefern, wenn der Eco Mode aktiviert ist. Das ist nämlich mit Cloudinary tatsächlich super einfach. Wir können das wieder über Cloudinary URL Parameter steuern, was wir das vektorisieren wollen, weil das einfach eine Transformation ist. Da können wir auch sagen, wie viel Details noch enthalten sein sollen in dem vektorisierten Bild und wie viele Farben. Und dass wir das gerne als SVG haben wollen. Das machen wir alles mit relativ wenig Details und Farben. Das spart dann auf dieser Podcast Übersichtsseite und auf den Seiten der einzelnen Folgen auch noch mal ziemlich viel an Datentransfer ein und damit auch an Emissionen. Dieser Eco Mode ist aktuell aber nur über einen Query Parameter aktivierbar. Das heißt, es gibt jetzt kein UI oder so was, wo ich den auswählen kann. Manche anderen Webseiten haben dafür zum Beispiel so einen Schalter, einen Toggle Button oder so was, wo ich das machen kann. Denkbar wäre aber vielleicht auch, dass man da auf die HTTP Request Header schaut. Das gibt es auch, dass man Save Data Attribut. Das wird aber glaube ich, bisher noch nicht von vielen Browsern unterstützt. Aber das sagt eben dem Server auch die Person, die diese Seite gerade aufruft, möchte gerne Daten sparen, zum Beispiel weil sie eben mobil unterwegs ist. Und dann kann der Server sich entsprechend anpassen.

Lucas: Aber ich glaube, wir packen in die Shownotes mal einen Link auf die Podcast Seite von dieser Folge. Dann könnte ihr das einfach mal sehen, wie das da konkret aussieht. Aber wie gesagt, es ist noch im Beta, deswegen ist es einfach noch nicht irgendwo ver-UI-t.

Daniel: Und vor allem, weil es auch noch nicht viel tut.

Lucas: Genau.

Daniel: Nur diese Podcasts, die wir bisher anpassen. Da müssen wir uns noch überlegen, was man da sonst noch Schlaues tun könnte.

Lucas: Ja, weil ich meine, ich finde es auch gut, einfach Sachen auszuprobieren, weil wenn man es nicht ausprobiert, dann weiß man es nicht. Das ist auf jeden Fall ein guter erster Schritt. Aber ihr habt bestimmt viele Diskussionen darüber geführt, über Sachen, wo ihr gesagt habt: Hm, wissen wir jetzt noch nicht, ob wir das tun wollen oder vielleicht machen wir es später oder was auch immer. Was fällt dir da in dem Bereich ein, für Maßnahmen, die ihr erst mal nicht machen wolltet?

Daphne: Wir haben uns auch über Grenzen Gedanken gemacht und wo unsere Prioritäten so liegen und eine Grenze, an die wir so gestoßen sind. Das ist aktuell unser Corporate Design. Wir benutzen zum Beispiel auch hochauflösende Fotos auf unserer Work Seite. Das waren bisher Bitmap Bilder. Daniel, du hattest doch vor kurzem noch praktisch damit zu tun. Hat sich da was geändert oder machen wir das eigentlich immer noch so? Weißt du das gerade?

Daniel: Das weiß ich leider gerade nicht.

Daphne: Aber mein letzter Stand war einfach, dass wir hochauflösende Bitmap Bilder benutzen. Wir wollten das auf jeden Fall noch optimieren, aber momentan sind wir eben noch an dem Stand, dass wir die erstmal beibehalten, um auch unsere Kultur zu kommunizieren. Das ist so ein Punkt. Und ein weiterer Punkt ist auch Typografie. Unsere Hausschrift zum Beispiel hat dann mehrere Schriftschnitte und so und da haben wir uns überlegt, könnte man das irgendwie optimieren und vielleicht irgendwie unbenötigte Characters daraus entfernen? Allerdings wissen wir noch gar nicht genau, welche Characters wir nicht brauchen. Eine Alternative zu herkömmlichen Fonts wären zum Beispiel auch Variable Fonts. Dass man die nutzt, weil die alle möglichen Schriftschnitte dann in einem Bündel. Aber da muss man dann noch mal im konkreten Fall prüfen, ob wirklich diese Variable Font dann auch kleiner ist als diese ganzen einzelnen Schrittschnitte zu laden. Das müssen wir noch evaluieren. Ich glaube, das waren so die Hauptpunkte, wenn es ums Corporate Design geht. Da müssen wir dann gucken, welche Trade Offs wir tatsächlich verschmerzen können und welche Dinge uns aber sehr wichtig sind, dass wir die dann trotzdem sie eben Emissionskosten haben, dann doch vorläufig beibehalten wollen.

Lucas: Ich finde in dem Bereich ist auch eine Sache, die man da im Hinterkopf behalten sollte. Man möchte, dass seine Webseite irgendwie schon so einen eigenen Charakter hat. Die soll schon irgendwie herausstechen. Und man soll sagen: Hey, das ist unsere Webseite, die erkennt man auch wieder. Und aus meiner Sicht ist ein Font, der nicht einer von diesen Standard Fonts ist von Google Fonts oder eine von den Systemschriften oder so, eine gute Art zu sagen: Hey, das ist unsere Identität und wir haben eben ein Font, den man sonst selten trifft, auf unseren Sachen verwendet. Und vielleicht ist es dann auch okay, diesen einen Font auszuliefern und zu sagen: Hey, das bezahlen wir. Aber dafür müssen wir dann vielleicht an anderen Stellen nicht so viele Logos oder was auch immer einblenden, um das auszugleichen. Ich finde ein Font ist eine gute Investition von Kilobytes in der Auslieferung im Vergleich zu anderen Maßnahmen, um da diese Einzigartigkeit hinzubekommen. Vor allem wenn man bedenkt, dass Font Rendering, da kann man nichts sparen, wenn man einen anderen Font nimmt im Vergleich zu weniger Bildern. Wenn man weniger Bilder rendert, spart man eben dann doch wieder Strom. Und das, finde ich, sollte man immer auch ein bisschen beachten, wenn man solche Sachen auswählt.

Daphne: Ja, absolut. Und Typografie gehört auch zu den Designgrundlagen. Wenn wir schon dabei sind. Über das Layout kann man auch einiges an Individualität auch erzeugen. Wenn das nicht immer so der Standard ist, sondern wenn man da kreativ wird, kann man auch darüber viel eigenes kommunizieren und vielleicht auch durch ein, zwei Brand Colors oder so.

Lucas: Absolut, stimme ich dir zu. Und jetzt mal abgesehen davon, gibt es auch einfach noch mal diesen ganzen Themenbereich: Was wäre denn, wenn man die Webseite nicht mehr als CMS betreiben würde, sondern stattdessen eine statische Seite generiert? Was sind da eure Überlegungen gewesen, Daphne?

Daphne: Wie kriegt man das jetzt einigermaßen geordnet zusammen? Da wäre zum Beispiel ein Ansatz, ein ein JAM Stack oder ein Headless CMS zu pflegen. In dem Fall ist JAM Stack kein klassischer Technologie Stack, wie man das vielleicht vermuten würde bei dem Wort. Das ist irreführend. Früher stand JAM mal für JavaScript, APIs und Markup und eigentlich geht es im Wesentlichen darum, dass man weg von dynamisch generierten Seiten geht und einfach quasi zurück zu statisch generierten Seiten geht. Ich finde das ganz witzig, dass dann so alte Sachen wieder neu verpackt werden. Das ist der Kerngedanke dabei. Und für uns würde das bedeuten, dass wir unser Frontend, das wir aktuell dynamisch für jeden Besucher generieren und ausliefern, dass wir das einmal statisch pre-rendern und das dann auch cachen können. Und dann würden wir unser CMS weiter als Content Basis benutzen, auch mit unserem Admin Backend. Man könnte weiter Inhalte einpflegen und da könnte die Pipeline quasi anlaufen und da könnte ein statischer Website Generator mit eingebunden sein, der dann die aktuellen Inhalte in die statischen Seiten mitintegriert und dann hat man quasi den neuesten Stand. Und ein Vorteil davon wäre natürlich auch abseits davon, dass man schon pre-gerenderte Seiten hat, die nicht jedes Mal neu gebaut werden müssen, dass auch komplizierte Caching Strategien entfallen. Daniel hatte schon vorher angeschnitten, dass es eine Herausforderung ist, alle Referenzen auf Ressourcen upzudaten. Und diese Schwierigkeit hätten wir dann zum Beispiel auch nicht mehr.

Lucas: Verstehe. Ich meine, das ist dann schon eigentlich eher ein Trade Off in diese Richtung. Aber vielleicht ist es gar nicht so viel effizienter, weil aktuell ist es auch so, dass die Seite quasi einmal ausgerechnet wird in der Rails Anwendung und danach wird sie eh von Cloudflare ausgeliefert. Und das heißt, da ist der Unterschied in der Rechenzeit vielleicht gar nicht so richtig groß. Aber du hast absolut recht, dann ist es eher eine Frage: Wo spart man sich damit eben Caching Komplexität ein? Da kann man sich auch vorstellen, wenn man jetzt irgendwie alle Seiten immer wieder neu baut und viele davon haben sich gar nicht geändert, dann hat man die vielleicht unnötig erzeugt.

Daniel: Das stimmt natürlich auch. Andererseits sind bisher unsere Cache Control Header eben auch die für Cloudflare, obwohl wir da Cache purgen können, haben wir uns nicht getraut, diese auf ewig zu setzen, weil wir eben wussten, dass wir vielleicht manchmal was nicht erwischen, was wir invalidieren müssen.

Lucas: Ja, das stimmt.

Daniel: Da wäre das mit dem statischen Rendern noch ein Vorteil, weil wir genau dann, wenn sich was ändert, wissen wir, dass es auch geändert im CDN ankommt.

Lucas: Ja, das stimmt. Guter Punkt. Ich meine vor allem, dass wahrscheinlich das jetzt nicht ein riesiger Unterschied wäre, von der rechten Rechenzeit, die dafür benötigt wird. Es ist es ein Unterschied. Das glaube ich auch. Aber ich glaube, der ist nicht so riesig groß, weil man sowieso sehr viel mit CDN Caching arbeitet, wo das dann abgelegt wird, weil wir doch relativ viele Zugriffe aus Deutschland haben auf unsere Inhalte und jetzt nicht so viel weltweit. Auch klar, aber nicht so viel. Das heißt viel wird auch auf den deutschen CDN Knoten gecached und deswegen denke ich, ist der Unterschied nicht so riesig groß, weil man muss natürlich auch da ganz klar sagen. Wenn man jetzt das umbauen wollen würde, dass wir eben nicht so ein Projekt, was man mal so nebenbei macht. Das ist dann schon eine ziemlich große Änderung der Architektur und des Codes, die dann viel Aufwand ist. Und das ist dann der Punkt, wo man darüber nachdenken muss, ist es den Aufwand wert und das muss man dann einfach bewerten.

Daniel: Genau. Sämtliche HTML Templates, die wir jetzt so in der Rails Anwendung haben, könnte man wahrscheinlich in der Form nicht mehr weiterverwenden.

Lucas: Ja.

Daniel: Man müsste sich überlegen, wie ich als Redakteury schnell ein Preview bekommen kann, von dem Inhalt, den ich gerade schreibe. Hat auch eine Herausforderung natürlich dieser Ansatz.

Lucas: Cool. Gut, dann würde ich jetzt sagen, ich komme langsam zum Ende der Folge. Daphne, magst du noch einmal kurz zusammenfassen, was aus deiner Sicht, die das Gesamtbild ist, von diesem Projekt, was sie da das halbe Jahr vor allem getrieben habt?

Daphne: Was uns eigentlich insgesamt aufgefallen ist, ist, dass wir die geschätzten Emissionen fast um die Hälfte reduzieren konnten. Und dafür haben wir relativ wenig Aufwand betrieben und relativ wenig Zeit gebraucht. Es waren vielleicht eine Handvoll Personentage und das Ganze war nicht besonders kompliziert. Diese Maßnahmen, die wir umgesetzt haben, die kennt man vielleicht auch aus in Anführungszeichen klassischen Performance Optimierungen und gehört einfach zum Handwerk. Wir haben das Handwerk angewandt und haben gemerkt, damit können wir sehr viel bewegen. Und das war, glaube ich, die größte Erkenntnis, die wir hatten. Und natürlich auch, dass es wichtig ist, dass wir nicht alles nur mit Technologie erschlagen können oder das Problem nicht nur von einer Seite angehen können, sondern dass es auch wichtig ist, dass die Sensibilisierung, die wir angesprochen haben, dass die sich weiter entwickelt für die redaktionellen Inhalte. Und wir haben auch überlegt, was wir denn zukünftig technisch vielleicht noch mal mehr fokussieren wollen. Unter anderem zum Beispiel den Eco Mode.

Lucas: Sehr cool. Gut, dann danke euch beiden für die Arbeit daran, dass ihr meinen persönlichen Footprint auch noch verbessert habt. Dadurch, dass meine Bilder weniger ausgeliefert werden und eure Zeit heute beim Podcast. Ja, und ich hoffe, wir hören uns demnächst mal wieder. Vielleicht gibt es auch noch weitere Themen aus diesem Themenbereich oder anderen, wo ihr noch mal was zu erzählen wollt. Und dann wünsche ich euch und den Hörerinnen und Hörern noch einen schönen Tag. Bis dann.

Daphne: Tschüss.

Daniel: Tschüss.