colspan=13: Die zwei Säulen der Bildkomprimierung

colspan  –  0 Kommentare

Bildkomprimierung spielt eine wichtige Rolle in der Performance-Optimierung. Sie scheint ziemlich einfach zu sein. Das täuscht aber, da sie nicht nur aus einem, sondern zwei Teilen besteht. Fehlendes Verständnis eines dieser beiden Teile ist es, was oft dazu führt, dass Bildkomprimierung nicht effektiv – oder gar nicht – ausgeführt wird.

Was sind diese beiden Teile?

  1. Es gibt einen Tooling-Teil, der die Infrastruktur behandelt, um Grafiken sowohl manuell als auch automatisiert zu komprimieren. Dies ist der prominente Teil, der Performance sicherstellt oder verbessert.
  2. Dann gibt es einen Kontext-Teil, der sich a) darum dreht, welches Bild wie aggressiv komprimiert werden kann, und b) den notwendigen Informationsfluss für Team und Werkzeuge betrifft, sodass jede Grafik soweit es geht optimiert wird, ohne dabei ihre Funktion und die Möglichkeit zu verlieren, ihren Zweck zu erfüllen. Dieser Teil betrifft Qualität.

In der Praxis geschieht es, dass Komprimierung manchmal allein mit Tooling verwechselt und damit zu sehr vereinfacht, da auf einen Teil von Komprimierung reduziert wird. Der andere Teil wird vernachlässigt, wenn nicht ganz ausgelassen: Was für eine Art Bild wird optimiert (Foto oder Icon?), und wo wird es eingesetzt (Vorder- oder Hintergrund?) – wie also ist der Kontext? Unsere Werkzeuge sind bisher nicht gut darin, diesen Kontext selbst zu ermitteln. Mit Tooling, das nur aus kontextlosen Algorithmen besteht, beobachten wir somit Teams, die damit Probleme haben, Bilder effektiv oder überhaupt zu komprimieren.

Differenzierung ist dann wie so oft das Stichwort. Sie und wir wissen, dass das Problem nicht Komplexität in Bezug auf Tooling, sondern besagter Kontext ist: Teams haben zum Teil gar nicht genug Informationen, um Bilder zu komprimieren, egal ob manuell oder automatisch; Entwickler können ihre Werkzeuge zum Teil nicht gut genug konfigurieren, um bestimmte Grafiken stärker zu komprimieren. Und, ein Schritt davor, Designer mögen Entwickler nicht unbedingt darüber instruieren, welche Grafiken wo verwendet werden, um zu welchem Grad optimiert zu werden. Ebenso wenig ist unsere Informationsarchitektur so ausgelegt, dass sie Kontext verlässlich widerspiegelt (zum Beispiel mit etwas wie einem halbstandardisierten »icons«-Ordner, der aggressiv komprimiert werden könnte).

Wenn wir zwischen Tooling und Kontext differenzieren, stehen uns zwei Pfade offen: Zum einen können wir wie gehabt die notwendige Infrastruktur für die Bildkomprimierung aufsetzen (Editor-Plug-ins wie Image Optimizer für VS Code, Standalone-Apps wie ImageOptim, Pakete wie imagemin etc.). Zum anderen können wir den Informationsfluss formen, um den Kontext zu gewinnen, der notwendig ist, um in jedem einzelnen Fall über den angemessenen Grad der Komprimierung zu entscheiden, ob vollständige Automatisierung hierfür eine Möglichkeit ist.

Sie können nun sagen, dass das Aufsetzen des Toolings für Bildkomprimierung eher einfach ist. Da Kontext mit seinen ganz anderen Herausforderungen aber den Grad vielmehr als die Tatsache von Komprimierung betrifft, kann die Unterscheidung zwischen beidem helfen, sogar technische Einschränkungen zu überwinden: Sie können vollautomatisiertes Tooling aufsetzen, das verlustfrei komprimiert (wobei sich gegen Regressionen verwahrt werden sollte, wenn bereits optimierte Bilder erneut behandelt werden), um aggressivere Optimierung dann zu handhaben, wenn alle notwendigen Daten zum entsprechenden Kontext vorliegen.

Tooling und Kontext. Beides muss vorliegen, um Bildkomprimierung wirklich effektiv zu betreiben – und hier liegt die eigentliche Herausforderung aktuell nicht auf der technischen Seite.