Ab dem Dataset vom März 2024 enthält der Bericht zur Nutzererfahrung in Chrome (CrUX) den Messwert navigation_types. So erhalten Sie zusammengefasste Statistiken zu den Navigationstypen beim Seitenaufbau für die abgefragte Dimension.
Unterschiedliche Navigationstypen führen zu unterschiedlichen Leistungsmesswerten. Wenn Sie sich die Leistung Ihrer Website ansehen, ist es daher hilfreich, die relative Häufigkeit der verschiedenen Typen zu kennen. Wenn für eine Navigation beispielsweise Zurück vorwärts (bfcache) verwendet wird, führt dies in der Regel zu einer nahezu sofortigen Navigation, was sich in sehr kleinen LCP- und FCP-Messwerten und reduzierten CLS- und INP-Messwerten widerspiegelt.
Wir hoffen, dass Websiteinhaber durch die Aufschlüsselung der Navigationstypen besser auf die auf ihren Websites verwendeten Navigationstypen aufmerksam werden. Wir möchten auch einige der schnelleren Typen fördern, indem wir uns die Caching-Einrichtung, bfcache-Blocker und Pre-Rendering ansehen.
Der Messwert „navigation_types“ ist in der täglichen CrUX API, der CrUX History API (mit einem 3-Wochen-Verlauf verfügbar und in den nächsten 6 Monaten wöchentlich auf vollständige Abdeckung), das aktuelle BigQuery-Dataset für Chrome und das CrUX-Dashboard verfügbar. Mithilfe des Verlaufs können Websiteinhaber außerdem Änderungen bei der Nutzung der Navigationstypen im Zeitverlauf sehen. Dadurch können Verbesserungen verfolgt werden (z. B. das Entfernen der bfcache-Blockierung). Außerdem können Sie damit Änderungen der Messwerte erklären, selbst wenn keine Änderungen an den Websites vorgenommen wurden.
Welche Navigationstypen sind in CrUX verfügbar?
CrUX unterscheidet in der folgenden Tabelle die folgenden Navigationstypen:
| Typ | Beschreibung |
|---|---|
navigate |
Ein Seitenaufbau, der in keine der anderen Kategorien passt. |
navigate_cache |
Ein Seitenaufbau, bei dem die Hauptressource (das HTML-Hauptdokument) aus dem HTTP-Cache bereitgestellt wurde. Websites nutzen oft das Caching von untergeordneten Ressourcen, das Haupt-HTML-Dokument wird jedoch häufig deutlich seltener im Cache gespeichert. Ist dies der Fall, kann es aufgrund der Möglichkeit, lokal und in einem CDN im Cache gespeichert zu werden, zu deutlichen Leistungsverbesserungen führen. |
reload |
Der Nutzer hat die Seite neu geladen – entweder durch Klicken auf die Schaltfläche zum Aktualisieren, durch Drücken der Eingabetaste in der Adressleiste oder durch Rückgängigmachen des Schließens eines Tabs. Seitenaktualisierungen führen häufig zu einer erneuten Validierung des Servers, um zu prüfen, ob die Hauptseite geändert wurde. Ein hoher Prozentsatz der Seitenaktualisierungen kann auf frustrierte Nutzer hindeuten. |
restore |
Die Seite wurde nach einem Browserneustart neu geladen oder ein Tab, der aus Speichergründen entfernt wurde, wurde neu geladen. In Chrome unter Android werden diese Werte stattdessen als reload gemeldet. |
back_forward |
Verlaufsnavigation, d. h., die Seite wurde vor Kurzem aufgerufen und danach wieder aufgerufen. Bei korrektem Caching sollten dies relativ schnell sein, aber dennoch die Verarbeitung der Seite und die Ausführung von JavaScript erfordern – und das vermeidet der bfcache. |
back_forward_cache |
Eine Verlaufsnavigation, die aus dem bfcache bereitgestellt wurde. Wenn du deine Seiten mithilfe des bfcache optimierst, kannst du sie schneller aufrufen. Websites sollten bfcache-Blocker entfernen, um den Prozentsatz der Navigationen in dieser Kategorie zu verbessern. |
prerender |
Die Seite wurde vorgerendert, was – ähnlich wie „bfcache“ – dazu führen kann, dass Seiten nahezu sofort geladen werden. |
In einigen Fällen kann ein Seitenaufbau eine Kombination aus mehreren Navigationstypen sein. In diesem Fall meldet das CrUX die erste Übereinstimmung in umgekehrter Reihenfolge der vorherigen Tabelle (von unten nach oben).
Einschränkungen der Navigationstypen in Chrome UX
Da es sich bei CrUX um ein öffentliches Dataset handelt, ist der Detaillierungsgrad der Berichterstellung eingeschränkt. Für viele Ursprünge und URLs ist der Messwert „navigation_types“ aufgrund unzureichenden zulässigen Traffic nicht verfügbar. Weitere Informationen finden Sie unter CrUX-Methodik.
Außerdem kann in CrUX keine Aufschlüsselung anderer Messwerte nach Navigationstyp erstellt werden, da dies die Anzahl der in CrUX verfügbaren Ursprünge und URLs weiter reduzieren würde.
Wir empfehlen, dass Websites ein eigenes RUM (Real User Monitoring) implementieren, um den Traffic nach Kriterien wie den Navigationstypen zu segmentieren. Beachten Sie, dass in diesen Lösungen je nach gemeldeten Typen und den enthaltenen Seitenaufrufen möglicherweise Unterschiede bei den Navigationstypen auftreten. Weitere Informationen finden Sie im Artikel Warum unterscheiden sich die CrUX-Daten von meinen RUM-Daten?.
RUM kann auch mehr Details zu bestimmten Leistungsproblemen liefern. Während CrUX beispielsweise andeutet, dass es sich lohnen würde, die bfcache-Eignung zu verbessern, kann die bfcache notRestoredReasons API genau darüber informieren, warum ein bestimmter Seitenaufbau nicht aus dem bfcache bereitgestellt werden konnte.
Navigationstypen in der CrUX API
Wenn Sie die Navigationstypen in der API sehen möchten, nehmen Sie den Messwert navigation_types in die Anfrage auf oder legen Sie keinen Messwert fest, damit alle Messwerte enthalten sind:
export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
--header 'Content-Type: application/json' \
--data '{"origin": "https://example.com", metrics: ["navigation_types"]}'
Das Anfrageformat wird in der API-Dokumentation genauer beschrieben, einschließlich einer Erläuterung zum Abrufen des API-Schlüssels und des API-Leitfadens. Dadurch wird ein Objekt wie dieses zurückgegeben:
{
"record": {
"key": { "origin": "https://example.com" },
"metrics": {
"navigation_types": {
"fractions": {
"navigate": 0.5335,
"navigate_cache": 0.2646,
"reload": 0.0885,
"restore": 0.0023,
"back_forward": 0.0403,
"back_forward_cache": 0.0677,
"prerender": 0.0031
}
}
},
"collectionPeriod": {
"firstDate": { "year": 2024, "month": 3, "day": 6 },
"lastDate": { "year": 2024, "month": 4, "day": 2 }
}
}
}
In der Antwort meldet CrUX den Messwert navigation_types als Objekt mit den Anteilen der Seitenladevorgänge für jeden der Navigationstypen. Jeder Bruchteil ist ein Wert zwischen 0.0 (0% des Seitenaufbaus) und 1.0 (100% der Seitenladevorgänge) für den jeweiligen Schlüssel.
Aus dieser Antwort geht hervor, dass während des Erfassungszeitraums ab dem 6. März 2024 bis einschließlich 2. April 2024 6, 77% der Navigationen (Seitenaufrufe) aus dem bfcache des Browsers bereitgestellt wurden. Gleichermaßen können auch einige der anderen Anteile helfen, Möglichkeiten zur Optimierung des Seitenaufbaus zu erkennen. Beachten Sie, dass die navigation_types für jeden Schlüssel (einschließlich einer Kombination aus URL oder Ursprung und Formfaktor) ungefähr 1,0 ergeben.
Navigationstypen in der CrUX History API
Die CrUX History API kann eine Zeitreihe für Navigationstypen mit bis zu 25 Datenpunkten pro Bruch bereitstellen. Dadurch können diese Anteile im Zeitverlauf visualisiert werden. Wenn Sie Ihre Anfrage von der CrUX API in die CrUX History API ändern möchten, führen Sie sie am Endpunkt queryHistoryRecord statt am queryRecord aus. In unserem CrUX-Verlaufs-Collab wird beispielsweise der Messwert navigation_types als gestapelte Balken dargestellt:
Im Screenshot oben ist der Verlauf nur für drei Erhebungszeiträume verfügbar (jeweils 28 Tage im Abstand von 7 Tagen). Wenn das Feld vollständig ausgefüllt ist, deckt es alle 25 Erfassungszeiträume ab. Durch die Visualisierung dieses Verlaufs lässt sich überprüfen, ob die Optimierungen wirksam geworden sind oder bereits behoben wurden. Dies gilt insbesondere für die HTTP-Cache-Konfiguration, bei der eine Seite für bfcache und Pre-Rendering optimiert wird.
Navigationstypen in BigQuery für CrUX
Die BigQuery-Tabellen für CrUX enthalten jetzt einen navigation_type-Eintrag für jeden Typ, während die materialisierten Zusammenfassungsansichten mehrere navigation_types_*-Spalten enthalten – eine für jeden Typ.
Detaillierte Tabellen
Das detaillierte Tabellenschema in BigQuery für CrUX enthält detaillierte Histogramme für die Leistungsmesswerte im Web. So können wir in dieser Beispielanalyse zeigen, wie bestimmte Navigationstypen mit sofortiger oder guter Ladeleistung korrelieren können.
Wir haben uns als Beispiel den Anteil der back_forward_cache angesehen und ihre Korrelation mit der Häufigkeit der sofortigen Seitenladevorgänge (instant_lcp_density definiert als LCP <= 200 ms) und der Häufigkeit, mit der ein guter LCP festgestellt wurde (good_lcp_density definiert als LCP <= 2500 ms), betrachtet. Wir haben eine starke statistische Korrelation zwischen back_forward_cache und instant_lcp_density (im folgenden Diagramm dargestellt) und eine mäßige Korrelation zwischen back_forward_cache und good_lcp_density ({3}=0,29) beobachtet.
Der Colab für diese Analyse ist gut kommentiert. Hier geht es nur um die Abfrage, mit der die „navigation_types“-Brüche für die 10.000 beliebtesten Ursprünge aus den detaillierten Tabellen in CrUX BigQuery extrahiert werden:
- Hier greifen wir auf die Tabelle
all.202403zu (sieheFROM-Klausel), filternform_factornachphoneund wählen Ursprünge mit dem Beliebtheitsrang <= 10.000 für die 10.000 beliebtesten Ursprünge aus (sieheWHERE-Klausel). - Wenn Sie den Messwert
navigation_typesin BigQuery abfragen, müssen Sie durch die Summe dernavigation_types-Brüche dividieren, da sich diese nur nach Ursprung, aber nicht nach Kombination (Ursprung, Formfaktor) summieren. - Nicht alle Ursprünge haben
navigation_types, es empfiehlt sich daher,SAVE_DIVIDEzu verwenden.
WITH tmp AS (
SELECT
origin,
SUM(navigation_types.navigate.fraction) AS navigate,
SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
SUM(navigation_types.reload.fraction) AS reload,
SUM(navigation_types.restore AS restore,
SUM(navigation_types.back_forward.fraction) AS back_forward,
SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
SUM(navigation_types.prerender.fraction) AS prerender,
SUM(navigation_types.navigate.fraction
+ navigation_types.navigate_cache.fraction
+ navigation_types.reload.fraction
+ navigation_types.restore.fraction
+ navigation_types.back_forward.fraction
+ navigation_types.back_forward_cache.fraction
+ navigation_types.prerender.fraction) AS total
FROM
`chrome-ux-report.all.202403`
WHERE
experimental.popularity.rank <= 10000 AND
form_factor.name = 'phone'
GROUP BY
origin
)
SELECT
origin,
ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
tmp
Materialisierte Tabellen
Wenn eine Zusammenfassung ausreicht, ist es oft praktischer (und kostengünstiger), stattdessen die materialisierten Tabellen abzufragen. Die folgende Abfrage extrahiert beispielsweise die verfügbaren navigation_types-Daten aus der Tabelle chrome-ux-report.materialized.device_summary. Diese Tabelle ist nach Monat, Ursprung und Gerätetyp aufgeschlüsselt.
SELECT
yyyymm,
device,
navigation_types_navigate,
navigation_types_navigate_cache,
navigation_types_reload,
navigation_types_restore,
navigation_types_back_forward,
navigation_types_back_forward_cache,
navigation_types_prerender
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://example.com' AND
navigation_types_navigate IS NOT NULL
ORDER BY
yyyymm DESC,
device DESC
Beachten Sie, dass diese Summe nicht 1,0 pro Zeile ergibt.Daher muss jeder Bruch durch die Summe der Ergebnisse geteilt werden, anhand derer die Abfrage interpretiert werden soll.
Der Grund dafür ist, dass navigation_type-Brüche in chrome-ux-report.materialized.device_summary – wie die Histogrammdichten – insgesamt 1,0 pro Ursprung und nicht pro Ursprung und Gerät und Datum ergeben. So können Sie sich die Verteilung der Navigationstypen auf die verschiedenen Geräte ansehen:
SELECT
device,
navigation_types_back_forward
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
navigation_types_back_forward |
|---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
In diesem Abfrageergebniss geben die Anteile den Prozentsatz der Seitenladevorgänge für den Ursprung https://www.google.com an: 6,63% dieser Seitenladevorgänge hatten den Navigationstyp back_forward auf dem Smartphone, 1,79% auf Computern und 0,09% dieser Seitenladevorgänge.
Der deutlich höhere back_forward-Prozentsatz auf phone lässt darauf schließen, dass wir versuchen könnten, diese Seitenladevorgänge zu optimieren, damit sie aus dem bfcache bereitgestellt werden können.
Sie sollten aber auch berücksichtigen, welcher Anteil der Seitenladevorgänge bereits vom bfcache bereitgestellt wird, d. h. die bfcache-Trefferquote. Die folgende Abfrage deutet darauf hin, dass dieser Ursprung möglicherweise bereits gut optimiert ist, da die Trefferraten für Smartphones und Computer mehr als 60% betragen.
SELECT
device,
navigation_types_back_forward_cache /
(navigation_types_back_forward + navigation_types_back_forward_cache)
AS back_forward_cache_hit_rate
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
back_forward_cache_hit_rate |
|---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
Die hohe back_forward-Rate auf Smartphones scheint also nicht auf eine geringere bfcache-Nutzung zurückzuführen zu sein, sondern darauf zu schließen, wie Nutzer auf ihren Smartphones häufiger vorwärts und rückwärts navigieren.
Navigationstypen im CrUX-Dashboard
Navigationstypen finden Sie am einfachsten im CrUX-Dashboard, auf das Sie über diesen Link zugreifen können. Wie Sie im folgenden Screenshot sehen können, sind anfangs nur die Daten eines Monats verfügbar. Im Laufe der Zeit füllt sich jedoch der Verlauf, sodass Sie monatliche Änderungen der Typen sehen können.
Wie Sie auch sehen können, haben wir oben auf dieser Dashboard-Seite die schnelleren Navigationstypen hervorgehoben, die von Sehenswürdigkeiten optimiert werden sollten.
Fazit
Wir hoffen, dass die Aufschlüsselung der Navigationstypen in CrUX nützlich für Sie ist und Ihnen dabei hilft, die Leistung Ihrer Website besser zu verstehen und zu optimieren. Durch eine effiziente Nutzung von HTTP-Caching, bfcache und Pre-Renderings können Seiten viel schneller geladen werden als Seitenladevorgänge, bei denen ein Zurück zum Server erforderlich ist.
Wir freuen uns außerdem, die Daten an allen verschiedenen CrUX-Zugangspunkten zur Verfügung zu stellen, damit Nutzer die Daten nach Belieben verwenden können und die Typaufschlüsselungen nach URL für diejenigen sehen, die in den CrUX APIs verfügbar sind.
Wir würden uns über Feedback zu dieser Ergänzung zu Chrome in den sozialen Medien oder in der CrUX-Diskussionsgruppe freuen.