Core/Dash-Dimension: Navigationstyp

Dimension: Navigationstyp (nt)

Jeder Seitenaufruf in deinen CrUX-Daten enthält einen Navigationstyp. Er verrät dir, wie der Browser die Seite geladen hat. Das bestimmt, welche Browser-Systeme beteiligt waren: der Netzwerk-Stack, der Back/Forward-Cache, die Prerender-Pipeline oder eine Sitzungswiederherstellung. CoreDash stellt dies als Dimension nt bereit, damit du die Core Web Vitals für jeden Navigationskontext separat filtern und vergleichen kannst.

Die Daten stammen aus der PerformanceNavigationTiming-API, genauer gesagt aus der Eigenschaft type. Du liest 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 du ohne eigene Instrumentierung segmentieren kannst.

Warum der Navigationstyp wichtig ist

LCP oder INP über alle Navigationstypen hinweg zu aggregieren, liefert einen Wert, der zwar technisch korrekt, in der Praxis aber irreführend ist. Ein Treffer im Back/Forward-Cache ist in Millisekunden abgeschlossen. Eine kalte Navigation wartet auf DNS, TCP, TLS und TTFB. Wenn 20 % deiner Sitzungen bfcache-Treffer sind, ziehen sie deinen p75-LCP-Wert nach unten. Ein echtes Problem bei neuen Navigationen wird dadurch schwerer erkennbar.

Das Gleiche gilt auch umgekehrt. Wenn der bfcache auf deiner Website defekt ist, schneiden back/forward-Sitzungen genauso schlecht ab wie frische Navigationen. Ohne Segmentierung nach Navigationstyp wirst du das nie bemerken, da der Gesamtwert stabil bleibt.

Prerender ist der extremste Fall. Eine korrekt per Prerender geladene Seite sollte einen LCP-Wert nahe Null aufweisen, da das Rendering bereits abgeschlossen war, bevor der Nutzer überhaupt auf den Link geklickt hat. Wenn deine per Prerender geladenen Seiten normale LCP-Werte zeigen, ist die Speculation-Rules-Konfiguration fehlerhaft. Der Prerender wird dann entweder nicht ausgelöst oder vor der Nutzung 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ändiger Seitenaufruf ohne Caching-Abkürzungen. Der Browser durchläuft die gesamte Request-Pipeline einschließlich DNS-Lookup, Verbindungsaufbau und dem vollständigen Laden der Ressourcen. In den Daten von CoreDash macht navigate etwa 65 % der Sitzungen aus. Das ist deine Baseline. Jeder andere Navigationstyp sollte daran gemessen werden, wie er im Vergleich zu navigate abschneidet.

reload

Der Nutzer hat F5 gedrückt, auf den Aktualisieren-Button des Browsers geklickt oder dein Code hat location.reload() aufgerufen. Der Browser sendet Revalidierungsanfragen für gecachte Ressourcen, wodurch der TTFB oft schlechter aussieht als bei navigate – obwohl der Nutzer sich auf derselben Seite befindet. Wenn dein reload-TTFB dramatisch höher ist als der navigate-TTFB, lösen deine Cache-Header bei jedem Neuladen eine Revalidierung aus, anstatt veraltete Inhalte aus dem Cache zu bedienen. In typischem CoreDash-Traffic machen Reloads etwa 10 % der Sitzungen aus.

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, komplett ohne Netzwerkanfragen. Der LCP bei einem bfcache-Treffer ist praktisch die Zeit, die für das Zeichnen aus dem Speicher benötigt wird – also nahezu sofort.

Wenn deine back_forward-Metriken denen von navigate ähneln, 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. In den CoreDash-Daten liegt back_forward bei etwa 20 % der Sitzungen. Das macht diese Optimierung zu einem extrem wirkungsvollen Hebel.

prerender

Die Seite wurde mittels der Speculation Rules API im Hintergrund geladen, bevor der Nutzer auf den Link geklickt hat. Klickt der Nutzer dann tatsächlich, wird das vorgerenderte Dokument sofort aktiviert. Der LCP für einen korrekt aktivierten Prerender liegt nahe Null, weil die gesamte Rendering-Arbeit bereits vor dem Navigationsereignis abgeschlossen war.

Wenn dein 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 das Prerendering verhindern. Etwa 3 % der CoreDash-Sitzungen sind Prerender-Aktivierungen. Dieser Anteil steigt jedoch schnell an, sobald Speculation Rules implementiert sind.

restore

Der Tab wurde wiederhergestellt, nachdem der Browser geschlossen wurde oder der Tab abgestürzt war. Der Browser lädt die Seite komplett neu, aber die Sitzung wird als restore statt als frische Navigation gewertet. Die Performance ähnelt der einer kalten Navigation. Dies macht etwa 2 % der Sitzungen aus und steht selten im Fokus der Optimierung. Es lohnt sich jedoch zu überwachen, wenn deine Nutzer instabile Browsersitzungen haben.

Debugging Workflow

1. Vergleiche den navigate-LCP mit deinem LCP-Gesamtziel. Das ist deine Ground Truth für die Performance bei einem frischen Seitenaufruf. Wenn navigate bereits die Anforderungen erfüllt, liegt dein Problem woanders.
2. Prüfe back_forward im Vergleich zu navigate. Wenn die Werte nah beieinanderliegen, ist der bfcache defekt. Öffne die Chrome DevTools, wechsle zum Panel „Application“ und führe den bfcache-Test aus. Die DevTools-Ausgabe listet genau auf, welche Funktionen oder Header die bfcache-Kompatibilität blockieren.
3. Prüfe den prerender-LCP. Wenn er über 200 ms liegt, liefert die Prerender-Pipeline nicht ab. Überprüfe, ob dein Speculation-Rules-JSON valide ist, stelle sicher, dass die Zielseiten keine blockierende Logik zurückgeben, und kontrolliere in den Chrome DevTools unter Speculation Rules, ob Aktivierungen gezählt werden.

Engineering Rule of Thumb

• navigate: Sollte deinen LCP-Grenzwert durch normale Optimierung erreichen: schneller TTFB, fetchpriority="high" auf dem LCP-Bild, keine renderblockierenden Ressourcen.
• back_forward: Sollte 10- bis 20-mal schneller als navigate sein. Wenn nicht, ist der bfcache defekt.
• prerender: Sollte einen LCP unter 200 ms aufweisen. Wenn nicht, sind deine Speculation Rules falsch konfiguriert.
• reload: Der TTFB sollte nicht dramatisch schlechter sein als bei navigate. Falls doch, korrigiere deine Header für die Cache-Revalidierung.

Der Navigationstyp ist die Dimension, die „Wie performt meine Seite?“ von „Wie performt meine Seite unter der jeweiligen Lade-Strategie des Browsers?“ trennt. Genau dieser Unterschied entscheidet zwischen Raten und Debuggen.