Zum Inhalt springen
Core Web Vitals Spezialisten
Grundlagen & Strategie

Nachhaltige Websites: Wie Performance CO2 einspart

Nachhaltige Websites: Wie weniger Bytes, schlankes JavaScript und effizientes Caching den CO2-Fußabdruck senken und zugleich die Core Web Vitals verbessern.

12 Min. Lesezeit Green WebNachhaltigkeitCO2PerformanceISO 20125CSRD

Jede Seite, die ausgeliefert wird, verbraucht Energie - im Rechenzentrum, im Netz und auf dem Endgerät der Besucher. Und wo Energie fließt, entsteht CO2. Nach der Modellrechnung des HTTP Archive Web Almanac (2024) verursacht ein einzelner Seitenaufruf im Median rund 0,33 Gramm CO2 auf Mobilgeräten (HTTP Archive Web Almanac, 2024). Das klingt nach wenig - hochgerechnet auf Millionen Aufrufe im Monat wird daraus eine messbare Größe. Die gute Nachricht: Genau die Faktoren, die eine Seite schwer und langsam machen, treiben auch ihren Energiebedarf. Wer Bilder verschlankt, JavaScript reduziert und effizient cached, senkt Ladezeit und CO2-Fußabdruck zugleich und verbessert dabei die Core Web Vitals. Dieser Artikel verbindet den digitalen Fußabdruck mit konkreten Performance-Hebeln und ordnet den neuen Rahmen aus ISO/IEC TS 20125 und der CSRD ein.

Das Wichtigste in Kürze

  • Ein mobiler Seitenaufruf verursacht im Median rund 0,33 Gramm CO2 (HTTP Archive Web Almanac, 2024); der deutsche Strommix lag 2024 bei 363 Gramm CO2 je Kilowattstunde (Umweltbundesamt), Rechenzentren verbrauchten 20 Milliarden Kilowattstunden (Bitkom).
  • Bilder verantworten 69,6 Prozent der Seiten-Emissionen, JavaScript 20,8 Prozent, Schriften, CSS und HTML zusammen unter 10 Prozent (HTTP Archive Web Almanac, 2024). Das mediane Seitengewicht liegt mobil bei 2,0 Megabyte, der Zielkorridor bei 500 Kilobyte.
  • Beim Bild liegt Potenzial brach: Erst 12 Prozent (HTTP Archive Web Almanac, 2024) der Bilder werden als WebP ausgeliefert, 1 Prozent als AVIF, 42,4 Prozent der Seiten nutzen srcset und 34 Prozent natives Lazy-Loading (HTTP Archive Web Almanac, 2024).
  • JavaScript kostet doppelt – Übertragung im Netz und Rechenzeit auf dem Endgerät. Am 90. Perzentil schleppen mobile Seiten rund 812 Kilobyte ungenutztes JavaScript mit (HTTP Archive Web Almanac, 2024), das eine Coverage-Analyse sichtbar macht.
  • Caching verkürzt die Antwortzeit und spart zugleich wiederholte Rechenarbeit im Rechenzentrum. Dort sind die Unterschiede groß: Im ineffizientesten untersuchten Rechenzentrum entstanden je Rechenoperation zehnmal mehr Treibhausgase (Umweltbundesamt).
  • Seit dem 27. Februar 2026 beschreibt ISO/IEC TS 20125-1:2026 (ISO) Praktiken für das Ökodesign digitaler Dienste; die CSRD verlangt über ESRS E1 die Offenlegung indirekter Emissionen. Der Emissionswert je Seitenaufruf wird damit berichtsrelevant.

Der digitale Fußabdruck: Warum jede Seite Energie kostet

Hinter jeder Website steht physische Infrastruktur, die Strom zieht. Der Stromverbrauch der Rechenzentren in Deutschland lag 2024 bei rund 20 Milliarden Kilowattstunden - 2014 waren es noch 12 Milliarden (Bitkom). Für 2025 weist die Erhebung bereits 21,3 Milliarden Kilowattstunden aus, und bei linearer Fortschreibung steigt der Bedarf bis 2030 auf etwa 31 Milliarden Kilowattstunden (Bitkom). In einer Befragung erwarten 80 Prozent der Betreiber, dass der verstärkte Einsatz von Künstlicher Intelligenz den Verbrauch weiter treibt (Bitkom). Diese Zahlen machen deutlich: Digitale Angebote sind alles andere als immateriell.

