Dimensione Core/Dash: Navigation Type

Dimensione: Navigation Type (nt)

Ogni visualizzazione di pagina nei tuoi dati CrUX contiene un tipo di navigazione. Ti dice come il browser ha caricato la pagina. Questo determina quali sistemi del browser sono stati coinvolti: lo stack di rete, la back/forward cache, la pipeline di prerender o il ripristino di sessione. CoreDash espone questo valore come dimensione nt, così puoi filtrare e confrontare i Core Web Vitals per ciascun contesto di navigazione separatamente.

I dati provengono dall'API PerformanceNavigationTiming, nello specifico dalla proprietà type. La leggi con performance.getEntriesByType("navigation")[0].type. Chrome riporta questo valore insieme a ogni misurazione dei Core Web Vitals inviata a CrUX. CoreDash lo memorizza e lo indicizza, consentendoti di segmentare i dati senza scrivere alcuna strumentazione personalizzata.

Perché il Navigation Type è importante

Aggregare il LCP o l'INP su tutti i tipi di navigazione produce un valore tecnicamente corretto, ma fuorviante all'atto pratico. Un hit della back/forward cache si completa in pochi millisecondi. Una navigazione a freddo deve attendere DNS, TCP, TLS e TTFB. Se il 20% delle tue sessioni sono hit della bfcache, queste abbassano il p75 del tuo LCP, rendendo più difficile individuare un problema reale sulle nuove navigazioni.

Vale anche il contrario. Se la bfcache sul tuo sito è rotta, le sessioni back/forward avranno prestazioni pessime tanto quanto le nuove navigazioni. Senza segmentare per tipo di navigazione non te ne accorgerai mai, perché il dato aggregato rimane stabile.

Il prerender è il caso più eclatante. Una pagina pre-renderizzata correttamente dovrebbe mostrare un LCP vicino allo zero, perché il rendering è terminato prima ancora che l'utente cliccasse sul link. Se le tue pagine pre-renderizzate mostrano valori di LCP normali, la configurazione delle Speculation Rules è errata: il prerender non si attiva o viene scartato prima dell'uso.

I tipi di navigazione

navigate

Una navigazione standard: l'utente ha inserito un URL, ha cliccato su un link da un altro sito o ha seguito un redirect. Si tratta di un caricamento completo della pagina senza scorciatoie di cache. Il browser esegue l'intera pipeline di richiesta, inclusi risoluzione DNS, stabilimento della connessione e caricamento completo delle risorse. Nei dati di CoreDash, navigate rappresenta circa il 65% delle sessioni. È il tuo valore di riferimento. Qualsiasi altro tipo di navigazione va valutato in base al confronto con navigate.

reload

L'utente ha premuto F5, ha cliccato sul pulsante di ricarica del browser o il tuo codice ha chiamato location.reload(). Il browser invia richieste di convalida per le risorse in cache. Di conseguenza, il TTFB spesso appare peggiore rispetto a un navigate, anche se l'utente si trova sulla stessa pagina. Se il TTFB di reload è nettamente superiore a quello di navigate, i tuoi header di cache stanno forzando la convalida a ogni ricarica invece di servire contenuti obsoleti. Nel traffico tipico di CoreDash, i reload rappresentano circa il 10% delle sessioni.

back_forward

L'utente ha premuto il pulsante indietro o avanti del browser. Se la back/forward cache (bfcache) funziona, questo è il tipo di navigazione più veloce in assoluto. Il browser ripristina la pagina direttamente dalla memoria, senza alcuna richiesta di rete. L'LCP per un hit della bfcache è di fatto il tempo necessario per il paint dalla memoria, il che lo rende quasi istantaneo.

Se le metriche di back_forward sono simili a quelle di navigate, significa che la bfcache non funziona. Le cause più comuni sono i gestori di eventi unload, gli header di risposta Cache-Control: no-store e le connessioni IndexedDB rimaste aperte prima della navigazione. I dati di CoreDash indicano che le navigazioni back/forward coprono circa il 20% delle sessioni, il che rende questo intervento ad alto impatto.

prerender

La pagina è stata caricata in background tramite l'API Speculation Rules prima che l'utente cliccasse sul link. Quando l'utente fa clic, il documento pre-renderizzato viene attivato all'istante. L'LCP di un prerender attivato correttamente è vicino allo zero, perché tutto il lavoro di rendering si è concluso prima dell'evento di navigazione.

Se l'LCP del tuo prerender sembra normale, è successa una di queste tre cose: il prerender è stato scartato prima dell'attivazione, la speculation rule ha come target gli URL errati, oppure la pagina utilizza header o JavaScript che impediscono il prerendering. Le attivazioni di prerender rappresentano circa il 3% delle sessioni di CoreDash, ma questa quota sale rapidamente una volta distribuite le Speculation Rules.

restore

La scheda è stata ripristinata in seguito alla chiusura del browser o a un crash. Il browser ricarica la pagina da zero, ma la sessione viene considerata un restore anziché una nuova navigazione. Le prestazioni sono simili a quelle di una navigazione a freddo. Questo tipo rappresenta circa il 2% delle sessioni ed è raramente l'obiettivo principale del lavoro di ottimizzazione, ma vale la pena monitorarlo se i tuoi utenti hanno sessioni del browser instabili.

Workflow di debug

1. Confronta l'LCP di navigate con il tuo obiettivo di LCP complessivo. Questa è la tua fonte di verità per le prestazioni del caricamento iniziale. Se navigate rispetta già la soglia, il problema è altrove.
2. Confronta back_forward con navigate. Se i valori sono vicini, la bfcache è rotta. Apri i DevTools di Chrome, vai al pannello Application ed esegui il test bfcache. L'output dei DevTools mostrerà esattamente quali funzionalità o header bloccano l'idoneità alla bfcache.
3. Controlla l'LCP di prerender. Se è superiore a 200 ms, la pipeline di prerender non sta portando risultati. Verifica che il JSON delle tue Speculation Rules sia valido, assicurati che le pagine di destinazione non restituiscano logiche bloccanti e controlla che le attivazioni siano registrate nei DevTools di Chrome sotto la voce Speculation Rules.

Regole pratiche

• navigate: dovrebbe soddisfare la soglia LCP attraverso le normali ottimizzazioni: TTFB veloce, fetchpriority="high" sull'immagine LCP, nessuna risorsa render blocking.
• back_forward: dovrebbe essere da 10 a 20 volte più veloce di navigate. In caso contrario, la bfcache non funziona.
• prerender: dovrebbe registrare un LCP inferiore a 200ms. In caso contrario, le tue Speculation Rules sono configurate male.
• reload: il TTFB non dovrebbe essere drasticamente peggiore di navigate. Se lo è, correggi gli header di convalida della cache.

Il Navigation Type è la dimensione che separa la domanda "come si comporta la mia pagina?" da "come si comporta la mia pagina per ciascuna strategia di caricamento del browser?". Questa distinzione fa la differenza tra tirare a indovinare e fare debug.