colspan=11: Performance-Sammelsurium

Fokus einer Jahreshälfte: Geschwindigkeitsoptimierung. Von Meta-Themen bis hin zu Tooling-Optionen.

In den letzten Monaten drehte sich meine Arbeit sehr um Performance – mit der Performance von sum.cumo-Projekten, mit der meiner eigenen Tests und Experimente und unseren Herangehensweisen allgemein. Diese Arbeit war zum einen dadurch motiviert, dass hohe (zumindest so wahrgenommene) Geschwindigkeit gut für den Umsatz ist (Stichwort: Conversions), mehr dann aber dadurch, dass Performance ein Schlüssel zu guter UX ist, und dann noch mal dadurch, dass man manchmal diesen vagen Eindruck hat, dass etwas vergessen wird.

Was vielleicht gerne vergessen wird, schien mir dann zunächst Folgendes: Dass Performance eigentlich ganz einfach ist, wenn man weiß, was wirklich wichtig ist. Und dass das sehr viel trivialer klingt – täuschend trivial –, als es ist. Denn hinter dem Verständnis davon, was wichtig ist, stecken jede Menge Details. Welche Inhalte sind wichtig? (Für uns oft nachrangig, weil selten unsere Profession.) Was ist technisch wichtig? Was ist technisch zwingend notwendig? Und diese Frage nach zwingender Notwendigkeit nimmt dem Trivialen alle Trivialität. Denn um das mit Gewissheit beantworten zu können, muss man wieder Expertenwissen haben. Damit scheint man sich im Kreis zu drehen, aber letztlich ist man schneller, wenn man weiß, was wirklich wichtig ist.

Performance als Prozess

Trivial mag ebenfalls erscheinen, dass Performance ein Prozess ist. Auch hier zerfällt der Eindruck der Trivialität schnell. Denn aus so manchen beliebten Visionen, die man vor allem für Performance-Budgetierung braucht, folgt eben nicht, dass Performance ein Prozess ist. Grundsätzlich trägt der Prozessgedanke der Situation Rechnung, dass wir es mit Systemen zu tun haben, die in Bewegung sind – unsere Projekte bewegen sich, unsere Werkzeuge bewegen sich, wir bewegen uns. Von daher muss sich Performance auch bewegen.

Anderswo wiederum zeichnet sich Googles Lighthouse als nützliches Tool aus. Es kann bereits "out of the box" auf viele Arten eingesetzt werden – CLI, Node-Modul, Browser-Erweiterung – und dennoch kann man noch mehr herauskitzeln. Bei der Auditierung aller Lighthouse-Tests fällt die gesamte PWA-Sparte (Progressive Web Apps) weiterhin negativ auf, was an zweifelhaften und zum Teil redundanten Tests liegt, sodass diese aus der Konfiguration rausfällt, die ich vor allem Websites empfehle – und die Lighthouse Keeper, ein Wrapper für Lighthouse, auch als Beispiel-Konfiguration kennt.

Die Performance-Tests aber sind im Großen und Ganzen stimmig, Lighthouse wird ein zunehmend wichtigerer Bestandteil qualitätsorientierten Toolings, und insgesamt kann man nur in Sonderfällen seriös gegen Qualität argumentieren. Und um die geht es letztlich ja auch bei Performance. ()