Aus Strom wird CO2, und zwar in einer heute bezifferbaren Menge. Pro Kilowattstunde des in Deutschland verbrauchten Stroms wurden 2024 bei der Erzeugung durchschnittlich 363 Gramm CO2 ausgestoßen; 2023 lag der Wert bei 386 und 2022 bei 433 Gramm (Umweltbundesamt). Der Strommix wird also grüner - doch der wachsende Bedarf frisst einen Teil dieses Fortschritts wieder auf. Weltweit verbrauchten Rechenzentren im Jahr 2020 nach Auswertung verschiedener Studien zwischen 200 und 1.000 Terawattstunden, was etwa 100 bis 500 Millionen Tonnen CO2-Äquivalenten entspricht (Umweltbundesamt). Die große Spannweite zeigt, wie unsicher globale Schätzungen sind - die Richtung aber ist eindeutig.

Drei Orte, an denen eine Seite Energie verbraucht

Energie fällt an drei Stellen an: im Rechenzentrum, das die Seite erzeugt und ausliefert, im Übertragungsnetz auf dem Weg zum Nutzer und schließlich auf dem Endgerät, das die Seite verarbeitet und darstellt. Jedes übertragene und ausgeführte Byte belastet alle drei Ebenen. Deshalb ist Datensparsamkeit der wirksamste Hebel: Ein Byte, das gar nicht erst gesendet wird, verbraucht an keiner der drei Stationen Strom.

Vom Byte zum Gramm: Wie sich Web-Emissionen berechnen lassen

Um Emissionen einer Website abzuschätzen, hat sich das quelloffene Sustainable Web Design Model (SWD) etabliert. Es rechnet die übertragene Datenmenge über Annahmen zu Rechenzentrum, Netz und Endgerät in eine CO2-Menge je Seitenaufruf um. Der HTTP Archive Web Almanac wendet dieses Modell auf Millionen realer Seiten an. Das Ergebnis für 2024: Im Median verursacht ein mobiler Seitenaufruf 0,33 Gramm CO2, auf dem Desktop 0,37 Gramm (HTTP Archive Web Almanac, 2024). Am oberen Ende, dem 90. Perzentil, sind es bereits 1,36 Gramm mobil und 1,47 Gramm am Desktop (HTTP Archive Web Almanac, 2024). Der wichtigste Treiber dahinter ist das Seitengewicht: Der Medianwert liegt bei rund 2,0 Megabyte mobil, das Modell empfiehlt eine Obergrenze von 1 Megabyte und einen Zielkorridor um 500 Kilobyte (HTTP Archive Web Almanac, 2024).

Ein Rechenbeispiel für die Größenordnung

Bei 0,33 Gramm je mobilem Seitenaufruf (HTTP Archive Web Almanac, 2024) und 100.000 Aufrufen im Monat entstehen rechnerisch rund 396 Kilogramm CO2 pro Jahr. Wird das Seitengewicht konsequent etwa halbiert, sinkt dieser Wert nach dem gleichen Modell auf ungefähr die Hälfte. Das ist keine Punktprognose, sondern eine Modellrechnung - sie zeigt aber, dass sich Datensparsamkeit über die Reichweite einer Website zu einer relevanten Menge summiert, ganz ohne Komfortverlust für die Nutzer.

Entscheidend ist, wie sich das Gewicht auf die Ressourcentypen verteilt, denn nicht jeder trägt gleich stark zur Emission bei. Die folgende Aufschlüsselung stammt aus dem Sustainable-Web-Design-Modell für das 90. Perzentil und zeigt, wo der Hebel am größten ist - dieselbe Reihenfolge kennt jedes strukturierte Lighthouse-Audit aus der Praxis.

RessourcentypAnteil an den EmissionenTypische MaßnahmeWirkung auf die Vitals
Bilder69,6 Prozent (HTTP Archive)Moderne Formate, responsive Größen, Lazy-LoadingLCP, CLS
JavaScript20,8 Prozent (HTTP Archive)Code-Splitting, ungenutzten Code entfernenINP, LCP
Schriften4,8 Prozent (HTTP Archive)Subsetting, WOFF2, font-displayLCP, CLS
CSS3,1 Prozent (HTTP Archive)Critical CSS, ungenutzte Regeln entfernenLCP
HTML1,7 Prozent (HTTP Archive)Kompression, saubere AuslieferungLCP, TTFB

Bildgewicht: der größte einzelne Hebel

