Inhalt
Der CO₂-Fussabdruck einer Website entsteht nicht an einem Ort, sondern verteilt: im Rechenzentrum, das den Server betreibt, in den Netzen, die die Daten transportieren, und auf dem Endgerät, das die Seite rendert. Der gemeinsame Treiber ist das übertragene Datenvolumen — je mehr eine Seite wiegt und je mehr Rechenarbeit sie verlangt, desto mehr Energie fliesst. Genau hier setzt eine entkoppelte Architektur an: Ein schlankes, statisch über ein CDN ausgeliefertes Frontend überträgt weniger und rechnet weniger. Wie diese Trennung von Backend und Auslieferung technisch funktioniert, ordnet die Themenseite zu Headless WordPress ein.
Dieser Beitrag macht aus Nachhaltigkeit ein konkretes Effizienz-Argument — aber ohne Greenwashing. Die Einsparung an übertragenen Daten und Server-Rechenzeit ist real und messbar. Die Übersetzung in exakte Gramm CO₂ ist es nicht: Sie beruht auf Modellen mit groben Durchschnitts-Annahmen. Beide Seiten gehören in eine ehrliche Bewertung.
Woher kommt der CO₂-Fussabdruck einer Website?
Der CO₂-Fussabdruck einer Website entsteht aus dem Stromverbrauch dreier Systeme: Rechenzentren, Datenübertragungsnetzen und Endgeräten der Besucher. Treiber ist das übertragene Datenvolumen plus die Rechenlast pro Seitenaufruf. Schwerere Seiten mit viel JavaScript verbrauchen an jeder dieser Stationen mehr Energie — die Auslieferung ist also der Hebel.
Die Grössenordnung des realen Strombedarfs ist autoritativ eingeordnet. Laut der Internationalen Energieagentur (IEA) verbrauchten Rechenzentren 2022 global geschätzt 240 bis 340 TWh Strom — rund 1 bis 1,3 % der weltweiten Stromnachfrage — und Datenübertragungsnetze 260 bis 360 TWh, also 1 bis 1,5 %. Diese Zahlen sind eine 2022er-Schätzung; die IEA weist für die Folgejahre höhere, KI-getriebene Werte aus. Für den gesamten ICT-Sektor schwanken die Schätzungen je nach Methode: Eine viel zitierte Studie von Freitag, Berners-Lee und Kollegen referenziert peer-reviewte Vorstudien bei 1,8 bis 2,8 % der globalen Treibhausgase und kommt bei voller Lieferkettenbetrachtung selbst auf 2,1 bis 3,9 %.
Das Problem wächst, weil Seiten schwerer werden. Die mediane Website wog im Oktober 2024 auf dem Desktop 2'652 KB und auf Mobile 2'311 KB — ein Anstieg von 8,6 % auf dem Desktop und 6,4 % auf Mobile gegenüber 2023 (HTTP Archive Web Almanac 2024). Mehr Gewicht heisst mehr Transfer, mehr Transfer heisst mehr Energie.
Wo sitzt das Gewicht — Bilder oder JavaScript?
Beides, aber JavaScript holt stark auf. Auf der medianen Website entfallen laut Web Almanac 2024 rund 1'054 KB auf Bilder und 613 KB auf JavaScript (Desktop). Der entscheidende Befund: JavaScript hat Bilder als meistangefragten Dateityp überholt, bei median 24 JS-Dateien pro Seite auf dem Desktop. Bilder sind also der grössere Brocken, aber JS ist der dynamischste — und der teuerste pro Kilobyte.
Das ist relevant, weil ein Kilobyte JavaScript nicht so viel kostet wie ein Kilobyte Bild. JavaScript muss heruntergeladen, geparst, kompiliert und ausgeführt werden — Arbeit, die das Endgerät leistet und die DebugBear zu Recht betont: Ein 1-MB-JavaScript-File belastet den Client weit stärker als ein 1-MB-Bild. Wo Sie also Gewicht sparen, entscheidet über den Effekt.
Der vermeidbarste Posten ist ungenutzter Code. Im 90. Perzentil liefern Desktop-Seiten 225 KB ungenutztes CSS und 907 KB ungenutztes JavaScript aus — Werte, die seit 2022 gestiegen sind, besonders deutlich beim JavaScript (Web Almanac 2024, Sustainability). Das ist Code, der übertragen, geparst und nie gebraucht wird: Ballast, der an jeder Station der Kette Energie kostet, ohne irgendeinen Nutzen zu liefern. Wie sich genau dieser Ballast auf die Ladezeit auswirkt, vertieft der Beitrag zu Core Web Vitals bei WordPress.
Wie misst man den CO₂-Fussabdruck einer Website?
Gemessen wird über das übertragene Datenvolumen, multipliziert mit Annahmen zur Energieintensität und zur Kohlenstoffintensität des Stroms. Das verbreitetste Verfahren ist das Sustainable Web Design Model — die Grundlage der meisten CO₂-Rechner für Websites. Es ist transparent dokumentiert, und genau diese Transparenz zeigt, wie viel Schätzung im Spiel ist.
Das Sustainable Web Design Model V4 rechnet mit einer operativen Energieintensität von rund 0,19 kWh pro übertragenem Gigabyte — aufgeteilt in Rechenzentren (0,055), Netze (0,059) und Endgeräte (0,080 kWh/GB). Dieser Wert wird mit einer globalen durchschnittlichen Netz-Kohlenstoffintensität von 494 gCO₂e/kWh multipliziert (Quelle: Ember). Daraus ergeben sich die medianen Werte aus dem Web Almanac: rund 0,37 g CO₂ pro Seitenaufruf auf dem Desktop und 0,33 g auf Mobile (Web Almanac 2024, Sustainability).
Diese Zahlen sind brauchbar für Trends und Vorher-Nachher-Vergleiche — nicht für amtliche Bilanzen. Das Modell selbst räumt ein, dass „Modelle und Schätzungen ungenau sind" und es Emissionen eher überschätzt. Im Modell entfallen rund 54 % der Systemenergie auf Endgeräte, 24 % auf Netze und nur 22 % auf Rechenzentren — der grösste Anteil liegt also dort, wo der Website-Betreiber am wenigsten direkt steuert. Mehr zur Server-Seite und ihrer realen Energiebilanz im Beitrag zu Headless-WordPress-Hosting 2026.
Warum hilft eine schlanke, statische Auslieferung?
Eine statisch über ein CDN ausgelieferte Headless-Architektur senkt den Energieverbrauch an zwei Stellen: Sie reduziert die Server-Rechenlast und das übertragene Datenvolumen. Statt bei jedem Aufruf eine Seite per PHP neu zu rendern, liefert ein CDN-Knoten am Rand eine vorgefertigte Datei aus — weniger Server-Arbeit, kürzere Wege, weniger Energie pro Aufruf. Das ist der direkte Hebel auf den Fussabdruck.
Der erste Effekt ist weniger Rechenarbeit pro Anfrage. Ein klassisches WordPress baut jede Seite serverseitig zusammen — Datenbankabfragen, Template-Rendering, Plugin-Hooks, bei jedem Aufruf. Ein Headless-Setup mit statischer Generierung (SSG) erledigt diese Arbeit einmal zur Build-Zeit; danach liefert das CDN nur noch fertige Dateien aus. Die Rechenlast pro Besucher sinkt drastisch, weil sie nicht mehr pro Aufruf, sondern pro Deploy anfällt.
Der zweite Effekt ist weniger Gewicht. Ein modernes Frontend lädt nur das JavaScript, das eine Seite wirklich braucht, statt eines monolithischen Theme-Bundles plus einem Dutzend Plugin-Skripte. Angesichts der 907 KB ungenutztem JavaScript im 90. Perzentil ist das der grösste vermeidbare Posten. Aus eigenen Schweizer Projekten 2024–2026: Bei der Migration einer mittelgrossen KMU-Marketing-Site von klassischem WordPress auf ein statisches Headless-Frontend sank das mediane Seitengewicht von rund 3,1 MB auf etwa 0,9 MB — eine Reduktion um knapp 70 %, bevor überhaupt ein einziges Bild zusätzlich optimiert wurde. Das ist der Effekt, der sich verlässlich messen lässt.
Headless senkt keine Emissionen per Knopfdruck — es entfernt das Gewicht und die Rechenarbeit, an denen Emissionen entstehen.
Welches Rechenzentrum dahinter die beste Energiebilanz bietet, ist eine Hosting-Frage — und die behandelt der Beitrag zur Hosting-Wahl für Headless WordPress im Detail.
Was Headless nicht löst — der ehrliche Teil
Hier wird die Bewertung unbequem, und genau das gehört dazu. Wer Nachhaltigkeit als Verkaufsargument überdehnt, betreibt Greenwashing — und untergräbt die belastbaren Teile des Arguments.
Die exakten Gramm CO₂ sind Schätzwerte, keine Messwerte. Das zeigt nichts so deutlich wie das V4-Update des Sustainable Web Design Model: Mit der neuen Methodik fielen die geschätzten CO₂-Werte pro Seitenaufruf rund zwei Drittel niedriger aus als unter V3 — obwohl sich keine einzige Website geändert hatte. Ein Methoden-Wechsel allein verschob die „Gramm CO₂" um den Faktor drei. Die Effizienz ist real; die präzise Zahl ist es nicht.
Datentransfer ist ein schwacher Proxy für Energie. Genau deshalb berichtet DebugBear bewusst keine CO₂-Werte: Datentransfer korreliere schlecht mit dem tatsächlichen Server- und Netz-Energieverbrauch, und die Wissenschaft habe „noch keinen breiten Konsens" zur Messung digitaler Emissionen erreicht. Wer Seitengewicht als alleinigen Indikator nimmt, verwechselt einen groben Stellvertreter mit der eigentlichen Grösse.
„Grünes Hosting" ist oft Zertifikat, nicht Realität. Laut Web Almanac 2024 laufen nur rund 12 % der Desktop-Seiten auf als grün eingestuftem Hosting (bei den Top-1'000-Seiten immerhin 56 %). Und „grün" bedeutet nicht zwingend fossilfrei: Die Einstufung beruht häufig auf Kompensationen. Die Green Web Foundation hat angekündigt, ab dem 1. Oktober 2026 keine reinen CO₂-Kompensationen mehr als Beleg für „100 % fossilfreies" Hosting zu akzeptieren, weil Offsets die eingesetzte Energie nicht dekarbonisieren; stattdessen sollen zeitlich und regional passende Stromnachweise (EAC/REC) gelten. Es handelt sich um eine geplante Regel, noch nicht um geltende Praxis.
Headless verlagert Energie teils nur, statt sie zu sparen. Eine entkoppelte Architektur bringt eine eigene Build-Pipeline mit, die bei jedem Deploy rechnet, und ein CDN, das selbst Strom verbraucht. Bei einer Seite, die sich täglich tausendfach ändert und kaum Traffic hat, kann die Build-Energie den Auslieferungsvorteil teilweise auffressen. Der grösste Energieanteil liegt ohnehin beim Endgerät des Besuchers (rund 54 % im Modell) — dort, wo Sie über schlankes JavaScript Einfluss nehmen, aber das Gerät selbst nicht kontrollieren.
Kurz: Effizienz ist der belastbare Teil dieses Arguments. Die exakte CO₂-Bilanz ist es nicht — und wer sie als präzise verkauft, verkauft eine Genauigkeit, die die Modelle selbst nicht beanspruchen.
Welcher Hebel passt zu welchem Profil?
Nicht jedes Projekt braucht eine Architektur-Umstellung für einen kleineren Fussabdruck. Die folgende Matrix ordnet ein, welcher Hebel zu welcher Ausgangslage passt — und wann Headless der überdimensionierte Weg ist.
| Profil | Empfehlung | Warum |
|---|---|---|
| Kleine Site, wenig Traffic, seltene Änderungen | Bestehendes Setup verschlanken | Ungenutztes CSS/JS und überflüssige Plugins entfernen senkt das Gewicht ohne neue Architektur |
| Traffic-starke Marketing-Site mit Performance-Zielen | Headless mit statischer Auslieferung | Weniger Server-Rechenzeit pro Aufruf + schlankes Frontend wirken bei jedem der vielen Besucher |
| Bild-lastige Site (Portfolio, Shop) | Erst Bilder optimieren, dann Architektur | Bilder sind mit median 1'054 KB der grösste Einzelposten — moderne Formate greifen sofort |
| Sehr dynamische Site, niedriger Traffic | Klassisch bleiben, Hosting prüfen | Build-Energie pro Änderung kann den CDN-Vorteil bei wenig Traffic auffressen |
| Nachhaltigkeit als alleiniges Motiv | Erst messen und verschlanken | Headless allein für CO₂ ist meist der teure Umweg; Effizienz-Hebel greifen zuerst |
Die Logik ist immer dieselbe: zuerst messen und verschlanken, dann erst über Architektur entscheiden. Eine schlankere klassische Site schlägt eine schlampig gebaute Headless-Site bei jedem CO₂-Rechner. Wann sich der Schritt zur Entkopplung wirtschaftlich und technisch lohnt, ordnet der Beitrag dazu ein, wann sich Headless WordPress lohnt.
Wo Ihre Site heute steht — der schnelle Check
Bevor man über Architektur entscheidet, lohnt der Blick auf den Ist-Zustand. Das Performance-Modul im kostenlosen Website-Check misst sichtbare Effizienz-Indikatoren von aussen — Seitengewicht, Anteil ungenutzten Codes und die Ladekennzahlen, die direkt mit dem Energieverbrauch korrelieren. Das ist keine zertifizierte CO₂-Bilanz, aber eine belastbare Standortbestimmung dafür, wie viel Ballast Ihre Seite heute überträgt.
Aus dem Befund ergibt sich die richtige Frage fast von selbst: Reicht das Verschlanken des bestehenden Setups, oder rechtfertigen Performance, Wartbarkeit und Effizienz zusammen den Schritt zur entkoppelten Architektur? Eine vertiefte Übersicht über unser Vorgehen finden Sie auf der Seite Leistungen.
Nächster Schritt
Nachhaltigkeit ist ein Effizienz-Argument — real in der eingesparten Datenmenge und Rechenzeit, ehrlich nur, wenn man den Schätzcharakter der CO₂-Zahlen mitnennt. Ob ein schlankeres Setup genügt oder eine Headless-Architektur für Ihr Projekt der richtige Hebel ist, lässt sich in einem kurzen Gespräch sauber einordnen. Wenn Sie Ihren digitalen Fussabdruck und Ihre Performance zusammen angehen wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos.
Wer zuerst die technischen Felder vertiefen will, findet in der Architektur-Kategorie im Blog die passenden Beiträge zu Hosting, Auslieferung und Migration — die Stellen, an denen sich Effizienz im Betrieb tatsächlich entscheidet.