Frontend-Optimierung wurde seit Jahren vor allem als UX- und SEO-Thema betrachtet. Es gibt aber einen weiteren Aspekt, der kaum betrachtet wird: Energieverbrauch. Jeder Render-Zyklus, jeder Bundle-Download, jede Animation kostet echte Energie. Wenn du Millionen Nutzende versorgst, summieren sich diese Ineffizienzen schnell. Das Internet verursacht CO₂-Emissionen in einer Größenordnung, die mit der globalen Luftfahrt vergleichbar ist, nur sehen wir die Umweltkosten aufgeblähter JavaScript-Bundles nicht so direkt wie Flugzeugkondensstreifen. Diese Unsichtbarkeit macht das Problem schwerer greifbar.

Energieverbrauch im Frontend entsteht auf drei unterschiedlichen Ebenen, und jede davon braucht eigene Optimierungsstrategien.

Die Server-Schicht ist der Bereich, in dem Next.js-Funktionen laufen, API-Routen Requests verarbeiten und Server-Side Rendering passiert. Jede Millisekunde, die eine serverlose Funktion läuft, jede zu langsame Datenbankabfrage, jede komplexe Berechnung bedeutet Energieverbrauch im Rechenzentrum.

Die Netzwerk-Schicht liegt zwischen Server und Nutzenden. Forschende messen ihre Effizienz in Kilowattstunden pro Gigabyte (kWh/GB) für übertragene Daten, inklusive Energie der Telekommunikationsnetze, CDN-Infrastruktur und Übertragungssysteme. Mehr Daten bedeuten mehr Energie für den Transport durch das Netz.

Die Client-Schicht wird oft übersehen: die Geräte der Nutzenden. Diese machen etwa die Hälfte der Emissionen des gesamten digitalen Ökosystems aus. Trotzdem denken wir selten darüber nach, wie stark unser Code den Akku belastet.

Diese Ebenen sind wichtig, weil Optimierungen je nach Schicht unterschiedliche Effekte haben. Was Serverenergie spart, kann den Netzwerkverkehr erhöhen. Was Daten reduziert, verlagert mehr Arbeit auf das Gerät der Nutzenden. "Grüne" Frontend-Entwicklung bedeutet, diese Balance zu finden.

Den direkten Energieverbrauch von Frontend-Code können wir in Produktion nicht messen: es gibt keine Wattmeter auf jedem Endgerät. Stattdessen arbeiten wir mit Proxy-Metriken.

Server-seitig: Hier messen wir Laufzeit und Speicherverbrauch. Cloud-Anbieter liefern Kostenmetriken, die grob mit Energie korrelieren: längere Laufzeiten und mehr Speicher bedeuten mehr Energieverbrauch. Für genauere Analysen helfen Tools wie der Green Metrics Tool, das den Energieverbrauch eigener Server in kontrollierten Umgebungen sichtbar macht.

Netzwerk-Transfer ist einfacher messbar. Bundle-Größe, komprimierte Übertragungsgröße und Anzahl der HTTP-Requests stehen in direktem Zusammenhang mit Energieverbrauch. Mehr Daten im Netz bedeuten mehr Energie in Rechenzentren, Netzwerkinfrastruktur und Endgeräten.

Client-seitig ist es am schwierigsten. Den tatsächlichen Akkuverbrauch können wir nicht messen, aber Lighthouse-Metriken dienen als Annäherung: Total Blocking Time korreliert mit CPU-Auslastung, Time to Interactive zeigt, wann eine Seite wirklich nutzbar wird.

Performance-Optimierung und Energie-Optimierung sind größtenteils dieselbe Arbeit.

Netzwerk-Gewinne sind am einfachsten zu erreichen. Seiten sollten nicht unnötig groß werden (z. B. unter 300 KB JavaScript). Die Next.js-Komponente next/image optimiert Bilder automatisch, liefert moderne Formate wie WebP und nutzt Lazy Loading. Vergleiche zwischen PNG und WebP zeigen: WebP reduziert Dateigrößen um 25-35 % ohne sichtbaren Qualitätsverlust und bis zu 90 % bei minimalen Einbußen.

Der effektivste Hebel ist oft, große JavaScript-Frameworks zu vermeiden oder sie nur dort einzusetzen, wo sie wirklich notwendig sind, da sie häufig den größten Anteil am ausgelieferten Code haben.

Client-seitige Effizienz bedeutet, darüber nachzudenken, was wann ausgeführt wird. Ein konkretes Beispiel mit Lazy Loading in React:

Dieses Muster verzögert das Laden der Chart-Library, bis Nutzende sie wirklich öffnen. Wenn nur 30 % der Nutzenden diese Funktion sehen, sparst du 70 % unnötigen Download. Virtual Scrolling rendert nur sichtbare Elemente in langen Listen. Lazy Loading verschiebt nicht-kritische Ressourcen nach hinten.

Ein Beispiel aus der Praxis: Dropbox reduzierte JavaScript-Bundlegrößen um 33 % und die Anzahl der Scripts um 15 %, indem sie ihren Legacy-Bundler durch Rollup ersetzten. Die Performance verbesserte sich sofort messbar. Die Energieeinsparung lässt sich schwer exakt ausrechnen, wird aber im großen Maßstab deutlich.

Bist du jetzt bereit zu messen? Hier ist ein Überblick über zentrale Metriken über alle drei Schichten hinweg, was sie über Energieverbrauch aussagen und was du konkret tun kannst:

Perfekte Messbarkeit ist nicht das Ziel, Verbesserung schon. Fang mit dem an, was sichtbar ist: Bundle-Größe und Lighthouse-Scores.

Nimm dir diese Woche eine einzelne Metrik vor. Lauf Lighthouse auf deinen wichtigsten Seiten und schau dir die Total Blocking Time an. Prüfe deine größten Bundles und hinterfrage jede Abhängigkeit. Der ökologische Fußabdruck deines Codes ist unsichtbar, aber seine Optimierung wird greifbarer. Fange mit dem Messen an. Optimiere deinen Code. Davon profitieren Nutzende und Umwelt gleichermaßen.

Chrome DevTools Coverage Tab: https://developer.chrome.com/docs/devtools/coverage
webpack-bundle-analyzer: https://www.npmjs.com/package/webpack-bundle-analyzer
Website Carbon Calculator: https://www.websitecarbon.com/
Green Metrics Tool: https://www.green-coding.io/products/green-metrics-tool/

• VWO - What You Can Do To Reduce the Carbon Footprint of Your Website
• DEV Community - What makes a website green? A guide for front end devs
• DebugBear - Why We Don't Report Website Carbon Emissions
• Sustainable Web Design - Estimating Digital Emissions
• Read the Tea Leaves - JavaScript performance beyond bundle size
• Calibre - Small Bundles, Fast Pages: What To Do With Too Much JavaScript
• Dropbox - How we reduced the size of our JavaScript bundles by 33%