Bilder sind sowohl für die Ladezeit als auch für die Emissionen der mit Abstand größte Posten. Sie verantworten im Modell 69,6 Prozent der Seiten-Emissionen am 90. Perzentil (HTTP Archive Web Almanac, 2024), und auf der typischen mobilen Startseite laden allein die Bilder rund 900 Kilobyte - mehr als jeder andere Ressourcentyp (HTTP Archive Web Almanac, 2024). Genau hier ist das Einsparpotenzial am größten, und es kostet keine Funktion: Ein Bild in einem modernen Format und in der richtigen Größe sieht identisch aus, wiegt aber einen Bruchteil.

Bemerkenswert ist, wie viel Potenzial noch brachliegt. Nach den Felddaten des HTTP Archive nutzen erst 42,4 Prozent der Seiten responsive Bilder über das srcset-Attribut, und nur 34 Prozent setzen natives Lazy-Loading ein (HTTP Archive Web Almanac, 2024). Bei den Formaten ist der Rückstand noch größer: Lediglich 12 Prozent der Bilder werden als WebP ausgeliefert, gerade einmal 1 Prozent als AVIF (HTTP Archive Web Almanac, 2024). Wer hier ansetzt, senkt Gewicht und Emissionen zugleich - der Beitrag zur Bilder-Optimierung mit WebP und AVIF beschreibt die Technik im Detail.

Moderne Formate

WebP und AVIF komprimieren bei vergleichbarer Qualität deutlich stärker als ältere Formate. Da erst 12 Prozent der Bilder als WebP ausgeliefert werden (HTTP Archive), ist der Umstieg einer der schnellsten Gewinne für Gewicht und CO2.

Responsive Größen

Mit srcset erhält jedes Gerät genau die Auflösung, die es braucht - kein 2000-Pixel-Bild auf einem Smartphone-Display. Das spart Bytes, ohne dass die Darstellung leidet, und stabilisiert zugleich das Layout.

Lazy-Loading

Bilder außerhalb des Sichtfelds werden erst geladen, wenn der Nutzer sie erreicht. Das entlastet den initialen Ladepfad und verhindert, dass Energie für Inhalte aufgewendet wird, die viele Besucher kaum je sehen.

Die Bild-Optimierung ist damit der Musterfall für den doppelten Nutzen: Sie verbessert Largest Contentful Paint und Layout-Stabilität und reduziert gleichzeitig den größten Emissionsblock. In der Bilder-Optimierung wägen wir zwischen Qualität, Format und Auslieferung ab, statt pauschal die Kompression hochzudrehen und sichtbare Artefakte in Kauf zu nehmen.

JavaScript und Third-Party-Ballast reduzieren

Nach den Bildern ist JavaScript der zweitgrößte Emissionsblock - im Modell 20,8 Prozent am 90. Perzentil (HTTP Archive Web Almanac, 2024). Der Median der mobilen JavaScript-Auslieferung liegt bei 558 Kilobyte, auf dem Desktop bei 613 Kilobyte (HTTP Archive Web Almanac, 2024). JavaScript ist dabei doppelt teuer: Es muss übertragen werden - das kostet Energie im Netz - und es muss auf dem Endgerät geparst und ausgeführt werden, was zusätzlich Rechenzeit und damit Strom verbraucht. Anders als ein Bild belastet Skriptcode also nicht nur die Leitung, sondern auch den Prozessor des Nutzers.

Besonders ärgerlich ist ungenutzter Code. Am 90. Perzentil schleppen mobile Seiten rund 812 Kilobyte ungenutztes JavaScript und 212 Kilobyte ungenutztes CSS mit (HTTP Archive Web Almanac, 2024) - Bytes, die übertragen und teils ausgeführt werden, ohne einen Zweck zu erfüllen. Third-Party-Skripte verschärfen das Bild zusätzlich, weil ihr Verhalten schwer kontrollierbar ist. Wie sich diese Last systematisch senken lässt, zeigen die Beiträge zu Third-Party-Skripten entschlacken und zu JavaScript-Performance-Budgets.

  • Ungenutztes JavaScript und CSS über eine Coverage-Analyse aufspüren und entfernen
  • Code aufteilen, sodass jede Seite nur lädt, was sie tatsächlich braucht
  • Nicht kritische Skripte mit defer oder erst nach der ersten Interaktion laden
  • Third-Party-Tags inventarisieren und ohne benennbaren Zweck streichen
  • Ein Performance-Budget für die ausgelieferte JavaScript-Menge festlegen und im Deployment prüfen

Jedes eingesparte Kilobyte Skript wirkt doppelt: Es senkt die Energie für Übertragung und Ausführung und entlastet den Main-Thread, was direkt die Interaction to Next Paint verbessert. Genau diese Verbindung macht die Frontend-Optimierung zu einer Maßnahme, die Nachhaltigkeit und Reaktionsschnelligkeit in einem Schritt adressiert.

