Ein schlichter Textabsatz und ein aufwendiger Scroll-Effekt sehen im Browser gleich harmlos aus. In der Energiebilanz trennen sie Welten. Und trotzdem plant kaum ein Projekt ein Ziel dafür ein. Dabei gilt der einfachste Satz der ganzen Disziplin: Wer kein Ziel hat, kann es nicht verfehlen. Und optimiert ins Blaue.
Die zwei Erfolgskriterien von Guideline 3.1
Performance-Ziele: Setze klare Performance- und Umweltziele für das Projekt, einschließlich Obergrenzen für Requests, gerenderte Elemente oder anderen messbaren Ressourcenverbrauch.
Energieintensität: Bevorzuge ressourcenärmere Gestaltungsentscheidungen und achte auf die messbaren Unterschiede im Energieverbrauch der einzelnen Komponenten. Komplexe Strukturen, aufwendiges Styling und skriptgetriebene Erlebnisse sowie grafik- und medienlastige Darstellung erhöhen die Rechenkomplexität. Greife nur dort zu aufwendigeren Ansätzen, wo sie einen klaren Mehrwert bringen.
Meine Einordnung
Beide Kriterien oben laufen auf einen alten Ingenieurssatz hinaus: Was Du nicht misst, kannst Du nicht steuern. Ein Performance-Budget macht den unsichtbaren Ballast sichtbar. Es verwandelt “die Seite fühlt sich lahm an” in “wir liegen bei 2,3 MB, das Ziel sind 1,5”.
Und diese Zahlen sind nicht abstrakt. Eine grobe Faustregel aus meiner Beratungspraxis: 1 MB weniger pro Seitenaufruf spart bei einer Million Aufrufen rund 400 Kilogramm CO₂. Ein einziges nicht optimiertes Hero-Bild kann diese Größenordnung ausmachen. Ein Budget ist damit kein bürokratisches Korsett, sondern der Hebel, an dem die ganze Bilanz hängt.
Das zweite Kriterium, die Energieintensität, gibt Dir eine Entscheidungsregel für den Alltag. Nicht jede Zutat einer Seite kostet gleich viel Rechenaufwand: Unformatierter Text ist am günstigsten, CSS kostet mehr, JavaScript deutlich mehr, und ganz oben stehen WebGL und 4K-Video. Daraus folgt eine einfache Reihenfolge im Kopf: Bevor Du eine Animation in JavaScript baust, frag, ob CSS reicht. Bevor Du ein Video einbettest, frag, ob ein Bild genügt. Bevor Du ein Bild nimmst, frag, ob Text es auch tut.
Wo ich weiter gehe
Hier trennt sich mein Blick vom Wortlaut der Guideline. Sie ist eine Effizienz-Regel: Wähle die sparsamere Variante. Ich setze einen Schritt früher an. Die sparsamste Komponente ist nicht die, die Du effizient rendern lässt, sondern die, die Du gar nicht erst einbaust.
In der Praxis erlebe ich ein wiederkehrendes Muster: Teams behandeln ihr Performance-Budget wie ein Ausgabenlimit. “Wir haben 2 MB, also nutzen wir sie auch.” Genau das ist der Denkfehler. Ein Budget ist keine Einladung zum Ausschöpfen, sondern eine Obergrenze, die Du möglichst weit unterbieten willst. Die interessante Frage lautet selten “Wie rendere ich dieses Feature effizient?”, sondern “Muss dieses Feature überhaupt existieren?”
Dein erster Schritt heute
Fang mit einer einzigen Zahl an. Nimm Deine wichtigste Seite, miss ihr aktuelles Gewicht und die Zahl der Requests, und leg ein Ziel fest, das darunter liegt. Eine Zahl, aufgeschrieben, sichtbar fürs Team, mehr braucht es zum Start nicht.
Ein Budget bremst die Verschwendung. Aber die nachhaltigste Komponente bleibt die, die Du gar nicht erst lädst.
Quellen: W3C-Fassung von Guideline 3.1 · Interpretation bei Sustainable Web Design