Web Performance: PageSpeed Insights erklärt

Das nützliche Tool von Google zur Messung der Performance von Webseiten vereint Feld- & Labordaten, hat jedoch einige Schwächen. Wir erklären die Fallstricke.

Lesezeit: 8 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen

(Bild: Kolleen Gladden/Unsplash)

Von
  • Hilko Holweg

Das Thema Web Performance wird derzeit klar von Google dominiert. Der Suchmaschinenriese stellt jedoch nicht nur Forderungen an die Performance einer Website, sondern bietet auch Tools zur Messung an. Eines davon ist PageSpeed Insights, das wir in diesem Artikel näher vorstellen. Obwohl dessen Interface auf den ersten Blick eindeutig aussieht, gibt es doch mehrere Stolpersteine beim Verständnis der Ergebnisseite.

Mit PageSpeed Insights lässt sich die Web Performance einer URL testen. Neben der Ausführung im Browser gibt es für PageSpeed Insights auch eine API. Wer programmieren kann, hat so die Möglichkeit, automatisiert Tests auf beliebigen (öffentlichen) URLs auszuführen.

Die API-Dokumentation der PageSpeed Insights bietet Informationen zur Nutzung mit cURL und JavaScript sowie einen API-Explorer. Soll die API häufiger befragt werden, empfiehlt sich ein API-Schlüssel, sonst kommt man schnell an die Nutzungsgrenze. Der API-Schlüssel ist kostenlos und setzt ein Google-Konto voraus. Wer bereits eingeloggt ist, kann auf der Seite der API-Dokumentation direkt mit einem Button einen API-Schlüssel erzeugen, ohne in die Google Developer Console zu wechseln.

Auf der Startseite von PageSpeed Insights können Sie die zu testende URL eintragen. Im Hintergrund führt Googles Tool Lighthouse nun zwei Tests durch, einen Desktop-Test und einen mit einem simulierten Mobil-Gerät. Letzteres zeichnet sich durch drei Eigenschaften aus:

  • eine angepasste Auflösung,
  • eine reduzierte Internetgeschwindigkeit (zurzeit eine schnelle 3G-Verbindung) und
  • der Prozessor wird um das 4-fache verlangsamt.

Ein häufiges Missverständnis: Nicht der eigene Rechner führt den Test durch, sondern ein Google-Server. Daher hat das Testergebnis auch nichts mit der eigenen Internet- oder Rechner-Geschwindigkeit zu tun, geschweige denn mit lokal vorhandenen Chrome- oder Lighthouse-Versionen.

Nach dem Test werden Sie zur Ergebnisseite weitergeleitet. Voreingestellt befinden Sie sich dann im Reiter "Mobil". Zum "Desktop"-Ergebnis wechseln Sie mit einem Klick oben links.

Score, Labdaten und Screenshot gehören zum Lighthouse-Test.

Die Ergebnisseite liefert einen Score, der zwischen 0 und 100 liegt. Der Score ist ein Resultat aus den etwas weiter unten aufgeführten Labdaten. Dabei handelt es sich um sechs Metriken, die der Lighthouse-Test ermittelt hat. Zwischen Score und Labordaten gibt es die Bereiche Felddaten und Origin Summary (in manchen Ansichten auch Quellenübersicht genannt).

Klein und unscheinbar: Der Link zum Lighthouse Scoring Calculator.

Direkt unter den Labdaten ist im Text der kleine Link "Siehe Rechner" versteckt. Damit öffnet sich der Lighthouse Scoring Calculator. Wenn Sie ihn direkt aus einer Ergebnisseite heraus aufrufen, ist er vorausgefüllt mit den Werten genau dieses Tests. Mithilfe der Regler können Sie 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 sehen Sie beispielsweise, dass Largest Contentful Paint und Total Blocking Time alleine 55 Prozent des Scores ausmachen und somit eine Verbesserung dieser Werte einen hohen Einfluss auf den Score hat.

Seit Lighthouse 8 dabei: Empfehlungsfilter.

