Nachhaltiges Webdesign: Warum Performance der größte Hebel ist

Wer nachhaltiges Webdesign nur über „grünes Hosting" definiert, verfehlt den eigentlichen Punkt. Eine Website wird nicht dadurch nachhaltig, dass sie auf sauber etikettierter Infrastruktur läuft, während sie gleichzeitig schwere Skriptpakete, unnötige Third-Party-Dienste, kleinteilige API-Aufrufe und überdimensionierte Medien mit sich herumschleppt. Nachhaltigkeit beginnt im Web lange vor dem Stromvertrag: mit der Frage, wie viel Rechenarbeit ein digitales Produkt überhaupt verursachen muss.

Das ist am Ende auch eine kulturelle Frage. Ein großer Teil des heutigen Webs ist darauf trainiert, mehr zu laden, mehr zu messen, mehr zu verfolgen und mehr Aufmerksamkeit zu binden. Nachhaltiges Webdesign folgt dem Gegenprinzip: weniger Ballast, klarere Wege, weniger Maschinenarbeit. Eine gute Website ist nicht deshalb nachhaltig, weil sie asketisch wirkt. Sie ist es, weil sie präzise entwickelt wurde. Daraus folgt ein Grundsatz, der diesen Text trägt:

Für jede Aufgabe nur so viel technische Komplexität und Rechenleistung einsetzen, wie die Aufgabe tatsächlich verlangt.

Das gilt für JavaScript-Bundles und Bildformate ebenso wie für Tracking-Skripte und Datenbankabfragen. Und es gilt, als jüngstes und teuerstes Beispiel, für generative KI.

Wie groß dieser Fußabdruck bereits ist, zeigt eine Studie, die im Januar 2026 in der Fachzeitschrift Communications Sustainability erschien (1). Ein internationales Forschungsteam berechnete die Emissionen digitaler Industrien entlang globaler Lieferketten, von der Hardware über IT-Dienstleistungen bis zur Kommunikationsinfrastruktur, für den Zeitraum 2010 bis 2021. Das Ergebnis: rund 4,1 Prozent der weltweiten Treibhausgasemissionen. Zwischen 77 und 87 Prozent davon entstehen vorgelagert in den Lieferketten, bevor ein Produkt oder ein Dienst überhaupt genutzt wird; den größten Einzelanteil daran hat die Hardwareproduktion.

Ein erheblicher Teil dieser Emissionen taucht in offiziellen Klimabilanzen nie als „digital" auf, weil er in den Bilanzen anderer Branchen verbucht wird. Als wachsenden Treiber benennen die Autor:innen ausdrücklich IT-Dienstleistungen wie generative KI. Ihre Empfehlung für Websites, Anwendungen und KI-Werkzeuge lautet gleichermaßen, stets die ressourcenschonendste Lösung für ein gegebenes Problem zu wählen.

Nachhaltiges Webdesign, das nur den Strommix des eigenen Hosters betrachtet, sieht damit höchstens einen Bruchteil der eigentlichen Bilanz.

Innerhalb dessen, was ein Webteam unmittelbar beeinflussen kann, bleibt Performance der größte messbare Hebel. Sie beschreibt, wie viel Arbeit Browser, Netzwerk, Backend und Endgerät leisten müssen, bevor Inhalte tatsächlich nutzbar werden. Eine Studie mit 21 realen mobilen Web-Apps fand eine statistisch signifikante negative Korrelation zwischen Lighthouse-Performance-Scores und Energieverbrauch (2): Je besser die Performance, desto geringer tendenziell der Stromverbrauch beim Aufruf. Performance ist damit weit mehr als ein kosmetischer Wert für den Launch-Tag. Sie ist ein belastbarer Nachhaltigkeitsindikator, der sich mit jeder verbesserten Ladezeit sichtbar in der Energiebilanz niederschlägt.

Wer über nachhaltiges Webdesign spricht, sollte deshalb häufiger über Abfragen sprechen als über Ökostromtarife. Muss jede Seite beim Aufruf Daten aus mehreren Diensten zusammensammeln? Braucht jede Inhaltsseite ein JavaScript-Bundle, bevor überhaupt Text sichtbar wird? Muss eine Liste erst clientseitig zusammengesetzt werden, obwohl sie serverseitig oder statisch ausgeliefert werden könnte?

