Messen – web performance rocks

Neben dem Optimieren von Code und dem Interpretieren von Metriken müssen diese Zahlen auch irgendwo her kommen. An dieser Stelle möchte ich einen Überblick über verschiedene Messmethoden und -Tools geben. Ich werde mich hier (fast) nur auf Googles eigene Tools beschränken, da diese einerseits kostenlos sind und andererseits die Basis für Googles Core Web Vitals sind. Es gibt im Umfeld von Web Performance natürlich noch diverse Anbieter von Mess-Tools, die unterschiedliche Alleinstellungsmerkmale haben.

Synthetic

Unter Synthetic- oder Lab-Testing versteht man das automatische Testen der Performance einer Website. Hier kommen Skripte zum Einsatz, die die Seite aufrufen und dann Performance-Werte messen. Der Vorteil von Synthetic-Tests ist, dass sie häufig ausgeführt werden können und so der Einfluss einer Änderung auf eine URL nachvollzogen werden kann (sofern die Website ansonsten stabil ist). Der Nachteil ist, dass sie eben keine echten User*innen ersetzen und daher nicht für ein Nachempfinden der tatsächlichen Performance verstanden werden dürfen.

Tools

Lighthouse

Lighthouse ist im Prinzip das Standard-Tool in Googles Performance-Arsenal. Man kann Lighthouse als Node-Module verwenden, als CLI-Tool von der Konsole, es ist in den Developer-Tools des Chrome-Browsers enthalten und dient als Basis für die Lab-Tests in Googles PageSpeed Insights (s.u.). Lighthouse führt einen Test mit einem simulierten Mobil- oder Desktop-Gerät aus und präsentiert anschließend die Ergebnisse. Neben Performance-Audits kann Lighthouse eine Website auch hinsichtlich Accessibility, Einhaltung von Best Practices, SEO und PWAs (Progressive Web Apps) untersuchen. Außerdem gibt es mit Lighthouse CI die Möglichkeit Lighthouse in ein Continuous Integration-System einzubinden.

Wichtig an dieser Stelle ist anzumerken, dass Lighthouse nicht gleich Lighthouse ist. Einerseits sind in den verschiedenen Tools (PageSpeed Insights, Chrome Browser) nicht immer zur selben Zeit die selben Lighthouse-Versionen im Einsatz. Andererseits ist ein lokal ausgeführtes Lighthouse aber auch merklich abhängig von dem Rechner, auf dem es gerade läuft und wie sehr dieser aktuell anderweitig beansprucht ist.

PageSpeed Insights

PageSpeed Insights (PSI) stellt für mich Googles bestes Performance-Tool zum Messen dar. Es vereint Field-Data, Lab-Data, gibt konkrete Hinweise für Verbesserungen und hat darüber hinaus noch eine API. Obwohl unter der Haube Lighthouse genutzt wird hat auch PSI eine eigene Version, Änderungen können in den Release Notes verfolgt werden. Die aktuell eingesetzte Lighthouse-Version findet sich weiter unten auf der Ergebnisseite eines Tests.

Score und Labdaten

Die in PSI eingegebene URL wird zwei Lighthouse-Tests unterzogen: Mobil und Desktop. Die Ergebnisse werden anschließend auf der Ergebnisseite angezeigt. Diese kann allerdings anfangs etwas verwirrend sein. Ganz oben wird man mit einem Score begrüßt, der als Gesamt-Bewertung für die Performance herhalten soll. Darunter folgen dann vier einzelne Metriken:

First Contentful Paint (FCP)
First Input Delay (FID)
Largest Contentful Paint (LCP)
Cumulative Layout Shift (CLS)

Diese stehen allerdings unter der Überschrift „Field-Data“/“Felddaten“ (sofern vorhanden) und haben nichts mit dem Score zu tun! (Sie sind allerdings auch sehr wichtig, aber dazu kommen wir gleich.) Unter diesem Abschnitt kommt der Abschnitt „Origin Summary“ (sofern vorhanden, evtl. durch Haken bei „Quellenübersicht einblenden“ anzeigen) und dann folgt der Abschnitt „Lab-Data“/“Labdaten“ mit sechs Metriken, die die Basis für den oben prominent dargestellten Score sind:

