Stell Dir zwei Dateien vor, jede 100 Kilobyte groß. Die eine ist ein Bild, die andere ein Skript. In jeder CO₂-Bilanz einer Website zählen beide gleich. In der Realität nicht einmal annähernd.
Das Bild wird geladen, dekodiert, angezeigt. Fertig. Das Skript wird geladen, geparst, kompiliert, ausgeführt – und bei jeder Interaktion erneut ausgeführt. Diese Arbeit passiert nicht auf Deinem Server. Sie passiert auf jedem einzelnen Gerät, das Deine Seite aufruft.
Die Größenordnung
Der Web Almanac 2025 hat 17,2 Millionen Websites vermessen. Die mittlere mobile Startseite wiegt inzwischen rund 2,4 Megabyte – vor zehn Jahren waren es 845 Kilobyte. Davon entfallen im Median etwa 664 Kilobyte auf JavaScript. 98,1 Prozent aller Seiten laden mindestens eine Skriptdatei.
Aufschlussreicher ist eine andere Zahl: Auf der Hälfte aller mobilen Seiten bleiben mindestens 251 Kilobyte unkomprimiertes JavaScript ungenutzt. Code, der übertragen, entpackt, geparst und kompiliert wird, ohne jemals zu laufen. Der Web Almanac formuliert es in seinem Kapitel zum Seitengewicht selbst so: JavaScript trage eine Last, die deutlich schwerer wiege als seine Dateigröße vermuten lässt.
Warum das die Hardware trifft
Genau hier liegt der Punkt, der in Nachhaltigkeitsdebatten meist fehlt. Datenübertragung kostet Energie im Netz. Skriptausführung kostet Energie im Gerät – und zwar nicht einmalig, sondern bei jeder Bedienung.
Auf einem drei Jahre alten Mittelklasse-Smartphone dauert das Parsen und Ausführen eines großen Skript-Bundles ein Vielfaches der Zeit, die ein aktuelles Gerät braucht. Die Seite fühlt sich träge an. Der Akku leert sich schneller. Und irgendwann kauft jemand ein neues Telefon, obwohl das alte technisch völlig in Ordnung ist.
Bei einem Smartphone entfällt der überwiegende Teil der Lebenszyklus-Emissionen auf die Herstellung, nicht auf den Betrieb. Wer durch überladene Skripte den Gerätewechsel beschleunigt, verursacht damit ein Vielfaches dessen, was die eingesparten Bytes je ausgemacht hätten. Software macht Hardware alt.
Was der Browser inzwischen selbst kann
Der Entwickler Aaron T. Grogg hat unter dem Namen NoLoJS eine Sammlung angelegt, die genau da ansetzt: gängige Interface-Muster, die früher JavaScript brauchten und heute mit HTML und CSS auskommen. Aufklappbare Abschnitte, Modalfenster, Tabs, Filter, klebrige Kopfzeilen, sanftes Scrollen, Bildvergleichsregler, Karussells.
Ein Teil davon ist seit Jahren in jedem Browser verfügbar. Aufklappbare Inhalte über details und summary. Verzögertes Bildladen über loading="lazy". Klebrige Elemente über position: sticky. Für diese Muster ein Skript einzubinden, ist heute schlicht Gewohnheit.
Ein anderer Teil ist neu und noch nicht überall angekommen. Scrollgesteuerte Animationen laufen in Chrome und Safari, in Firefox bislang nur hinter einem Schalter. Vollständige CSS-Karussells sind noch enger begrenzt. Das ist kein Ausschlusskriterium: Fehlt die Unterstützung, bleibt der Inhalt sichtbar und scrollbar, nur die Animation entfällt. Der Ausfallmodus ist harmlos – anders als bei einem Skript, das nicht lädt.
Dein erster Schritt heute
Du musst dafür nichts umbauen und nichts installieren.
Die Frage ist nicht, ob JavaScript schlecht ist. Es ist unverzichtbar für das, wofür es gedacht war. Die Frage ist, warum wir es weiterhin Aufgaben erledigen lassen, die der Browser inzwischen selbst beherrscht – kostenlos, barrierefrei und ohne einen einzigen zusätzlichen Request.
Jede Zeile JavaScript, die der Browser nicht ausführen muss, spart Energie auf einem Gerät, das Dir nicht gehört.
Quellen: NoLoJS von Aaron T. Grogg · Web Almanac 2025, Kapitel Page Weight · Chrome for Developers: Carousels with CSS