Core/Dash Dimension: Navigationstyp

Dimension: Navigationstyp (nt)

Jeder Seitenaufruf in Ihren CrUX-Daten enthält einen Navigationstyp. Er verrät Ihnen, wie der Browser die Seite geladen hat. Dies bestimmt, welche Browsersysteme beteiligt waren: der Netzwerk-Stack, der Back/Forward-Cache, die Prerender-Pipeline oder eine Sitzungswiederherstellung. CoreDash macht dies als nt-Dimension verfügbar, damit Sie Core Web Vitals für jeden Navigationskontext separat filtern und vergleichen können.

Die Daten stammen von der PerformanceNavigationTiming API, genauer gesagt aus der Eigenschaft type. Sie lesen sie mit performance.getEntriesByType("navigation")[0].type aus. Chrome meldet diesen Wert zusammen mit jeder an CrUX gesendeten Web Vitals-Messung. CoreDash speichert und indiziert ihn, sodass Sie ohne das Schreiben benutzerdefinierter Instrumentierung segmentieren können.

Warum der Navigationstyp wichtig ist

Das Aggregieren von LCP oder INP über alle Navigationstypen hinweg liefert eine Zahl, die technisch korrekt, aber in der Praxis irreführend ist. Ein Treffer im Back/Forward-Cache (bfcache) wird in Millisekunden abgeschlossen. Eine kalte Navigation wartet auf DNS, TCP, TLS und TTFB. Wenn 20 % Ihrer Sitzungen bfcache-Treffer sind, ziehen sie Ihren p75 LCP nach unten und erschweren es, ein echtes Problem bei neuen Navigationen zu erkennen.

Das Gegenteil ist ebenfalls der Fall. Wenn der bfcache auf Ihrer Website fehlerhaft ist, schneiden Back/Forward-Sitzungen genauso schlecht ab wie neue Navigationen. Ohne die Segmentierung nach Navigationstyp werden Sie dies nie bemerken, da der aggregierte Wert stabil bleibt.

Prerender ist der dramatischste Fall. Eine korrekt vorgerenderte Seite (Prerender) sollte einen LCP nahe null aufweisen, da das Rendering abgeschlossen wurde, noch bevor der Nutzer überhaupt auf den Link geklickt hat. Wenn Ihre vorgerenderten Seiten normale LCP-Werte aufweisen, ist die Konfiguration der Speculation Rules falsch und das Prerendering wird entweder nicht ausgelöst oder vor der Verwendung verworfen.

Die Navigationstypen

navigate

Eine Standardnavigation: Der Nutzer hat eine URL eingegeben, auf einen Link einer anderen Website geklickt oder ist einer Weiterleitung gefolgt. Dies ist ein vollständiges Laden der Seite ohne Caching-Abkürzungen. Der Browser durchläuft die komplette Request-Pipeline einschließlich DNS-Lookup, Verbindungsaufbau und dem vollständigen Laden der Ressourcen. In den CoreDash-Daten macht navigate etwa 65 % der Sitzungen aus. Es ist Ihre Baseline. Jeder andere Navigationstyp sollte danach beurteilt werden, wie er im Vergleich zu navigate abschneidet.

reload

Der Nutzer hat F5 gedrückt, auf den Reload-Button des Browsers geklickt oder Ihr Code hat location.reload() aufgerufen. Der Browser sendet Revalidierungsanfragen für im Cache gespeicherte Ressourcen. Das bedeutet, dass der TTFB oft schlechter aussieht als bei einem navigate, obwohl sich der Nutzer auf derselben Seite befindet. Wenn Ihr reload-TTFB drastisch höher ist als der navigate-TTFB, lösen Ihre Cache-Header bei jedem Reload eine Revalidierung aus, anstatt veraltete Inhalte auszuliefern. Etwa 10 % der Sitzungen im typischen CoreDash-Traffic sind Reloads.

back_forward

Der Nutzer hat den Zurück- oder Vorwärts-Button des Browsers gedrückt. Wenn der Back/Forward Cache (bfcache) funktioniert, ist dies der schnellstmögliche Navigationstyp. Der Browser stellt die Seite direkt aus dem Speicher wieder her, ganz ohne Netzwerkanfragen. Der LCP für einen bfcache-Treffer entspricht praktisch der Zeit für das Rendern aus dem Arbeitsspeicher, was nahezu verzögerungsfrei geschieht.

