An ein paar Stellen hatte ich es ja schon mal durchblicken lassen, dass ich Googles Kommunikation bezüglich Web Performance und Core Web Vitals für optimierungsbedürftig halte. Damit meine ich nicht einmal die verschiedenen Tools, ihre Zusammenspiel und ihre unterschiedlichen Versionen. Sondern tatsächlich die ganz konkrete Präsentation der Daten. PageSpeed Insights (PSI) schätze ich zwar, weil es einem direkt Lab- und Felddaten zusammen anzeigt, aber es ist leider auch ein Quell für Missverständnisse.

Score und Felddaten

Die Ergebnisseite von PageSpeed Insights ist für mich tatsächlich die Krönung missverständlicher Kommunikation. Oben prangt der Score, darunter folgen gleich die Felddaten – diese haben aber gar nichts miteinander zu tun. Das kann man sich zwar aus der Seite erarbeiten, wenn man alle Links klickt, Folgeseiten liest, Zusatzinfos einblendet etc., aber das macht ja kaum jemand.

Verwirrung Nummer 1: Score und Felddaten haben nichts miteinander zu tun.

Felddaten und Labdaten-Screenshot

Direkt neben den Felddaten bekommt man einen Screenshot angezeigt. Dieser Screenshot stammt allerdings aus dem Lab-Test mit Lighthouse – müsste also vernünftigerweise neben dem Bereich „Labdaten“ angezeigt werden. Wird er allerdings nicht. Damit trägt er weiter dazu bei, dass Menschen irgendwie das Gefühl haben, dass die Felddaten Ergebnis der eben durchgeführten Performance-Analyse sind.

Verwirrung Nummer 2: Lighthouse-Screenshot neben Felddaten.

LCP – selbe Zeit, unterschiedliche Bewertung

Zu guter Letzt noch der Largest Contentful Paint (LCP) in Feld- und Labdaten, der jedoch unterschiedlich bewertet wird. In den Core Web Vitals gibt es einen Satz Schwellenwerte – egal welches Endgerät. Lighthouse hingegen unterscheidet zwischen Mobile und Desktop. Konkret:

GoodNeeds ImprovementPoor
CWV=< 2500 ms2500 ms < und =< 4000 ms> 4000 ms
LH Mobile=< 2520 ms2520 ms < und =< 4010 ms> 4010 ms
LH Desktop=< 1210 ms1210 ms < und =< 2410 ms> 2410 ms
Schwellenwerte von LCP in Core Web Vitals und Lighthouse in Desktop und Mobile

Das kann nun also dazu führen, dass man eventuell in den Felddaten (CWV) einen LCP im grünen Bereich hat (z.B. 2,4 s) und in den Labdaten (Desktop) sogar einen besseren Wert erzielt hat (z.B. 2,3 s), der LCP in den Labdaten aber gelb mit „Needs Improvement“ eingestuft wird, während der LCP in den Felddaten trotz eines schlechteren Wertes grün in „Good“ eingestuft ist.
Technisch kann ich das ein Stück weit nachvollziehen, es sind nunmal unterschiedliche Tools am Werk, aber die PSI-Ergebnisseite führt diese in sehr ähnlicher Präsentation zusammen und da kann man sich schon mal am Kopf kratzen, wenn die selbe Metrik unterschiedlich eingestuft wird ohne ersichtliche Erklärung.

Doku: Auf Deutsch nur FCP und FID

Jetzt könnte man sagen: Dann muss man halt einfach die Doku ordentlich lesen, dann weiß man das auch alles. RTFM! Leider ist die Kommunikation da auch nicht so gut. Auf der Doku von PageSpeed Insights ist oben rechts eine Sprachenauswahl. Ich habe nicht aktiv deutsch ausgewählt, das scheint irgendwie automatisch ausgewählt zu werden.

Wenn man sich da noch nicht auskennt kommt einem das vermutlich auch nicht komisch vor. Die Doku behandelt v5 von PageSpeed Insights, was die aktuelle Version ist. Gaaaanz unten steht klein „Last updated 2018-12-05 UTC.“, was ein Hinweis darauf sein könnte, dass bei einem so aktuellen Thema die Seite doch vermutlich veraltet ist. Aber ansonsten ist das Problem nur mit Kenntnissen über den zu erwartenden Inhalt zu erkennen.

Die deutsche Doku kennt nur FCP und FID. LCP? CLS? Nie gehört. Bei den Labdaten kommt noch der First Meaningful Paint vor, den man schon länger nicht mehr auf der Ergebnisseite finden kann. Eine Erwähnung von diesem ominösen „Core Web Vitals“? Fehl am Platz.

Man ist wohl am besten beraten einfach immer die englische Dokumentation zu lesen. Die anderen Sprachversionen sind übrigens durchmischt, manche sind auch noch veraltet, manche schon aktuell.

PSI-API: Keine Felddaten? Origin Fallback!

Zum Schluss noch eine Sache, die nicht eindeutig schlechte Kommunikation ist, aber ich kann das Verhalten der API nicht so ganz nachvollziehen. In der JSON-Antwort der PSI-API gibt es einen Bereich für das Ergebnis der Felddaten (Abschnitt „loadingExperience“), einen für die Origin Daten (Abschnitt „originLoadingExperience“) und einen für das Ergebnis der Lab-Daten aus dem Lighthouse-Test (Abschnitt „lighthouseResult“).

Auf der PSI-Ergebnisseite im Browser wird der Bereich der Origin Daten angezeigt, wenn es keine Felddaten gibt für eine URL. In der API gibt es das auch. Aber nicht (nur) im Abschnitt „originLoadingExperience“, wo man es einfach erwarten würde. Die Daten im Abschnitt „loadingExperience“ der API sind in Wirklichkeit Origin Daten, wenn der bool’sche Key „origin_fallback“ auf „true“ gesetzt ist. Das passiert, wenn es keine Felddaten für die angefragte URL gibt, aber Origin Daten vorhanden sind.

Wer sich also wundert, dass er*sie per API Felddaten für eine URL bekommt, die im Browser bei PSI immer nur Origin Daten hatte, sollte nochmal checken, ob „origin_fallback“ im eigenen Code beachtet wird.