Hier liegt oft der größte Hebel im eigenen Projekt. Weniger Requests bedeuten weniger Roundtrips, weniger Roundtrips meist weniger Wartezeit, weniger Rechenlast und weniger Fehleranfälligkeit. Nachhaltigkeit entsteht im Web erstaunlich oft durch das Weglassen unnötiger Komplexität: Assets reduzieren, Serverantworten bündeln, Caching sauber aufsetzen, Inhalte dort statisch oder serverseitig ausspielen, wo sie nicht bei jedem Aufruf neu berechnet werden müssen, Bilder in modernen Formaten und passenden Größen ausliefern und Progressive Enhancement höher bewerten als Frontend-Overkill. Wie sich Ressourcen gezielt vorladen lassen, ohne den Browser mit Arbeit zu überfordern, zeigt unser Snippet preload, prefetch, preconnect – wann was?.

Besonders teuer wird es dort, wo Websites fremde Dienste leichtfertig einbinden. Eine Untersuchung von neun populären Web-Apps verglich Versionen mit und ohne Werbung sowie mit und ohne Analytics: Werbung erhöhte den Energieverbrauch signifikant, Werbung und Analytics verschlechterten zudem messbar die vollständige Ladezeit (3). Die Autor:innen empfehlen ausdrücklich, beides dort zu begrenzen, wo Energieverbrauch und Ladezeit reduziert werden sollen.

In der Praxis werden Cookie-Tools, Tag-Manager, Chat-Widgets, Conversion-Pixel, eingebettete Karten, externe Video-Player und Social-Feeds oft wie harmlose Zusätze behandelt. Tatsächlich importiert jeder dieser Bausteine zusätzliche Netzwerkanfragen, zusätzlichen Code, zusätzliche Renderarbeit und oft genug zusätzlichen Governance-Aufwand. Ein Tracking-Snippet ist nie nur ein Snippet. Es ist eine architektonische Entscheidung mit Folgekosten.

Dasselbe Prinzip stellt sich heute in schärferer Form. Eine Website, die eingehende Formulareinträge kategorisieren soll, kann dafür ein Sprachmodell befragen oder einen Klassifikator, der dieselbe Aufgabe seit Jahrzehnten löst, nur schneller, günstiger und mit einem winzigen Bruchteil des Stromverbrauchs. Die Frage, die im Projektalltag selten gestellt wird, lautet: Muss diese Aufgabe überhaupt ein Sprachmodell lösen?

Eine 2026 in Scientific Reports veröffentlichte Studie des Umweltbundesamts hat genau das an einem konkreten Verwaltungsfall durchgemessen: der automatischen Kategorisierung eingereichter Stellungnahmen in 14 Themenfelder (4). Die höchste Genauigkeit erzielte dabei kein Sprachmodell, sondern ein klassisches lineares Modell mit vortrainierten Satz-Embeddings. Selbst ein einfacher Klassifikator mit TF-IDF-Merkmalen übertraf mehrere getestete LLMs bei der Treffsicherheit. Bei einem der vier Vergleichsdatensätze fiel der Unterschied besonders deutlich aus: Ein großes Sprachmodell erzielte dort fünf Prozentpunkte mehr Genauigkeit als das beste klassische Modell, verbrauchte dafür aber 34,15 Wattstunden statt 0,0021 Wattstunden, mehr als das 16.000-Fache an Energie für einen einstelligen Genauigkeitsgewinn.

Für Behörden mit hochvolumigen, sich wiederholenden Klassifikationsaufgaben ziehen die Studienautoren eine klare Handlungsempfehlung: erst mit einfachen, etablierten Modellen als Maßstab beginnen, komplexere Sprachmodelle nur dann einsetzen, wenn sie einen messbaren Zugewinn liefern, der die zusätzlichen Ressourcen rechtfertigt. Das gilt für Websites im Kleinen genauso wie für Behörden im Großen. Eine Sortierfunktion, ein Formularvalidator, eine Produktsuche mit festen Filterkriterien: all das lässt sich mit regelbasierter Logik oder einer klassischen Datenbankabfrage lösen, oft in Millisekunden statt Sekunden und ohne den zusätzlichen Aufruf eines KI-Dienstes. Eine Untersuchung, die den Ressourcenverbrauch von Sprachmodell-Abfragen direkt mit klassischen SQL-Datenbankabfragen verglich, kommt zum selben Schluss und rät ausdrücklich davon ab, relationale Datenbanken durch Sprachmodelle zu ersetzen (5).

