Seit ich mich mit Web Performance-Optimierung beschäftige und PageSpeed Insights einsetze habe ich viel gelernt und in Unterhaltungen mit Anderen die Stolpersteine des Tools kennen gelernt. So suggeriert die Ergebnisseite beispielsweise, dass der Score und die Felddaten in irgendeiner Weise zusammen hängen – sie stehen ja auch direkt untereinander.

Ich habe mich jetzt einmal hingesetzt und ein kleines, 7-minütiges Video-Tutorial über PageSpeed Insights aufgenommen. Darin erkläre ich zum einen die generelle Nutzung, aber auch die besagten Fallstricke.

Lasst mir gerne mal hier oder bei YouTube Feedback da, wie ihr das Video fandet und ob ihr gerne mehr solcher Tutorials sehen möchtet.

Ein Klick auf das Bild führt zum YouTube-Channel, wo es dann das Video zu sehen gibt.

Erklärt in 7 Minuten: PageSpeed Insights

Im Folgenden das Transkript des Videos.


Intro
Ahoi und herzlich Willkommen bei web-performance.rocks. Mein Name ist Hilko und ich möchte euch heute einen Überblick zu Googles Tool PageSpeed Insights geben. Dabei zeige ich euch wie ihr das Tool benutzen könnt und vor allem wie die Ergebnisseite zu verstehen ist und worauf ihr achten solltet.

PageSpeed Insights & API
PageSpeed Insights ist ein Tool von Google mit dem ihr die Performance einer URL testen könnt. Neben der Ausführung im Browser gibt es auch noch die Möglichkeit PageSpeed Insights über eine API zu verwenden. Wenn ihr etwas programmieren könnt habt ihr damit die Möglichkeit automatisiert Tests auf beliebige URLs auszuführen.

Informationen zur API findet ihr, wenn ihr hier oben auf DOCS klickt und anschließend in der linken Spalte unter „PageSpeed API“ auf „Get Started“. Ein kleiner Tipp noch: Wenn ihr vor habt häufiger die API zu befragen, dann holt euch einen API-Schlüssel, sonst kommt ihr relativ schnell an die Nutzungsgrenze.

Test im Browser
Kommen wir zurück zum Browser-Tool. In das Eingabefeld hier oben könnt ihr die zu testende URL eintragen. Ich nehme hier mal die Startseite meines Blogs web-performance.rocks.

Im Hintergrund werden jetzt zwei Test mit Googles Tool Lighthouse durchgeführt – ein Desktop-Test und einer mit einem simulierten Mobil-Gerät. Das simulierte Mobil-Gerät zeichnet sich durch drei Eigenschaften aus:

  • eine angepasste Auflösung
  • eine reduzierte Internetgeschwindkeit – zur Zeit eine schnelle 3G-Verbindung
  • und der Prozessor wird um das 4-fache verlangsamt.

Die Tests gehen von einem Server aus, der grob in meiner Nähe ist. Das ist auch das erste Missverständnis über das ich häufig gestolpert bin: Ein Test mit PageSpeed Insights wird nicht(!) vom eigenen Rechner ausgeführt und hat daher auch nichts mit der eigenen Internet- oder Rechner-Geschwindkigkeit zu tun. Der Test wird von Google-Servern durchgeführt.

Ergebnisseite – Score und Labdaten
Schauen wir uns nun einmal die Ergebnisseite an. Wenn der Test fertig ist befinden wir uns standardmäßig auf dem Reiter „Mobil“ – zum Desktop kann einfach per Klick gewechselt werden.

Oben bekommen wir prominent den Score präsentiert, der sich zwischen 0 und 100 bewegen kann. Der Score ist ein Resultat aus den unten aufgeführten Labdaten. Das sind 6 Metriken, die durch den Lighthouse-Test ermittelt wurden. Zwischen Score und Labdaten gibt es noch die Bereiche Felddaten und Origin Summary (in machen Ansichten auch Quellenübersicht genannt). Auf die beiden Bereiche gehe ich später noch ein.

Lighthouse Scoring Calculator
Direkt unter den Labdaten ist im Text der kleine Link „Siehe Rechner“ versteckt. Damit öffnet sich der Lighthouse Scoring Calculator. Wenn man ihn direkt aus einer Ergebnisseite heraus aufruft ist er vorausgefüllt mit den Werten genau dieses Tests. Mit Hilfe der Regler kann man sich nun anzeigen lassen, was eine Änderung einer Metrik für einen Einfluss auf den Score hätte. Interessant ist hier die Spalte „Weighting“, die die Gewichtung der jeweiligen Metrik angibt. So kann man beispielsweise sehen, dass Largest Contentful Paint und Total Blocking Time alleine 55% des Scores ausmachen und somit eine Verbesserung dieser Werte einen hohen Einfluss auf den Score hat.