Rechenzentrum, Caching und effiziente Auslieferung

Nicht nur das, was an den Browser geht, zählt - auch wie die Seite entsteht, hat einen Energiepreis. Wird jede Anfrage von Grund auf berechnet, arbeiten Datenbank und Applikationsserver bei jedem Aufruf erneut. Effizientes Caching liefert stattdessen fertige Ergebnisse aus und spart die wiederholte Rechenarbeit. Das senkt zugleich die Antwortzeit des Servers (TTFB) und die Last im Rechenzentrum. Wie man Cache-Schichten sinnvoll kombiniert, behandelt der Beitrag zu Caching-Strategien; die serverseitige Grundlage dafür schafft eine gezielte Server-Optimierung.

Wie groß die Effizienzunterschiede im Rechenzentrum selbst ausfallen, zeigt eine Untersuchung nach der KPI4DCE-Methodik: Im ineffizientesten von drei untersuchten Rechenzentren wurden pro Rechenoperation zehnmal mehr Treibhausgase emittiert als notwendig (Umweltbundesamt). Die Wahl eines effizienten Betreibers und einer stromsparenden Architektur ist damit ein realer Hebel. Zugleich verbreitet sich grünes Hosting noch langsam: Nach dem HTTP Archive Web Almanac (2024) laufen erst 10 Prozent der mobil ausgelieferten Seiten auf als grün eingestuften Servern, unter den größten Websites sind es dagegen bereits über die Hälfte (HTTP Archive Web Almanac, 2024).

Caching wirkt in beide Richtungen

Ein gut gesetzter Cache ist selten nur ein Tempo-Trick. Er verhindert, dass Server bei jedem Aufruf dieselbe Arbeit wiederholen, verkürzt die Antwortzeit und reduziert die im Rechenzentrum verbrauchte Energie. Wer Cache-Header, Objekt-Cache und Auslieferung über verteilte Standorte zusammen denkt, verbessert Ladezeit und Effizienz gemeinsam - eine der wenigen Maßnahmen, die praktisch keine fachliche Abwägung erfordert.

Warum Performance und CO2 dasselbe Ziel verfolgen

Der rote Faden dieses Artikels ist die Deckungsgleichheit der Hebel. Weniger Bytes, weniger JavaScript und effizientes Caching senken den Energiebedarf und verbessern zugleich die Core Web Vitals. Das ist kein Zufall, sondern folgt aus der gemeinsamen Ursache: Sowohl die Emission als auch die gefühlte Geschwindigkeit hängen davon ab, wie viel übertragen, verarbeitet und dargestellt werden muss. Eine leichte Seite ist deshalb in aller Regel auch eine schnelle Seite - und umgekehrt.

Nachhaltigkeit und Geschwindigkeit sind im Web keine konkurrierenden Ziele, sondern zwei Seiten derselben Optimierung. Wer Ballast entfernt, gewinnt beides zugleich: eine reaktionsschnellere Seite und einen kleineren Fußabdruck.

Aus der Projektarbeit zur Performance-Optimierung

Schnellere Vitals

Kleinere Bilder und weniger Skriptcode verbessern LCP und INP unmittelbar. Die Seite reagiert früher auf Eingaben und stellt Inhalte schneller dar - das wirkt direkt auf Wahrnehmung und Conversion.

Geringere Emissionen

Dieselben eingesparten Bytes reduzieren die Energie an allen drei Stationen: Rechenzentrum, Netz und Endgerät. Der CO2-Wert je Seitenaufruf sinkt, ohne dass eine Funktion verloren geht.

Niedrigere Kosten

Weniger übertragene Daten bedeuten geringere Bandbreiten- und Rechenlast. Effizienz senkt damit auch den Betriebsaufwand - Nachhaltigkeit und Wirtschaftlichkeit zeigen in dieselbe Richtung.

Dass sich Tempo wirtschaftlich auszahlt, ist gut belegt - der Beitrag zu Ladezeit, Conversion-Rate und Umsatz vertieft diesen Zusammenhang. Und wer Navigationen im Voraus vorbereitet, statt Ressourcen doppelt zu laden, arbeitet ebenfalls effizienter, wie der Artikel zu Speculation Rules für sofortige Navigation zeigt. Die Verbindung aus Effizienz, Tempo und Emissionsersparnis steht im Zentrum jeder nachhaltigen Performance-Leistung.

