Nachhaltiges JavaScript und APIs nutzen
JavaScript kostet zweimal: beim Übertragen und bei jeder Ausführung auf fremder Hardware. Warum diese zweite Rechnung nie bei Dir landet.
Das ist die Kategorie, in der ich beruflich zu Hause bin. Sechzehn Guidelines beschreiben hier, wo Front- und Backend Ressourcen verbrauchen: Code, der übertragen, ausgewertet und ausgeführt wird, Anfragen, die Server beschäftigen, Dateien, die auf fremden Geräten Rechenzeit und Akku kosten.
Das Angenehme daran ist, dass diese Regeln fast nie im Widerspruch zu anderen Zielen stehen. Effizienter Code lädt schneller, ist leichter zu warten, funktioniert auch auf älteren Geräten und verbessert nebenbei die technische Auffindbarkeit bei Suchmaschinen. Wer hier optimiert, muss sich selten zwischen Nachhaltigkeit und Geschäftsinteresse entscheiden.
Und doch endet fast jede dieser Guidelines bei mir mit derselben Frage, die sie selbst nicht stellt: Muss dieser Baustein überhaupt existieren? Effizienz macht das Vorhandene sparsamer. Suffizienz fragt, was gar nicht erst gebaut werden muss.
JavaScript kostet zweimal: beim Übertragen und bei jeder Ausführung auf fremder Hardware. Warum diese zweite Rechnung nie bei Dir landet.
Ein Installationsbefehl, drei Sekunden, hunderte fremde Pakete im Projekt. Warum jede Abhängigkeit eine Verpflichtung auf Jahre ist.
Ein paar hundert Byte im Wurzelverzeichnis entscheiden darüber, ob Maschinen Deine Website effizient behandeln oder blind durchsuchen.
Jede Seite dieser Website wurde genau einmal berechnet. Warum statt dynamischer Erzeugung meist die fertige Datei die bessere Antwort ist.
Ein Versionssprung bei PHP kann dieselbe Seite spürbar schneller machen, ohne dass sich eine Zeile Code ändert. Effizienz durch Nichtstun.
Ein typischer CMS-Seitenaufruf löst Dutzende Datenbankabfragen aus, für Inhalte, die sich seit Wochen nicht geändert haben. Das geht anders.