Zurück zur Ergebnisseite!

Ergebnisseite – Empfehlungen & Diagnose
Im Bereich Empfehlungen und Diagnose listet die Seite Performance-Schwächen der getesten URL auf und welche Verbesserungen diese eventuell bringen könnten. Wenn man noch relativ frisch in der Web-Performance-Optimierung ist und die Probleme der eigenen Seite gar nicht so genau kennt finden sich hier erste Hinweise. Seit Lighthouse 8 gibt es auch diese Filter. Falls man sich beispielsweise erstmal auf eine Verbesserung des LCP konzentrieren möchte kann man so nur die Empfehlungen für eine Verbesserung dieser Metrik anzeigen.

Lighthouse und Chrome-Version
Etwas unscheinbar findet sich am Ende der Ergebnisseite noch die Information mit welcher Lighthouse- und Chrome-Version der Test durchgeführt wurde. Da beide Programme Einfluss auf die Messungen haben kann dies gerade bei Problem-Analysen eine wichtige Information sein, wenn sich plötzlich Messwerte ändern oder wenn man Lighthouse-Tests vergleichen möchte.

Kommen wir noch einmal an den Anfang der Ergebnisseite zurück. Da war ja noch was mit Felddaten und der Origin Summary.

Unterschied Felddaten und Labdaten
Zuerst einmal der generelle Unterschied zwischen Felddaten und Labdaten.

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.

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.

RUM steht für Real User Monitoring bzw. Real User Measurement.

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.

Jetzt erklärt sich vielleicht schon, weshalb wir nicht für jede URL Felddaten angezeigt bekommen.

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.

Auch möchte ich an dieser Stelle noch einmal deutlich auf ein häufiges Missverständnis hinweisen, da die Ansicht in PageSpeed Insights hier leider missverständlich ist: Die Felddaten – auch wenn sie direkt unter dem Score angezeigt werden – haben nichts mit dem Score zu tun und auch nichts mit dem eben durch Lighthouse durchgeführten Test!

Weiter zur Origin Summary!

Origin Summary
Was ist nun eigentlich die Origin Summary?

Die Origin Summary gibt Felddaten im Schnitt über alle Seiten der Domain an.

Das heißt, gibt es Felddaten für Seiten unter dieser Domain, aber nicht für die konkret getestete URL, dann wird die Origin Summary eingeblendet. Gibt es hingegen Felddaten für die getestete URL und man möchte die Origin Summary sehen muss man diese erst durch einen Klick auf „Quellenübersicht einblenden“ anzeigen.

Besonderheit: Teilweise Felddaten
Seit ein paar Wochen gibt es auch noch die Variante der unvollständigen Felddaten. Wenn Google nicht für alle Metriken ausreichend qualifizierte Felddaten zu der getesteten URL hat, dann werden seit kurzem alle anderen Metriken angezeigt und die fehlende ausgegraut.

Core Web Vitals
Da sich die Core Web Vitals aus den Felddaten speisen und aus den Metriken

  • First Input Delay
  • Largest Contentful Paint und
  • Cumulative Layout Shift bestehen hat das natürlich auch auf diese Einfluss. Der Core Web Vitals-Test kann nun nämlich auch bestanden werden, wenn für First Input Delay nicht ausreichend Daten zur Verfügung stehen, aber die anderen beiden Metriken bestanden sind. Diese Ausnahme gilt allerdings nur für First Input Delay, liegen für LCP oder CLS nicht ausreichend Daten vor, dann ist der Core Web Vitals-Test erstmal nicht zu bestehen.

Outro
Das war’s erstmal von mir mit dem kleinen PageSpeed Insights-Tutorial. Wenn euch das Video gefallen hat lasst gerne einen Like da und selbstverständlich könnt ihr den Channel auch abonnieren für weitere Web Performance-Inhalte. Auf meiner Website web-performance.rocks habe ich die gängigen Performance-Metriken auch im Detail erklärt und im Blog schreibe ich regelmäßig, wenn’s was Neues gibt. Danke für’s Zusehen und Tschüss Tschüss.