Diese Seite wurde von der Cloud Translation API übersetzt.

In CrUX jetzt verfügbare Navigationstypen

Barry Pollard

Johannes Henkel

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.

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.

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:

Gestapeltes Balkendiagramm, das den Verlauf der Navigationstypen in den letzten 3 Wochen zeigt, wobei der Großteil der Navigation als „Navigation“ verwendet wurde und keine größeren Änderungen während der drei Wochen. — Navigationstypen im Zeitverlauf

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.

Korrelationsdiagramm, das eine starke Korrelation zwischen dem Anteil der Instant- und dem bfCache-Seitenaufbau zeigt — Korrelation zwischen dem sofortigen Laden von Seiten und der bfcache-Nutzung

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 (siehe FROM-Klausel) und filtern form_factor nach phone und wählen Ursprünge mit einem Beliebtheitsrang <= 10.000 für die Top-10.000-beliebtesten Ursprünge aus (siehe Klausel WHERE).
Bei der Abfrage des Messwerts navigation_types in BigQuery müssen Sie durch die Gesamtzahl der navigation_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.

Screenshot des Bildschirms für die Verteilung der Navigationstypen im Chrome UX-Dashboard mit den Daten eines Monats — Navigationstypen im CrUX-Dashboard

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.