Google Search Console (GSC) Speed Report

Geschwindigkeitsanzeigeanlage

Am 4. November 2019 hat Google den Speed Report für die Google Search Console veröffentlicht:

A fast web experience has long been an important user experience factor that we have promoted and advocated for. To help site owners on this quest we showed a preview of the Speed report in Search Console at Google I/O 2019. Since then, we’ve been iterating on all the great feedback from the beta testers and, starting today, are excited to begin public rollout!

(Zum vollständigen Announcement im Google Webmaster Central Blog)

Aktuell hat der Report die Anmerkung “(experimental)” im GSC Menü. Vollständig aus der Testingphase ist das Ganze aus Googles Sicht folglich noch nicht. (Stand 12.11.19)
GSC Menü Screenshot Speed Report (Experimentell)
Dennoch wollen wir uns den Report ansehen, denn neben Optimierungspotenzialen für die eigene Domain zeigt Google hier endlich offen, welche Grenzwerte in der Pagespeed-Bewertung ungefähr angelegt werden.

Zudem gibt es ein paar interessante Details, auf die wir aufmerksam geworden sind und gerne hier vorstellen möchten.

Für den Fall, dass der Link zum Report in Deiner Property noch nicht auftaucht, kannst Du ihn direkt unter diesem Link aufrufen:
https://search.google.com/search-console/speed

Der Speed Report ist da, aber leer? Hier findest Du die Erklärung.

Was sehen wir in dem neuen Report?

Google teilt den Report in zwei Bereiche: Mobile und Desktop.
Übersichtsseite des GSC Speed Reports

Wir sehen pro Device im Zeitverlauf, wie viele URLs als schnell, moderat oder langsam eingestuft werden.

Wenn wir den jeweiligen Bericht öffnen, sehen wir in den Details eine Unterscheidung zwischen zwei Messwerten:

  • FCP (First Contentful Paint)
  • FID (First Input Delay)

Die genaue Bedeutung der beiden Metriken erklären wir weiter unten im Abschnitt Messwerte. 

Wenn ein Problem mit der Seitengeschwindigkeit erkannt wurde, also URLs für mindestens einen der beiden Messwerte nicht schnell sind, wird die jeweilige Geschwindigkeit zusätzlich in langsam und moderat unterteilt.
Desktop Abschitt eines Google Search Console (GSC) Speed Reports
Die einzelnen Probleme kann man auch separat aufrufen, um mehr Details zu sehen.
Detailansicht zu einem Problem im GSC Speed Report
Detaillierte Ergebnisse für einzelne URLs gibt es dabei nicht, sondern nur eine Tabelle mit Beispiel-Werten. Daneben steht jeweils die Anzahl der URLs die durch dieses Beispiel repräsentiert werden sollen und der jeweils bemängelte Messwert, aggregiert für die jeweilige Gruppe.
Detailtabelle zu einem Problem im GSC Speed Report
Welche ähnlichen URLs es sind oder wonach die Gruppen gebildet werden, verrät Google leider nicht. Es werden, wenn man auf eine URL klickt, lediglich bis zu 20 weitere Beispiel-URLs einer Gruppe angezeigt.

Ob diese angezeigten URLs und die entsprechenden Gruppen von Google so gewählt sind, dass sie wirklich das gleiche Problem beschreiben ist noch nicht abzuschätzen.

Grundsätzlich sollte Google in der Lage sein, URLs zu erkennen, die zum Beispiel technisch auf dem gleichen Template basieren, aber es kann hier auch vorkommen, dass unter den Beispiel-URLs einer Gruppe verschiedene Templates auftauchen.

Möglicherweise sind diese Zusammenfassungen aber auch noch ein Grund, warum der Report derzeit als experimentell bezeichnet wird.

Pagespeed Grenzwerte von Google

Die angelegten Grenzwerte sind für Mobile und Desktop identisch, auch wenn eine strengere Einstellung im mobilen Bereich denkbar wäre.

Allerdings ist der Anteil der Nutzer, die den Grenzwert überschreiten müssen, damit die Geschwindigkeit als moderat oder langsam gilt, zwischen FCP und FID unterschiedlich.

Grenzwerte des Google Search Console Speed Report:

Fast Moderate Slow User Threshold
FCP <1s <3s >=3s 75 %
FID <100ms <300ms >=300ms 95 %

Ob die Grenzwerte zwischen schnell, moderat und langsam auch dem entsprechen, was Google als Rankingfaktor “Pagespeed” wertet bleibt weiterhin nur eine Mutmaßung.