ISO 20125 und CSRD: der regulatorische Rahmen

Nachhaltige Softwaregestaltung ist inzwischen normiert. Mit ISO/IEC TS 20125-1:2026 wurde am 27. Februar 2026 eine Technische Spezifikation zum Ökodesign digitaler Dienste veröffentlicht - Teil 1 trägt den Titel Ecopractices for life cycle stages und beschreibt Praktiken, mit denen sich die Umweltwirkung eines digitalen Dienstes über seinen Lebenszyklus senken lässt (ISO). Die Spezifikation ist bewusst methodenunabhängig formuliert und lässt sich auf klassische wie agile Entwicklungsprozesse anwenden (ISO). Sie liefert damit erstmals einen international abgestimmten Bezugsrahmen für das, was Performance-Optimierung in der Praxis ohnehin tut: Ballast vermeiden und Ressourcen effizient einsetzen.

Parallel steigt der Berichtsdruck. Die europäische Corporate Sustainability Reporting Directive (CSRD) verlangt von einem wachsenden Kreis von Unternehmen, ihre Umweltwirkungen entlang der Wertschöpfungskette offenzulegen; der zugehörige Klimastandard ESRS E1 adressiert dabei auch indirekte Emissionen aus zugekauften digitalen Leistungen (Scope 3). Websites und Online-Dienste sind Teil dieser Kette. Ein belastbar niedriger Emissionswert je Seitenaufruf ist damit nicht nur ein Qualitätsmerkmal, sondern zunehmend eine berichtsrelevante Kennzahl - und ein Argument im Wettbewerb um umweltbewusste Kunden.

Was das für Betreiber bedeutet

Norm und Berichtspflicht verlangen keine Kür, sondern eine nachvollziehbare Grundhygiene: bekannte Emissionstreiber messen, Seitengewicht begrenzen, effizient ausliefern und die Wirkung dokumentieren. Genau diese Schritte deckt sich mit klassischer Performance-Arbeit. Ein Audit, das Ladezeit und Emissionen gemeinsam betrachtet, liefert damit sowohl bessere Core Web Vitals als auch belastbare Zahlen für die Nachhaltigkeitsberichterstattung.

Nachhaltigkeit dauerhaft im Betrieb verankern

Eine einmal verschlankte Seite bleibt nicht von selbst leicht. Neue Kampagnen bringen neue Skripte, unkomprimierte Bilder schleichen sich in Redaktionsprozesse ein, und über die Zeit wächst das Gewicht erneut. Deshalb gehört Effizienz in einen wiederkehrenden Prozess statt in ein einmaliges Projekt. Ein Performance-Budget legt Obergrenzen für Seitengewicht und JavaScript fest, die bei jedem Deployment geprüft werden; ein Real User Monitoring beobachtet die Vitals im Feld, sodass Regressionen früh auffallen.

  • Seitengewicht und JavaScript-Menge pro Vorlage budgetieren und automatisiert prüfen
  • Bilder grundsätzlich in modernen Formaten, responsiv und mit Lazy-Loading ausliefern
  • Ungenutzten Code regelmäßig aufspüren und entfernen
  • Caching und effiziente Auslieferung als Standard, nicht als Ausnahme etablieren
  • Emissionswert je Seitenaufruf messen und neben den Core Web Vitals dokumentieren
  • Hosting-Effizienz und Strommix des Betreibers in die Auswahl einbeziehen

Der Einstieg ist eine Bestandsaufnahme, die Ladezeit und Emissionen in einem Schritt betrachtet. Unsere Performance-Analyse deckt genau den Ballast auf, der zugleich Tempo kostet und CO2 verursacht, und priorisiert die Maßnahmen nach Wirkung. Vergleichbare Ausgangslagen begegnen uns quer durch Branchen - von der Unternehmenswebsite bis zum Online-Shop, wie die Referenzen zeigen. Am Ende steht eine Seite, die schneller lädt, weniger verbraucht und den Anforderungen von Norm und Berichtspflicht standhält.

Dieser Artikel basiert auf Daten aus: Umweltbundesamt (CO2-Faktor des deutschen Strommixes 2024, Rechenzentren und KPI4DCE), Bitkom (Rechenzentren in Deutschland, Borderstep-Erhebung 2024/2025), HTTP Archive Web Almanac 2024 (Kapitel Sustainability, Page Weight, JavaScript und Media, Sustainable Web Design Model v4) sowie ISO/IEC TS 20125-1:2026 (Digital services ecodesign). Die Werte entsprechen dem Stand Juli 2026.

Verwandte Artikel