JavaScript ist die einzige Ressource im Web, die zweimal kostet. Ein Bild wird übertragen, angezeigt und liegt danach still. Ein Skript wird übertragen, ausgepackt, übersetzt, ausgeführt, und dann arbeitet es weiter: bei jedem Scrollen, jeder Mausbewegung, jedem Timer. Die erste Rechnung siehst Du im Netzwerk-Tab. Die zweite läuft auf einem Gerät, das Du nie in der Hand hattest.
Die drei Erfolgskriterien von Guideline 3.11
Nachhaltiges JavaScript: Schreibe JavaScript, das die langfristige Performance der Anwendung unterstützt, indem Du unnötige Berechnungen reduzierst, DOM-Aktualisierungen begrenzt und Netzwerkanfragen minimierst.
Energierelevante APIs: Nutze JavaScript-APIs wie Compression Streams, Page Visibility oder Vibration dort, wo sie helfen, den Energieverbrauch zu senken oder die Effizienz zu verbessern.
API-Anfragen: Rufe client- oder serverseitige APIs nur dann auf, wenn es nötig ist. Stelle sicher, dass Anfragen und Antworten nur die für die Aufgabe erforderlichen Daten enthalten.
Meine Einordnung
Von den drei Punkten oben ist der erste der wirkungsvollste, und darin wiederum die DOM-Aktualisierungen. Der Grund liegt in der Arbeitsweise des Browsers: Ändert ein Skript ein Element im Seitenbaum, muss er das Layout neu berechnen und neu zeichnen. Passiert das in einer Schleife, entstehen aus einer sichtbaren Änderung schnell Hunderte Neuberechnungen. Rein rechnerisch ist das die teuerste Sache, die eine Website auf dem Endgerät anstellen kann, teurer als das Herunterladen des Skripts selbst.
Das dritte Kriterium ist das, bei dem sich Nachhaltigkeit und Datenschutz treffen. Jede API-Anfrage ist ein Datenpaket in beide Richtungen, dazu Verbindungsaufbau und Wartezeit. Zwei Fragen entscheiden hier alles: Muss der Aufruf überhaupt stattfinden, und wenn ja, wie viel Feld darf mitreisen.
Auf datensm.art habe ich das an mehreren Stellen konsequent umgesetzt. Die Suche arbeitet mit einem Index, der beim Bauen der Website entsteht und als Datei ausgeliefert wird. Es gibt keine Suchanfrage an einen Server, weil es keinen Server gibt, der suchen müsste. Beim KGMID-Check ist ein echter externer Dienst im Spiel, dort läuft die Anfrage über einen eigenen Vermittler, der jedes Ergebnis zwischenspeichert. Wer denselben Begriff ein zweites Mal sucht, löst keinen zweiten Aufruf bei Google aus, sondern bekommt die abgelegte Antwort. Dazu ein Anfragelimit, damit nicht ein einzelner Nutzer die Schnittstelle heiß laufen lässt. Und der Green Check fragt die Green Web Foundation ausschließlich dann, wenn jemand aktiv darauf klickt.
Wo ich weiter gehe
Die Guideline fragt, wie Du JavaScript effizient schreibst. Ich stelle davor die Frage, ob es JavaScript sein muss. Der Browser kann heute vieles von Haus aus, wofür vor Jahren noch ein Skript nötig war: aufklappbare Bereiche mit dem details-Element, Dialoge mit dem dialog-Element, verzögertes Laden von Bildern über ein einzelnes Attribut, weiches Scrollen über eine Zeile CSS. Jede dieser nativen Lösungen ist nicht nur kleiner, sondern schneller, barrierefreier und funktioniert auch dann noch, wenn das Skript wegen einer schlechten Verbindung gar nicht ankommt.
Und dann ist da die Sache mit der Rechnung. Ich messe meine Website auf einem aktuellen Rechner mit schneller Leitung. Dort ist jedes Skript flott. Die Menschen, die meine Seite tatsächlich aufrufen, sitzen zum Teil vor fünf Jahre alten Telefonen, deren Prozessor ein Vielfaches länger braucht und deren Akku dabei mitzahlt. Die Kosten für schweres JavaScript trage nicht ich, sondern sie. Genau deshalb wird an dieser Stelle so selten gespart: Wer die Rechnung nicht bekommt, prüft sie auch nicht.
Dein erster Schritt heute
Hol Dir die Rechnung, die sonst jemand anders bezahlt.
Und wenn Du danach aufräumen willst, fang bei den Bausteinen an, die es doppelt gibt: eine Bibliothek für einen Effekt, den CSS auch beherrscht, ein Skript für ein Aufklappmenü, das HTML seit Jahren nativ kann.
Das energieeffizienteste Skript ist das, das der Browser nie ausführen muss.
Quelle: W3C-Fassung von Guideline 3.11