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. Dit bepaalt welke browsersystemen actief waren: de netwerkstack, de back/forward-cache, de prerender-pipeline of een sessieherstel. CoreDash toont dit als de nt-dimensie. Zo kun je Core Web Vitals voor elke navigatiecontext afzonderlijk filteren en vergelijken.

De data is afkomstig van de PerformanceNavigationTiming API, specifiek de eigenschap type. Je leest deze uit met performance.getEntriesByType("navigation")[0].type. Chrome rapporteert deze waarde bij elke Web Vitals-meting die naar CrUX wordt verzonden. CoreDash slaat dit op en indexeert het, zodat je kunt segmenteren zonder handmatige instrumentatie.

Waarom Navigatietype belangrijk is

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

Het omgekeerde is ook waar. Als de bfcache op je site niet werkt, presteren back/forward-sessies net zo slecht als nieuwe navigaties. Zonder te segmenteren op navigatietype merk je hier niets van, omdat het totaal stabiel blijft.

Prerender is het meest extreme geval. Een correct geprerenderde pagina moet een LCP van bijna nul laten zien, omdat het renderen al klaar was voordat de gebruiker überhaupt op de link klikte. Als je geprerenderde pagina's normale LCP-cijfers laten zien, klopt de configuratie van je Speculation Rules niet. De prerender start dan niet of wordt voor gebruik al weggegooid.

De navigatietypes

navigate

Een standaard navigatie: de gebruiker typte een URL, klikte op een link vanaf een andere site of volgde een redirect. Dit is een volledige paginalading zonder cache-shortcuts. De browser doorloopt de volledige verzoek-pipeline, inclusief DNS-lookup, het opzetten van de verbinding en het volledig laden van bronnen. In de data van CoreDash is navigate goed voor ongeveer 65% van de sessies. Dit is je nulmeting. Elk ander navigatietype moet worden beoordeeld op basis van de vergelijking met navigate.

reload

De gebruiker drukte op F5, klikte op de reload-knop van de browser of je code riep location.reload(). De browser stuurt revalidatieverzoeken voor gecachte bronnen. Hierdoor is de TTFB vaak slechter dan bij een standaard navigatie, hoewel de gebruiker op dezelfde pagina is. Als de TTFB van je reload dramatisch hoger is dan die van navigate, dwingen je cache-headers bij elke reload een revalidatie af in plaats van verouderde content te serveren. In typisch CoreDash-verkeer is ongeveer 10% van de sessies een reload.

back_forward

De gebruiker drukte op de terug- of vooruitknop 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 enige netwerkverzoeken. De LCP voor een bfcache-hit is in feite de tijd om vanuit het geheugen te renderen. Dit is vrijwel direct.

Als je back_forward-metingen lijken op die van navigate, werkt de bfcache niet. De meest voorkomende oorzaken zijn unload-eventhandlers, Cache-Control: no-store-responseheaders en openstaande IndexedDB-verbindingen die niet voor de navigatie zijn gesloten. Volgens CoreDash-data is back/forward goed voor ongeveer 20% van de sessies. Dit maakt het een optimalisatie met veel impact.

prerender

De pagina is op de achtergrond geladen via de Speculation Rules API voordat de gebruiker op de link klikte. Zodra de gebruiker klikt, wordt het geprerenderde document direct geactiveerd. De LCP voor een correct geactiveerde prerender is bijna nul, omdat al het renderwerk al klaar was voor de navigatie plaatsvond.

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

restore

Het tabblad is hersteld nadat de browser werd gesloten of de tab crashte. De browser laadt de pagina vanaf nul opnieuw, maar de sessie geldt als een restore in plaats van een nieuwe navigate. De prestaties zijn vergelijkbaar met een koude navigatie. Dit beslaat ongeveer 2% van de sessies. Het is zelden het focuspunt van optimalisaties, maar het is de moeite waard om te monitoren als je gebruikers hebt met onstabiele browsersessies.

Debugging-workflow

1. Vergelijk de LCP van navigate met je algemene LCP-doelstelling. Dit is je uitgangspunt voor nieuwe laadprestaties. Als navigate al voldoet, ligt het probleem elders.
2. Vergelijk back_forward met navigate. Als ze dicht bij elkaar liggen, werkt de bfcache niet. Open Chrome DevTools, ga naar het Application-paneel en voer de bfcache-test uit. De DevTools-output toont exact welke features of headers de bfcache blokkeren.
3. Controleer de LCP van prerender. Als deze boven de 200 ms ligt, schiet de prerender-pipeline tekort. Controleer of de JSON van je Speculation Rules valide is, check of de doelpagina's geen blokkerende logica bevatten en controleer of activaties in Chrome DevTools worden geteld onder Speculation Rules.

Vuistregels voor engineers

• navigate: Moet de LCP-drempelwaarde halen via normale optimalisatie: snelle TTFB, fetchpriority="high" op de LCP-afbeelding, geen render-blocking bronnen.
• back_forward: Moet 10 tot 20 keer sneller zijn dan navigate. Zo niet, dan werkt de bfcache niet.
• prerender: Moet een LCP onder de 200 ms tonen. Zo niet, dan zijn je Speculation Rules verkeerd geconfigureerd.
• reload: TTFB mag niet dramatisch slechter zijn dan navigate. Als dat wel zo is, herstel dan je cache-revalidatieheaders.

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