Im Bereich Empfehlungen und Diagnose listet die Seite Performance-Schwächen der getesteten URL auf und welche Verbesserungen diese eventuell bringen könnten. Falls 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 oberhalb der Liste auch Filter. Falls Sie sich zunächst auf eine Verbesserung des Largest Contentful Paint (LCP) konzentrieren möchten, lassen sich so nur die Empfehlungen für eine Verbesserung dieser Metrik anzeigen.

Ganz am Ende: Die Lighthouse- und Chrome-Versionen werden ausgegeben.

Etwas unscheinbar findet sich am Ende der Ergebnisseite 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 Sie Lighthouse-Tests vergleichen möchten. Beispielsweise verwendet PageSpeed Insights zum Zeitpunkt der Veröffentlichung dieses Artikels Lighthouse 8, während in Chromes Developer Tools noch Lighthouse 7 zum Einsatz kommt und erst mit Chrome 93 Ende August das Major-Upgrade zur v8 vollzogen wird.

Aber noch einmal zurück an den Anfang der Ergebnisseite zu den Felddaten und der Origin Summary. 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 Nutzer:innen ersetzen und daher nicht für ein Nachempfinden der tatsächlichen Performance verstanden werden dürfen.

Felddaten kommen bei PageSpeed Insights aus dem CrUX-Report, wobei CrUX für Chrome User Experience steht. Das sind Messwerte, die von echten Surfenden 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.)

Die CrUX-Daten kommen ausschließlich aus Chrome-Browsern – das sollten Sie bei der Bewertung immer im Hinterkopf behalten. Dort fließen Daten von Browsern derjenigen ein, die Google eine Erlaubnis zum Sammeln dieser Metriken erteilt haben.

Daraus lässt sich auch bereits ableiten, weshalb nicht für jede URL Felddaten angezeigt werden. Einerseits werden Felddaten erst ab einer gewissen Menge an Datensätzen ausgegeben, andererseits ist der Zeitraum wichtig: Sie erstrecken sich über 28 Tage. Ist die URL jünger könnte das auch der Grund sein, weshalb keine Felddaten angezeigt werden. Wichtig ist also, dass über die letzten 28 Tagen ausreichend qualifizierte Daten im CrUX-Report für die getestete URL vorliegen.

Da die Felddaten über die vergangenen vier Wochen ermittelt werden, fällt hier eine vorgenommene Performance-Anpassung nicht sofort ins Gewicht, sondern erst nach und nach über die nächsten vier Wochen.

An dieser Stelle sei auch nochmal deutlich auf ein häufiges Missverständnis hingewiesen, 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! Die Felddaten stammen aus dem CrUX-Report von echten Nutzer:innen, der Score gehört zu den Labdaten des eben ausgeführten, automatisierten Lighthouse-Tests!

Lesen Sie auch

Die Origin Summary gibt Felddaten im Schnitt über alle Seiten der Domain an. Gibt es generell Felddaten für Seiten unter dieser Domain, aber nicht für die konkret getestete URL, dann wird die Origin Summary eingeblendet, die einen Gesamtüberblick über die Performance der Domain anzeigt. Gibt es hingegen Felddaten für die getestete URL und Sie möchten die Origin Summary sehen, dann müssen Sie diese erst durch einen Klick auf "Quellenübersicht einblenden" anzeigen.

Eine Besonderheit, die Ihnen vermutlich eher selten begegnet: zu wenige oder unvollständige 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 nur die fehlende ausgegraut. Bisher gab es nur die Anzeige aller Felddaten oder keiner.

Diese URL hat nicht genügend FID-Daten im CrUX-Report, besteht den Core Web Vitals-Test aber dennoch.

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

  • First Input Delay (FID),
  • Largest Contentful Paint (LCP) und
  • Cumulative Layout Shift (CLS)

bestehen, hat das natürlich auch Einfluss auf diese. 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 der Test für die anderen beiden Metriken bestanden wurde. 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.

PageSpeed Insights erklärt in 7 Minuten - Tutorial

(vza)