sum.cumo
28.01.2019 sum.cumo

Ein Audit der Google-Lighthouse-Audits

Wenn man alle Audits von Lighthouse 3 prüft und dann mit Lighthouse 4 weitermachen kann

Anmerkung: Wie es sich in den letzten Wochen abzeichnete, hat das Lighthouse-Team Version 4 auf den Weg gebracht. Dieser Artikel bezieht sich noch auf Version 3, und wir haben uns aus zwei Gründen dazu entschieden, ihn so zu veröffentlichen: Zum einen wollen wir abwarten, wie Version 4 ausgerollt wird (so bezieht sich die Dokumentation noch immer auf Version 3) und ob sich noch kurzfristig Anpassungen ergeben; zum anderen ändert sich an den Kritikpunkten nicht viel, so dass wir die beschriebenen Ideen auch implementiert haben.

Bei sum.cumo setzen wir auf Google Lighthouse, weil es sich in unseren Projekten als Analysewerkzeug für die Qualität unserer Websites und Apps ausgezeichnet hat. Wir setzen Lighthouse so stark ein, dass wir mit Lighthouse Keeper ein Modul entwickelt und veröffentlicht haben, das die Konfiguration von Lighthouse noch verbessert und vereinfacht.

Die Audits von Lighthouse sind aber nicht alle nützlich. Am deutlichsten ist dies bei der PWA-Kategorie, die bei Nicht-PWAs naheliegenderweise ausgeklammert werden sollte. Um einen möglichst effektiven Gebrauch von Lighthouse sicherzustellen, haben wir – Hauke (Ubl), Sven (Wagner) und Jens (Meiert) – einmal alle Audits einzeln geprüft, und damit alle Audits nochmal auditiert. Das Ergebnis stellen wir hier anhand der von uns deaktivierten Tests vor.

Nein: Serve Images in Next-Gen Formats

JPEG 2000, JPEG XR und WebP werden von Google als Bildformate der nächsten Generation definiert, und wir finden vor allem WebP interessant. Wir sind mit der Idee hinter diesem Audit grundsätzlich einverstanden, allerdings haben wir den Audit vorerst rausgenommen. Das liegt daran, dass der Einsatz von JPEG 2000 und JPEG XR noch keine Option ist und uns auch die aktuelle 73%-Unterstützung von WebP noch nicht befriedigt – daran ändert auch @srcset und entsprechendes Tooling noch nichts. Dazu verfolgen wir die Verbreitung von WebP bereits intensiv, so dass wir es, wenn wir die Zeit für geeignet halten, auch ohne Audits stärker einsetzen werden.

Nein: Address Bar Matches Brand Colors

Bei der Einfärbung der Adresszeile hatten wir unterschiedliche Ansichten, insgesamt aber halten wir den Zweck dieses Audits nicht für wichtig und zweifeln auch den gewählten Weg an. Die Einfärbung selbst scheint in erster Linie nicht zwingend notwendig für gute User Experience zu sein. Dann steht die Überlegung im Raum, ob die Farbe nicht programmatisch bestimmt werden könnte, was die Implementierung in Frage stellt. Und schlussendlich kamen bei uns auch die Markup-Puristen durch, in dem Sinne, dass bei uns die Idee, Farben über Meta-Elemente zu definieren, keine große Gegenliebe findet.

Nein: Contains Some Content When JavaScript Is Not Available

Die Diskussion hier war kurz, hatte sich schon in Vor-Audits abgezeichnet, dass wir diesen Audit nicht (mehr) für relevant erachten. Nicht weil wir in sum.cumo-Projekten ohnehin sicherstellen, dass Inhalte auch ohne Scripting verfügbar sind. Sondern weil wir zudem feststellen, dass die Unterstützung von JavaScript in der Praxis lange schon zwingend erforderlich ist: Keine Benutzergruppe im Web – ob Menschen mit herkömmlichen Web-Browsern oder mit assistiven Technologien, oder „Maschinen“ mittels Bots und Spidern – greift noch auf das Web ohne Aktivierung von JavaScript zu. (Dann mal nebenbei, was ist eigentlich „some content“?)

Nein: User Can Be Prompted to Install the Web App

Bei einem in unserer Runde stellten sich hier bereits die Nackenhaare auf, sieht er bei Web-App-Prompts geradezu ein Dark Pattern: Die Zeiten von unerbetenen „Zur Startseite machen“- und „Zu den Favoriten hinzufügen“-Aufforderungen ist dankenswerterweise vorbei, und nun soll dasselbe bei PWAs unterstützt und mittels Lighthouse ermutigt werden? In Erwägung dieses Vergleichs und unter Berücksichtigung, dass Nutzer den Zugang zu Web-Apps auch auf anderem Wege speichern können, sowie, dass der ohne diesen Prompt freiwerdende Platz viel wichtiger für den Nutzer sind, haben wir uns letztlich klar gegen diesen Audit entschieden.

Nein: Document Doesn’t Have a Valid hreflang

Generell muss man sagen, dass es für jeden Lighthouse-Audit nützlich ist, sich die entsprechende Dokumentation näher anzusehen. Obwohl es generell stimmig scheint, hreflang-Werte zu prüfen, überwiegt bei uns der Zweifel an @hreflang an sich, und wir verweisen auf die Fragen von Anne van Kesteren sowie die eher schwach für @hreflang haltende Antwort von Ian Hickson: „It's not widely used, but since it’s not widely misused either, leaving it seems mostly harmless“ ist für uns kein guter Grund für einen Audit. Entsprechend verzichten wir auf ihn.

Viele „jeins“

Es gab eine Reihe von Audits, die wir länger besprochen haben, darunter First Contentful Paint und First Meaningful Paint (Definitionen), Offscreen Images (kann man machen, muss man aber vielleicht nicht), Properly Size Images (es kann Gründe geben, größere intrinsische Bildgrößen zu akzeptieren), Uses Inefficient Cache Policy on Static Assets (Third-Party-Bedenken), Configured for a Custom Splash Screen (erinnert uns vage an Splashscreens Must Die) und Document Does Not Have a Meta Description (Jens hasst sie leidenschaftlich wegen ihrer Unsichtbarkeit). Aber: Wir belassen sie vorerst in unseren Tests.

Eine neue Lighthouse-Konfiguration

Wir integrieren und testen die Ergebnisse dieses Audits gerade in unseren Projekten und werden wenn sinnvoll weitere Anpassungen vornehmen – die Konfigurationsmöglichkeiten sind ein Aspekt, den wir an Lighthouse schätzen. Wenn erprobt, werden wir auch die Beispiel-Konfiguration von Lighthouse Keeper aktualisieren, um mit dieser mit einem aus unserer Sicht passenderen Satz an Audits arbeiten zu können. Wir werden berichten, entweder hier oder unter @sumcumo – aufgrund der jüngsten Entwicklung um Lighthouse 4 wohl sehr bald.