First Contentful Paint (FCP)
Speed Index
Largest Contentful Paint (LCP)
Time to Interactive (TTI)
Total Blocking Time (TBT)
Cumulative Layout Shift (CLS)

Wer die genaue Gewichtung der einzelnen Messwerte sehen und mit ihnen rumspielen möchte kann unter den Metriken auf den Link „See calculator“ klicken, der öffnet den Score-Calculator mit den vorausgefüllten Werten des Testlaufs.

Felddaten und Core Web Vitals

Kommen wir noch einmal zurück zu den Felddaten. Diese Felddaten kommen aus dem CrUX-Report, wobei CrUX für Chrome User Experience steht. Das sind Messwerte, die von echten User*innen der für den Test angegebenen URL stammen – es handelt sich hier also um einen kostenlosen Datensatz an RUM-Data (s.u.). Diese Daten kommen ausschließlich aus Chrome-Browsern – das sollte bei der Bewertung immer im Hinterkopf behalten werden. Gemessen werden die Daten, weil die User*innen Google die Erlaubnis zum Sammeln dieser Metriken gegeben haben. Die hier angegebenen Werte für FID, LCP & CLS bilden die Core Web Vitals, welche seit Juni 2021 Einfluss auf das Ranking in Googles Suchergebnissen haben.
Hingegen der CrUX-Report (s.u.) immer nur Daten für vollständige Monate anzeigt sind die CrUX-Daten (Felddaten) im PSI-Report ein „Moving Target“: Es werden immer die letzten 28 Tage abgedeckt, daher verändern sie sich kontinuierlich von Tag zu Tag (wenn auch meist nur gering).

Wieso bekommt man nicht für jede URL Felddaten angezeigt?

Zum einen werden Felddaten erst ab einer gewissen Menge an Datensätzen ausgegeben. Zum anderen ist der Zeitraum wichtig: Felddaten erstrecken sich über 28 Tage. Ist die URL jünger könnte das auch der Grund sein, weshalb keine Felddaten angezeigt werden.

Was ist die Origin Summary?

Die Origin Summary gibt Felddaten im Schnitt über alle Seiten der Domain an. Also lasse ich beispielsweise PSI die URL https://web-performance.rocks/messen analysieren. Dann beziehen sich Lab- und Felddaten genau auf diese URL. Die Origin Summary tut das nicht! Sie gibt eine Zusammenfassung der Felddaten zu allen Adressen dieser Origin (hier https://web-performance.rocks) an, also neben der Startseite z.B auch von https://web-performance.rocks/metriken-core-web-vitals und auch https://web-performance.rocks/impressum.
Die Origin Summary wird einem angezeigt, wenn es für eine URL keine Felddaten, aber eine Origin Summary gibt. Das heißt für die zu analysierende URL gibt es nicht genügend qualifizierte Felddaten, aber genügend andere URLs dieser Origin haben Felddaten, sodass eine Origin Summary gebildet werden konnte. Gibt es Felddaten muss man die Origin Summary durch einen Haken bei „Quellenübersicht einblenden“ anzeigen. Ist eine Domain ganz frisch oder wenig besucht (mit dem Chrome-Browser), dann gibt es weder Felddaten noch eine Origin Summary.

Nutzt man die API von PageSpeed Insights muss im Bereich der Felddaten (das ist der Key loadingExperience) auf den Key origin_fallback achten. Ist dieser Key gesetzt (true) werden einem unter loadingExperience keine Felddaten, sondern Origin-Daten ausgegeben.

WebPageTest

WebPageTest.org (WPT) ist das Schweizer Taschenmesser der Pagespeed-Analyse-Tools. Es bietet Lab-Tests mit echten, unterschiedlichen Browsern von unterschiedlichen Orten auf der Welt. Man kann mehrere aufeinander folgende Aufrufe machen um z.B. die Auswirkung eines Caches zu testen, es kann zwischendurch JavaScript ausgeführt werden und noch vieles andere mehr. Nach den erfolgten Tests (ein Lighthouse-Test ist auch integriert) erwartet einen ein umfangreiches Analyse-Arsenal. Wer sich einen Account erstellt kann auch auf die eigene Test-Historie zugreifen. Prinzipiell ist WPT kostenlos. Seit 2021 gibt es die Möglichkeit einen API-Zugang zu nutzen, der dann Geld kostet. Man kann sich auch eigene Instanzen der WPT-Software aufsetzen, beispielsweise um Tests gegen interne URLs laufen zu lassen.