Wenn Ihre back_forward-Metriken ähnlich aussehen wie bei navigate, funktioniert der bfcache nicht. Die häufigsten Ursachen sind unload-Event-Handler, Cache-Control: no-store-Response-Header und offene IndexedDB-Verbindungen, die vor der Navigation nicht geschlossen wurden. Laut CoreDash-Daten machen Back/Forward-Navigationen etwa 20 % der Sitzungen aus, was dies zu einer Korrektur mit großer Hebelwirkung macht.

prerender

Die Seite wurde mithilfe der Speculation Rules API im Hintergrund geladen, bevor der Nutzer auf den Link geklickt hat. Wenn der Nutzer dann klickt, wird das vorgerenderte Dokument sofort aktiviert. Der LCP für einen korrekt aktivierten Prerender liegt nahe null, da die gesamte Rendering-Arbeit vor dem Navigationsereignis abgeschlossen wurde.

Wenn Ihr prerender-LCP normal aussieht, ist eines von drei Dingen passiert: Der Prerender wurde vor der Aktivierung verworfen, die Speculation Rule zielte auf die falschen URLs ab oder die Seite verwendet Header oder JavaScript, die ein Prerendering verhindern. Ungefähr 3 % der CoreDash-Sitzungen sind Prerender-Aktivierungen, aber dieser Anteil steigt schnell an, sobald Speculation Rules implementiert sind.

restore

Der Tab wurde wiederhergestellt, nachdem der Browser geschlossen wurde oder der Tab abgestürzt ist. Der Browser lädt die Seite von Grund auf neu, aber die Sitzung wird als Wiederherstellung (Restore) und nicht als neue Navigation betrachtet. Die Performance ähnelt einer kalten Navigation. Dies macht etwa 2 % der Sitzungen aus und steht selten im Fokus von Optimierungsarbeiten, ist aber eine Überwachung wert, wenn Sie Nutzer mit instabilen Browser-Sitzungen haben.

Debugging-Workflow

1. Vergleichen Sie den navigate-LCP mit Ihrem allgemeinen LCP-Ziel. Dies ist Ihre Ground Truth für die Performance bei neu geladenen Seiten. Wenn navigate die Vorgaben bereits erfüllt, liegt Ihr Problem woanders.
2. Vergleichen Sie back_forward mit navigate. Wenn die Werte nahe beieinander liegen, ist der bfcache fehlerhaft. Öffnen Sie die Chrome DevTools, navigieren Sie zum Application-Panel und führen Sie den bfcache-Test aus. Die Ausgabe der DevTools listet exakt auf, welche Features oder Header die bfcache-Berechtigung blockieren.
3. Überprüfen Sie den prerender-LCP. Wenn er über 200ms liegt, liefert die Prerender-Pipeline nicht die gewünschten Ergebnisse. Stellen Sie sicher, dass das JSON Ihrer Speculation Rules gültig ist, überprüfen Sie, ob die Zielseiten keine blockierende Logik zurückgeben, und bestätigen Sie, dass Aktivierungen in den Chrome DevTools unter Speculation Rules gezählt werden.

Faustregeln für Entwickler

• navigate: Sollte Ihren LCP-Schwellenwert durch normale Optimierungen erreichen: schneller TTFB, fetchpriority="high" beim LCP-Bild, keine Rendering-blockierenden Ressourcen.
• back_forward: Sollte 10- bis 20-mal schneller sein als navigate. Wenn nicht, ist der bfcache fehlerhaft.
• prerender: Sollte einen LCP unter 200ms aufweisen. Wenn nicht, sind Ihre Speculation Rules falsch konfiguriert.
• reload: Der TTFB sollte nicht drastisch schlechter sein als bei navigate. Wenn doch, korrigieren Sie Ihre Cache-Revalidierungs-Header.

Der Navigationstyp ist die Dimension, die "Wie performt meine Seite?" von "Wie performt meine Seite unter der jeweiligen Browser-Ladestrategie?" trennt. Diese Unterscheidung macht den Unterschied zwischen Raten und Debuggen aus.