Bei der Optimierung sollte man sich aber nicht nur auf eine Metrik konzentrieren, sondern immer die Ladezeiten als Gesamtbild im Auge behalten. Ein Guter Anhaltspunkt für die Relevanz der verschiedenen Aspekte der Seitengeschwindigkeit findet man bei der Definition der Chrome Lighthouse Audits.

Außerdem haben wir oben rechts in den Detailberichten den Button ”Fehlerbehebung überprüfen”, mit dem wir Google auffordern können, für diese URLs den Pagespeed erneut zu prüfen.

Die Validierung die durch den Button gestartet wird bezieht sich auf jeden Fall auf die Chrome UX (CrUX) Reports. Sobald die Fehlerbehebung gestartet ist, fängt Google an, Daten aus den CrUX-Reports zu sammeln.
Andere haben den Button schon einmal geklickt:

Das dauert solange bis genügend Daten gesammelt wurden, um zu prüfen, ob das Problem behoben ist. Kann Google das nicht innerhalb von 28 Tagen machen, zum Beispiel weil nicht genügend Nutzer innerhalb von 28 Tagen die CrUX-Reports mit Daten füttern, wird der Fehler allerdings nicht validiert. Das Interessante daran ist, dass Google sich an dieser Stelle vollständig auf die CrUX-Reports verlässt.

Beim FID ist das auch notwendig, da dazu eine Nutzerinteraktion notwendig ist. Auch wenn findige Köpfe bei Google durchaus in der Lage wären, einen automatisierten Test zu entwickelt, der eine FID zumindest zumindest schätzt.

Der FCP könnte natürlich von Google beim Rendern selbst gemessen werden. Aber der Vorteil der CrUX-Reports ist, dass es sich hier um Felddaten der Endgeräte der echten Nutzer handelt und nicht Testdaten aus dem Labor.

Was sind das für Messwerte?

FCP

First Contentful Paint (FCP) ist der Zeitpunkt beim Rendern, bei dem der Nutzer zum ersten mal etwas von der aufgerufenen URL sieht, zum Beispiel den Header oder ein Logo.

Dementsprechend handelt es sich um einen Messwert für den Beginn des Renderings einer Seite. Vereinfacht gesagt wird hier die Zeitspanne zwischen dem Abschicken des initialen Requests durch den Browser und dem Zeitpunkt, an dem der Nutzer einen Text oder ein Bild oder Ähnliches sehen kann, gemessen.

First Contentful Paint ist eine der wichtigsten Pagespeed-Metriken. Wenn es zu lange dauert, bis der Nutzer irgendetwas im Browser sieht, nachdem eine Seite aufgerufen wurde, wird der Nutzer ungeduldig und springt ab.
Unterschied zwischen FCP und Fertig Geladener Seite

FID

Im Gegensatz zum First Contentful Paint ist der First Input Delay bislang noch wenig beachtet. Für manche mag aber der First Input Delay sogar noch vollständiges Neuland sein. Schließlich braucht es für diese Metrik eine tatsächliche Nutzerinteraktion.

Es ist eher die Regel, als die Ausnahme, dass Nutzer nicht warten, bis eine Seite vollständig geladen ist, sondern auf den nächsten Navigationslink klicken oder herunterscrollen wollen, bevor der Ladeprozess abgeschlossen ist.

Häufig ist der Browser dann aber noch mit aufwändigen Hintergrundprozessen beschäftigt.

An sich ist es ja gut, wenn der Nutzer schnell den Content “Above The Fold”, also alles was der Nutzer sieht ohne das er scrollt, zu sehen bekommt. Aber wenn das Laden der Seite den Browser weiter so auslastet, dass er nur schwerfällig reagiert, dann ist das schlecht und frustriert (ungeduldige) Nutzer.

First Input Delay (FID) ist der Versuch, dieses Problem zu messen. FID ist die Zeit zwischen der ersten Interaktion des Nutzers mit einer Seite, meist ein Klick oder ein Scroll, bis zur ersten Reaktion des Browsers auf diese Interaktion.

Falls Du mehr darüber Wissen willst; die Google Chrome Developers haben sich die Mühe gemacht das im Detail aufzudröseln:

Übrigens, wenn Ihr FID-Werte für Eure Seiten selbst erfassen wollt, gibt es die Möglichkeit das per JavaScript zu messen.

Woher nimmt Google also die Daten für diesen Report?

Der Googlebot interagiert nicht mit dem Content, insofern kann auch kein FID gemessen werden. Daher können diese Daten nicht einfach vom Googlebot mit erfasst werden.