pagespeed10x

Shameless plug an dieser Stelle: pagespeed10x ist ein kleines Tool von mir das die oben erwähnte PageSpeed Insights API benutzt. Die Testergebnisse werden anschließend in eine InfluxDB geschrieben und die Performance-Daten dann mittels eines Grafana-Dashboards visualisiert. So kann man Lab- und Felddaten für mehrere URLs übersichtlich über einen Zeitverlauf sammeln, vergleichen und analysieren.

RUM

RUM steht für Real User Monitoring (oder manchmal auch „Measurements“). Damit sind im Gegensatz zu Synthetic-Tests bzw. Lab-Data Performance-Metriken gemeint, die bei der Interaktion von echten User*innen mit der Website entstanden sind. Synthetic-Tests sind beispielsweise nicht in der Lage die Metrik FID zu messen, da diese auf einer Interaktion mit der Seite basiert. Neben der Messbarkeit von Metriken unterscheidet sich auch das Verhalten. Während ein Sythetic-Test in der Regel nur den First-View der Seite bis zu Ende lädt verhalten sich User*innen oft anders, beispielsweise fangen sie bereits an runterzuscrollen bevor die Seite fertig geladen hat.

Von Google gibt es einen Satz kostenlose RUM-Daten, den CrUX-Report. Die Daten aus diesem Report finden wir in PageSpeed Insights, Search Console und dem CrUX Dashboard in Googles Data Studio. (Anleitung zur Einrichtung des CrUX Dashboard in Googles Data Studio)
Zu bedenken gilt bei diesem Datensatz, dass er ausschließlich im Chrome-Browser gesammelt wird. Ist die Website-Audience beispielsweise eher im Firefox beheimatet ist dieser RUM-Datensatz eventuell nicht die beste Basis für die Analyse der Website-Performance der eigenen User*innen.

Man kann auch selbst Daten mit Googles Web Vitals-JavaScript erfassen und an ein eigenes Analytics-Tool senden. Dabei gibt es aber ein paar Dinge zu beachten. Es werden nicht alle Metriken von allen Browsern unterstützt und jeder Browser-Hersteller hat die den Messungen durch das JavaScript zugrundeliegenden APIs selbst implementiert. Dadurch kann es Unterschiede in der Messung geben kann, wie Tim Kadlec am Beispiel von FCP ausführlich gezeigt hat. Darüber hinaus finden sich auf den jeweiligen web.dev-Seiten der Metriken immer wieder Hinweise, dass es Unterschiede zwischen der API und der Metrik gibt, weshalb man hier nicht identische Werte erwarten darf.

Custom Metrics

Auf dieser Seite und allgemein in der Web Performance geht es viel um die von Google definierten Metriken, was nicht zuletzt an der Einführung der Core Web Vitals und ihrer Berücksichtigung als Ranking Faktor in den Suchergebnissen liegen dürfte. Aber je nach Website oder Web-App können ganz andere Metriken relevant sein, viel speziellere vielleicht auch. Die Core Web Vitals versuchen ja möglichst allgemein auf jede Website anwendbar zu sein.

Wenn man Lighthouse für die Perfomance-Messung nutzen möchte gibt es die Möglichkeit Lighthouse mit sogenannten Custom Audits zu erweitern. Damit kann man selbst definieren was und wie gemessen wird und auch wie dieses Ergebnis dann zu interpretieren ist. Im GitHub-Repo gibt es ein Beispiel für ein Custom Audit und wie es ausgeführt werden kann.

Wer WebPageTest einsetzt kann ebenfalls mittels JavaScript eigene Metriken erheben. Die Doku gibt einen Überblick zu der Funktionalität und hilft noch mit einigen anschaulichen, übersichtlichen Beispielen.

Außerdem gibt es auch noch die Performance API im Browser mit der man mittels JavaScript unabhängig von Mess-Tools Timings messen kann. In Diensten wie WebPageTest und PageSpeed Insights tauchen diese seitenspezifischen Messungen dann zusätzlich auf den Ergebnisseiten auf.