Natürlich spielt auch die Infrastruktur eine Rolle: der Strommix, die Effizienz der Kühlung, die Region, in der ein Rechenzentrum steht. Und diese Infrastruktur verbessert sich kontinuierlich. Gleichzeitig wächst der Bedarf schneller, als Effizienzgewinne ihn ausgleichen können: Die IEA geht davon aus, dass sich der weltweite Stromverbrauch von Rechenzentren bis 2030 auf rund 945 Terawattstunden verdoppelt, angetrieben vor allem von KI-optimierten Anlagen (6). Reduktion bleibt deshalb der erste Hebel, Infrastruktur der zweite. Selbst das effizienteste Rechenzentrum kompensiert keine Website-Architektur, die überflüssige Skripte lädt, jeden Aufruf neu berechnet oder ein Sprachmodell befragt, wo eine lokale Funktion genügt hätte.

Zur Energiebilanz tritt dabei eine zweite Ressource, die in der Webdesign-Debatte bislang kaum vorkam: Wasser. Rechenzentren kühlen ihre Server häufig über Verdunstung, ein Verfahren, das Trinkwasser buchstäblich verdunsten lässt. Belastbare Zahlen zum Wasserverbrauch einzelner KI-Anfragen veröffentlichen die Anbieter nicht, und ältere, oft zitierte Schätzwerte je Abfrage beruhten teils auf fehlerhaften Berechnungen. Seriöser lässt sich das Problem über den Ort statt über die Menge fassen. Eine Recherche von NDR und Süddeutscher Zeitung zeigt, dass etwa jedes vierte in Deutschland geplante Rechenzentrumsprojekt in einer Region liegt, die bereits heute unter Wasserstress steht (7). Dort zählt weniger die globale Summe als die lokale Entnahme an einem einzigen Punkt, ganzjährig, am stärksten an ohnehin heißen Tagen.

Wer diese Faktoren über das Benennen hinaus tatsächlich messen möchte, muss dafür kein eigenes Verfahren entwickeln. Die Software Carbon Intensity (SCI) der Green Software Foundation ist inzwischen als ISO/IEC 21031:2024 veröffentlicht und beschreibt, wie sich die Kohlenstoffintensität einer Anwendung pro funktionaler Einheit berechnen lässt, pro Nutzerin, pro Transaktion oder pro API-Aufruf (8). Eine speziell auf das Web zugeschnittene Variante wird derzeit gemeinsam mit der Green Web Foundation und dem World Wide Web Consortium entwickelt.

Für Websites heißt das: Nachhaltigkeit lässt sich als Kennzahl neben Ladezeit, Kosten und Sicherheit in dieselbe Bewertung stellen, mit der ein Team ohnehin jede technische Entscheidung trifft. Eine Zahl ersetzt kein Urteil, aber sie macht Entscheidungen vergleichbar: zwischen zwei Architekturen, zwischen einem eingebetteten Dienst und einer eigenen Lösung, zwischen Sprachmodell und Klassifikator.

Zur Nachhaltigkeit gehört eine zweite Ebene: Langlebigkeit. Eine Website bleibt auch dann nachhaltig, wenn sie nach vier oder fünf Jahren weder technisch noch gestalterisch komplett ersetzt werden muss. Wer jedem Trend hinterherrennt, produziert kurze Aufmerksamkeit, aber selten robuste digitale Produkte.

Das betrifft Designentscheidungen ebenso wie Systemarchitektur. Modulare Strukturen lassen sich erweitern, ohne dass ein monolithischer Unterbau zur Bremse wird; verständliche Komponenten sparen die Einarbeitungszeit, die ein wuchernder Theme-Dschungel kostet. Und wer kontinuierlich weiterentwickelt, erspart sich den kompletten Relaunch, der meist teurer und energieintensiver ausfällt als eine Reihe kleiner Anpassungen. Die nachhaltigste Website ist selten die spektakulärste. Meist ist es die, die sich sauber erweitern, warten und neu denken lässt.

Nachhaltiges Webdesign bleibt am Ende eine Frage digitaler Präzision, kein Anlass für grüne Rhetorik. Es fragt bei jedem Feature, wie viel Rechenzeit, Ladezeit, Wartung und Abhängigkeit diese Entscheidung erzeugt, was Nutzer:innen tatsächlich dadurch gewinnen und ob ein Sprachmodell die Aufgabe wirklich besser löst als der Algorithmus, der sie seit Jahren zuverlässig erledigt. Wer diese Fragen ernst nimmt, gewinnt schnellere, zugänglichere, robustere und wirtschaftlich sinnvollere Systeme. Nachhaltigkeit ist dann keine Zusatzdisziplin. Sie ist die Folge guter Architektur, gutes Handwerk.

Manchmal ist die nachhaltigste Entscheidung die, gar kein Modell zu befragen.