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 Unterschieden in den Leistungsmesswerten. Wenn Sie sich die Leistung Ihrer Website ansehen, ist es daher hilfreich, die relative Häufigkeit dieser verschiedenen Typen zu verstehen. Wenn beispielsweise eine Navigation den Back-Forward (bfcache) verwendet, führt dies normalerweise zu einer nahezu sofortigen Navigation, was sich in sehr kleinen LCP- und FCP-Messwerten sowie in reduzierten CLS- und INP-Messwerten widerspiegelt.
Durch die Aufschlüsselung der Navigationstypen möchten wir Websiteinhabern die Navigation auf ihren Websites näherbringen und einige der schnelleren Typen unterstützen, 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 anfänglichen Verlauf von 3 Wochen und der Erhöhung der Abdeckung in den nächsten 6 Monaten wöchentlich bis zur vollständigen Abdeckung), im aktuellen CrUX-BigQuery-Dataset und im CrUX-Dashboard verfügbar. Anhand des Verlaufs können Websiteinhaber außerdem Änderungen bei der Nutzung der Navigationstypen im Zeitverlauf sehen. So lassen sich Verbesserungen nachverfolgen (z. B. das Entfernen der bfcache-Blockierung). Außerdem lassen sich damit Messwertänderungen erklären, selbst wenn keine Änderungen an den Websites vorgenommen wurden.
Welche Navigationstypen sind in Chrome zur Nutzererfahrung in Chrome verfügbar?
In der folgenden Tabelle werden die folgenden Navigationstypen unterschieden:
Typ | Beschreibung |
---|---|
navigate |
Seitenaufbau, der keiner der anderen Kategorien zugeordnet werden kann |
navigate_cache |
Ein Seitenaufbau, bei dem die Hauptressource (das Haupt-HTML-Dokument) aus dem HTTP-Cache bereitgestellt wurde. Websites nutzen häufig das Caching für Unterressourcen, aber das Haupt-HTML-Dokument wird häufig deutlich weniger im Cache gespeichert. Wenn dies möglich ist, kann dies zu spürbaren Leistungsverbesserungen führen, da die Daten lokal und auf einem CDN im Cache gespeichert werden können. |
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 eines Schließens eines Tabs. Seitenaktualisierungen führen häufig dazu, dass eine erneute Validierung auf dem Server durchgeführt wird, um zu überprüfen, ob sich die Hauptseite geändert hat. Ein hoher Prozentsatz an Seitenaktualisierungen kann auf frustrierte Nutzer hinweisen. |
restore |
Die Seite wurde nach einem Browserneustart oder einem Tab, der aus Speichergründen entfernt wurde, neu geladen. Bei Chrome unter Android werden diese stattdessen als reload gemeldet. |
back_forward |
Eine Verlaufsnavigation, d. h., die Seite wurde vor Kurzem aufgerufen und wieder aufgerufen. Mit korrektem Caching sollten die Ergebnisse relativ schnell geladen werden, aber dennoch muss die Seite verarbeitet und JavaScript ausgeführt werden – beides wird vom bfcache vermieden. |
back_forward_cache |
Eine Verlaufsnavigation, die vom bfcache bereitgestellt wurde. Die Optimierung deiner Seiten für die Nutzung des bfcache sollte zu einer schnelleren Nutzererfahrung führen. Websites sollten versuchen, bfcache-Blocker zu beseitigen, um den Prozentsatz der Aufrufe in dieser Kategorie zu verbessern. |
prerender |
Die Seite wurde vorab gerendert, was – ähnlich wie bfcache – dazu führen kann, dass die Seite nahezu sofort geladen wird. |
In einigen Fällen kann ein Seitenaufbau eine Kombination aus mehreren Navigationstypen sein. In diesem Fall meldet das Bericht zur Nutzererfahrung in Chrome die erste Übereinstimmung in umgekehrter Reihenfolge der vorherigen Tabelle (von unten nach oben).
Einschränkungen der Navigationstypen in Chrome zur Nutzererfahrung in Chrome
Da es sich bei CrUX-Daten um ein öffentliches Dataset handelt, ist die Berichtsgenauigkeit eingeschränkt. Für viele Quellen und URLs ist der Messwert navigation_types
nicht verfügbar, weil nicht genügend qualifizierte Zugriffe vorliegen. Weitere Informationen finden Sie in der CrUX-Methodik.
Außerdem ist es in CrUX nicht möglich, andere Messwerte nach Navigationstyp aufzuschlüsseln, da sich dadurch die Anzahl der in CrUX verfügbaren Ursprünge und URLs weiter verringern würde.
<ph type="x-smartling-placeholder">Wir empfehlen, dass Websites ihr eigenes RUM (Real User Monitoring) implementieren, um den Traffic nach Kriterien wie Navigationstypen aufzuschlüsseln. Beachten Sie, dass die Navigationstypen in diesen Lösungen je nach Art des Berichts und den darin enthaltenen Seitenaufrufen variieren können. Weitere Informationen finden Sie im Artikel Warum unterscheiden sich CrUX-Daten von meinen RUM-Daten?.
RUM kann auch mehr Details zu bestimmten Leistungsproblemen liefern. Zum Beispiel könnte CrUX den Eindruck erwecken, dass es sich lohnen würde, die bfcache-Eignung zu verbessern. Die bfcache notRestoredReasons API kann jedoch genau ermitteln, warum ein bestimmter Seitenaufbau nicht aus dem bfcache geladen 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, sodass 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 ausführlicher 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 dem Anteil der Seitenladevorgänge für jeden Navigationstyp. Jeder Bruchteil entspricht einem Wert zwischen 0.0
(0% der Seitenladevorgänge) und 1.0
(100% der Seitenladevorgänge) für den jeweiligen Schlüssel.
Diese Antwort zeigt, dass für den Erfassungszeitraum vom 6. März 2024 bis einschließlich 2. April 2024 6, 77% der Aufrufe (Seitenaufrufe) aus dem bfcache des Browsers ausgeführt wurden. Ebenso können auch einige der anderen Gruppen Möglichkeiten für Optimierungen beim Seitenaufbau aufzeigen. Beachte, dass die navigation_types
-Brüche für jeden Schlüssel (einschließlich einer Kombination aus einer URL oder einem Ursprung und einem 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, um diese Anteile im Zeitverlauf zu visualisieren. Wenn Sie Ihre Anfrage von der CrUX API in die CrUX History API ändern möchten, führen Sie sie über den Endpunkt queryHistoryRecord
statt über queryRecord
aus. In unserem CrUX History Colab wird beispielsweise der Messwert navigation_types
als gestapelte Balken dargestellt:
Im Screenshot oben ist der Verlauf nur für 3 Erfassungszeiträume verfügbar (jeweils 28 Tage im Abstand von 7 Tagen). Wenn das Feld vollständig ausgefüllt ist, deckt dies alle 25 Erfassungszeiträume ab. Durch die Visualisierung dieses Verlaufs können Sie prüfen, ob die Optimierungen bereits wirksam sind oder bereits zurückgegangen sind. Dies gilt insbesondere für die HTTP-Cache-Konfiguration, bei der eine Seite für bfcache und Pre-Rendering optimiert wird.
Navigationstypen in BigQuery zur Nutzererfahrung in Chrome
Die CrUX-BigQuery-Tabellen enthalten jetzt einen navigation_type
-Eintrag für jeden Typ, während die materialisierten zusammenfassenden Ansichten mehrere navigation_types_*
-Spalten enthalten – eine für jeden Typ.
Detaillierte Tabellen
Das detaillierte Tabellenschema in CrUX-BigQuery liefert detaillierte Histogramme für die Leistungsmesswerte im Web, die es uns ermöglichen, in dieser Beispielanalyse zu zeigen, wie bestimmte Navigationstypen mit einer sofortigen oder guten Ladeleistung korrelieren können.
Wir haben uns beispielsweise den back_forward_cache
-Anteil und seinen Zusammenhang mit der Häufigkeit des sofortigen Ladens von Seiten (instant_lcp_density
wird als LCP <= 200 ms) und der Häufigkeit angesehen, mit der ein guter LCP erkannt wurde (good_lcp_density
wird als LCP <= 2.500 ms definiert). Es wurde eine starke statistische Korrelation zwischen back_forward_cache
und instant_lcp_density
(Ж=0,87) – wie im folgenden Diagramm dargestellt – und eine mäßige Korrelation zwischen back_forward_cache
und good_lcp_density
(p=0,29) festgestellt.
Der Colab für diese Analyse ist gut kommentiert. Hier geht es nur um die Abfrage, mit der die „Navigations-Typen“-Brüche für die 10.000 beliebtesten Ursprünge aus den detaillierten Tabellen in CrUX BigQuery extrahiert werden:
- Wir greifen hier auf die Tabelle
all.202403
zu (sieheFROM
-Klausel) und filternform_factor
nachphone
und wählen Ursprünge mit einem Beliebtheitsrang <= 10.000 für die Top-10.000-beliebtesten Ursprünge aus (siehe KlauselWHERE
). - Bei der Abfrage des Messwerts
navigation_types
in BigQuery müssen Sie durch die Gesamtzahl dernavigation_types
-Bruchteile dividieren, da sich diese nur nach Ursprung und nicht pro Kombination (Ursprung, Formfaktor) addieren lassen. - Nicht alle Ursprünge haben
navigation_types
, daher empfiehlt es sich,SAVE_DIVIDE
zu 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 ausreichend ist, ist es oft zweckmäßiger (und kostengünstiger), stattdessen die materialisierten Tabellen abzufragen. Mit der folgenden Abfrage werden beispielsweise die verfügbaren navigation_types
-Daten aus der Tabelle chrome-ux-report.materialized.device_summary
extrahiert. Diese Tabelle ist nach Monat, Ursprung und Gerätetyp angegeben.
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 Brüche nicht 1,0 pro Zeile ergeben.Daher ist es notwendig, jeden Bruch durch die Summe der Ergebnisse zu dividieren, 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 Dichten von Histogrammen – bis zu 1,0 pro Ursprung und nicht pro Ursprung und Gerät und Datum addieren. So können Sie sich die Verteilung der Navigationstypen auf verschiedenen Geräten 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 Bruchteile den Prozentsatz der Seitenladevorgänge für den Ursprungsort https://www.google.com
an: 6,63% dieser Seitenaufrufe hatten den Navigationstyp back_forward
auf Smartphones, 1,79% auf Computern und 0,09% auf Tablets.
Der deutlich höhere back_forward
-Prozentsatz auf phone
deutet darauf hin, dass wir versuchen könnten, diese Seitenladevorgänge zu optimieren, damit sie aus dem bfcache geliefert werden können.
Es ist jedoch auch wichtig zu berücksichtigen, welcher Anteil der Seitenladevorgänge bereits vom bfcache bereitgestellt wird, d. h. von der bfcache-Trefferquote. Die folgende Abfrage deutet darauf hin, dass dieser Ursprung möglicherweise bereits gut optimiert ist, da seine > 60% Trefferraten bei Smartphones und Computern.
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 zu zurückzuführen, sondern vielmehr darauf, wie Nutzer auf ihren Smartphones vorwärts und rückwärts navigieren.
Navigationstypen im Chrome UX-Dashboard
Die Navigationstypen lassen sich am einfachsten im CrUX-Dashboard aufrufen, das für den Ursprung über diesen Link aufgerufen werden kann. Wie Sie dem folgenden Screenshot entnehmen können, sind anfangs nur die Daten eines Monats verfügbar, aber im Laufe der Zeit füllt sich der Verlauf und Sie sehen Änderungen der Typen Monat für Monat.
<ph type="x-smartling-placeholder">Wie Sie auch sehen können, haben wir die schnelleren Navigationstypen, die optimiert werden sollten, oben auf dieser Seite des Dashboards hervorgehoben.
Fazit
Wir hoffen, dass die Aufschlüsselung der Navigationstypen in Chrome für Sie hilfreich ist und Sie damit die Leistung Ihrer Website besser nachvollziehen und optimieren können. Durch die effiziente Nutzung von HTTP-Caching, bfcache und Pre-Rendering können Seiten viel schneller geladen werden als Seitenladevorgänge, bei denen eine Rückkehr zum Server erforderlich ist.
Wir freuen uns außerdem, die Daten an allen verschiedenen CrUX-Zugriffspunkten verfügbar zu machen, damit Nutzer die Daten nach Belieben nutzen und die Typen in den CrUX-APIs nach URL aufgeschlüsselt sehen können.
Wir würden uns sehr über Feedback zu dieser Ergänzung von CrUX in den sozialen Medien oder in der CrUX-Diskussionsgruppe freuen.