Die Datenquelle ist, wie auch bei den Vergleichsdaten im PageSpeed Insights Report, der Chrome User Experience Report.

Diese Daten werden von Google auch für die tatsächliche Pagespeedbewertung verwendet. Hier ist ein Statement von John Mu aus den Webmaster Hangouts vom 05.04.2018:

Und auch in den Google Webmasters Blogs wurde das schon bestätigt.

Die Chrome User Experience Reports sind Website-Nutzungsdaten von allen Chrome Nutzern, die dabei “helfen, die Funktionen und die Leistung von Chrome zu verbessern”.

Die Einstellung findest du übrigens in Chrome hier: chrome://settings/syncSetup
Menüpunkt für die Chrome User Experience Reports in Google Chrome Einstellungen

Keine Daten bei zu wenig Traffic

Es handelt sich um die tatsächlichen Ladezeiten von echten Nutzern. Das bedeutet aber auch, dass in dem Bericht nur URLs auftauchen können, die genügend Traffic von Chrome Nutzern haben.

Daher kann es gerade bei Domains mit wenig Traffic schnell mal vorkommen, das nicht genug Daten da sind, um den Report zu zeigen.

Möglicherweise bekommst Du also in deiner GSC-Property für einen oder beide Devices nur den Hinweis, dass nicht genügend Daten vorhanden sind:
Menüpunkt für die Chrome User Experience Reports in Google Chrome EinstellungenGSC Speed Report bei nicht Ausreichender Menge von Daten in den Chrome User Experience Reports

Dann bleibt dir nichts anderes übrig, als weiter auf die altbekannten Tools zurückzugreifen. Freundlicherweise ist in dem Fall auch direkt ein Link zu den PageSpeed Insights platziert.

Die Chrome User Experience Reports sind übrigens nicht nur über die Google Search Console und die PageSpeed Insights einsehbar. Es gibt ein öffentliches BigQuery Dataset mit den CrUX Daten auf Domainebene. Dieses Dataset enthält noch einige Metriken mehr.

Da die Daten aber nur auf Domainebene verfügbar sind, bleibt es auch über die BigQuery nur ein Traum, sich mal eben die Daten auf Folder-Ebene zu aggregieren, um einfach verschiedene Seitenbereiche zu vergleichen.

Was tun, wenn der Report nicht grün ist?

Keine Panik kriegen. Es gibt nur wenige Domains, bei denen die Mehrheit der URLs als schnell gewertet wird.

Wenn der Zeitpunkt, an dem die rote Linie plötzlich nach oben geht, mit einem Rollout zusammenpasst, sollte man sich nochmal genau ansehen. Wenn dann auch die betroffene Beispiel-URL zu dem Rollout gehörte, hat man schon eine recht eindeutige Korrelation. Hierdurch ist es recht einfach, dass exakte Problem zu Identifizieren.

Abgesehen davon sollte man sich die Ladezeiten der genannten URLs im Detail einmal ansehen. Besonders bei langsamen URLs ist eine gründliche Pagespeed-Kur für das Template immer sinnvoll.

Häufig zeigt auch ein kurzer Google Lighthouse Audit oder ein Blick auf die PageSpeed Insights direkt ein paar Probleme auf, die die Seite unnötig verlangsamen, und direkt gelöst werden können.

Also, nimm die URL, aus dem Report und lass den Lighthouse Audit (im Inkognito Modus) drüber laufen.

Fazit

Was bringt der Speed Report nun eigentlich?

  • Zur Ableitung konkreter Maßnahmen musst Du nach wie vor einen Google Lighthouse Audit anstrengen, den Network-Tab in den Chrome Dev Tools auseinander nehmen oder eines der anderen gängigen und bekannten Tools bemühen.
  • Der Report in der Google Search Console gibt Dir immerhin eine Idee davon, bei welchen URLs und Templates zuerst ansetzen musst/kannst .
  • Außerdem können ein paar rote Warnleuchten von Google sicherlich auch nicht schaden, um die große Bedeutung der Ladezeiten-Thematik zu unterstreichen. Vielleicht hilft der Bericht auch dabei, mehr Budget für das Thema Ladezeiten zu bekommen.

Link zur Google-Dokumentation des Reports: https://support.google.com/webmasters/answer/9205520
Link zur CrUX Dokumentation: https://developers.google.com/web/tools/chrome-user-experience-report


Verlinkt von

[…] Beitrag von Wingmen […]

Kommentare

Sven am 13. November 2019 um 12:56:42

Danke für diesen aufschlussreichen Artikel und deine entspannte und unaufgeregte Einschätzung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.