Core/Dash-dimensie: Navigatietype

Dimensie: Navigatietype (nt)

Elke paginaweergave in je CrUX-data bevat een navigatietype. Het vertelt je hoe de browser de pagina heeft geladen, wat bepaalt welke browsersystemen erbij betrokken waren: de netwerkstack, de back/forward cache, de prerender-pipeline of een sessieherstel. CoreDash stelt dit beschikbaar als de nt-dimensie, zodat je Core Web Vitals voor elke navigatiecontext afzonderlijk kunt filteren en vergelijken.

De data is afkomstig van de PerformanceNavigationTiming API, specifiek de type-eigenschap. Je leest dit uit met performance.getEntriesByType("navigation")[0].type. Chrome rapporteert deze waarde samen met elke web vitals-meting die naar CrUX wordt gestuurd, en CoreDash slaat deze op en indexeert deze zodat je kunt segmenteren zonder zelf aangepaste instrumentatie te hoeven schrijven.

Waarom Navigatietype belangrijk is

Het aggregeren van LCP of INP over alle navigatietypes heen levert een getal op dat technisch correct maar in de praktijk misleidend is. Een hit in de back/forward cache is in milliseconden voltooid. Een koude navigatie wacht op DNS, TCP, TLS en TTFB. Als 20% van je sessies bfcache-hits zijn, trekken ze je p75 LCP omlaag en maken ze een echt probleem bij nieuwe navigaties moeilijker zichtbaar.

Het omgekeerde is ook waar. Als bfcache op je site kapot is, zullen back/forward-sessies net zo slecht presteren als nieuwe navigaties. Zonder te segmenteren op navigatietype zul je dit nooit opmerken, omdat het geaggregeerde gemiddelde stabiel blijft.

Prerender is het meest dramatische geval. Een correct geprerenderde pagina zou een LCP van bijna nul moeten tonen, omdat de rendering al voltooid was voordat de gebruiker überhaupt op de link klikte. Als je geprerenderde pagina's normale LCP-cijfers laten zien, is de configuratie van de Speculation Rules verkeerd en wordt de prerender ofwel niet geactiveerd, ofwel genegeerd voordat deze kan worden gebruikt.

De Navigatietypes

navigate

Een standaardnavigatie: de gebruiker heeft een URL getypt, op een link van een andere site geklikt of een redirect gevolgd. Dit is een volledige paginalading zonder caching-snelkoppelingen. De browser doorloopt de volledige request-pipeline, inclusief DNS-lookup, het opzetten van de verbinding en het volledig laden van resources. In CoreDash-data is navigate goed voor ongeveer 65% van de sessies. Het is je basislijn. Elk ander navigatietype moet worden beoordeeld op basis van hoe het zich verhoudt tot navigate.

reload

De gebruiker drukte op F5, klikte op de vernieuwen-knop van de browser of je code riep location.reload() aan. De browser stuurt revalidatieverzoeken voor gecachete resources, wat betekent dat TTFB er vaak slechter uitziet dan bij een navigate, ondanks dat de gebruiker zich op dezelfde pagina bevindt. Als je reload TTFB dramatisch hoger is dan de navigate TTFB, activeren je cache-headers revalidatie bij elke reload in plaats van verouderde content te serveren. Ongeveer 10% van de sessies in typisch CoreDash-verkeer zijn reloads.

back_forward

De gebruiker drukte op de vorige- of volgende-knop van de browser. Als de back/forward cache (bfcache) werkt, is dit het snelst mogelijke navigatietype. De browser herstelt de pagina vanuit het geheugen zonder dat er netwerkverzoeken plaatsvinden. De LCP voor een bfcache-hit is in feite de tijd om vanuit het geheugen te renderen, wat vrijwel direct is.

Als je back_forward-statistieken vergelijkbaar zijn met navigate, werkt bfcache niet. De meest voorkomende oorzaken zijn unload event handlers, Cache-Control: no-store response headers en open IndexedDB-verbindingen die niet werden gesloten vóór de navigatie. CoreDash-data laat zien dat back/forward goed is voor ongeveer 20% van de sessies, wat dit een fix met een grote impact maakt.

prerender

De pagina werd op de achtergrond geladen met behulp van de Speculation Rules API voordat de gebruiker op de link klikte. Wanneer de gebruiker daadwerkelijk klikt, wordt het geprerenderde document onmiddellijk geactiveerd. De LCP voor een correct geactiveerde prerender is bijna nul, omdat al het renderwerk was voltooid voorafgaand aan het navigatie-evenement.

Als je prerender LCP er normaal uitziet, is er een van drie dingen gebeurd: de prerender is weggegooid voor activatie, de speculation rule was gericht op de verkeerde URL's, of de pagina gebruikt headers of JavaScript die prerendering verhinderen. Ongeveer 3% van de CoreDash-sessies zijn prerender-activaties, maar dat aandeel stijgt snel zodra Speculation Rules worden ingezet.

restore

Het tabblad is hersteld nadat de browser werd gesloten of het tabblad crashte. De browser laadt de pagina helemaal opnieuw, maar de sessie wordt beschouwd als een restore in plaats van een nieuwe navigatie. De prestaties zijn vergelijkbaar met een koude navigatie. Dit is goed voor ongeveer 2% van de sessies en vormt zelden de focus van optimalisatiewerk, maar is wel het monitoren waard als je gebruikers hebt met onstabiele browsersessies.

Debugging Workflow

1. Vergelijk de navigate LCP met je algemene LCP-doel. Dit is je basiswaarheid voor prestaties bij een nieuwe lading. Als navigate al slaagt, ligt je probleem elders.
2. Vergelijk back_forward met navigate. Als ze dicht bij elkaar liggen, is bfcache kapot. Open Chrome DevTools, ga naar het Application-paneel en voer de bfcache-test uit. De output in DevTools zal precies aangeven welke features of headers de geschiktheid voor bfcache blokkeren.
3. Controleer de prerender LCP. Als deze boven de 200 ms ligt, levert de prerender-pipeline niet de verwachte prestaties. Controleer of je Speculation Rules JSON geldig is, verifieer of de doelpagina's geen blokkerende logica retourneren en bevestig dat activaties worden geteld in Chrome DevTools onder Speculation Rules.

Vuistregel voor engineering

• navigate: Zou je LCP-drempelwaarde moeten halen door middel van normale optimalisatie: snelle TTFB, fetchpriority="high" op de LCP-afbeelding, geen render-blocking resources.
• back_forward: Zou 10 tot 20 keer sneller moeten zijn dan navigate. Zo niet, dan is bfcache kapot.
• prerender: Zou een LCP onder de 200 ms moeten tonen. Zo niet, dan zijn je Speculation Rules verkeerd geconfigureerd.
• reload: TTFB zou niet dramatisch slechter moeten zijn dan bij navigate. Als dat wel zo is, repareer dan je headers voor cache-revalidatie.

Navigatietype is de dimensie die "hoe presteert mijn pagina?" onderscheidt van "hoe presteert mijn pagina onder elke laadstrategie van de browser?". Dat onderscheid is het verschil tussen gissen en debuggen.