Dimensione Core/Dash: Navigation Type

Segmenta i tuoi Core Web Vitals in base al modo in cui gli utenti sono arrivati alla pagina per eseguire il debug delle prestazioni di bfcache, prerender e reload.

Dimensione: Navigation Type (nt)

Ogni visualizzazione di pagina nei tuoi dati CrUX porta con sé un tipo di navigazione. Ti dice come il browser ha caricato la pagina, il che determina quali sistemi del browser sono stati coinvolti: lo stack di rete, la back\/forward cache, la pipeline di prerender o un ripristino di sessione. CoreDash espone questo come dimensione nt in modo da poter filtrare e confrontare i Core Web Vitals in ogni contesto di navigazione separatamente.

I dati provengono dall'API PerformanceNavigationTiming, specificamente dalla proprietà type. Viene letta con performance.getEntriesByType("navigation")[0].type. Chrome riporta questo valore insieme a ogni misurazione dei web vitals inviata a CrUX, e CoreDash lo memorizza e lo indicizza in modo da poter segmentare senza scrivere alcuna strumentazione personalizzata.

Perché il Navigation Type è importante

Aggregare LCP o INP tra tutti i tipi di navigazione produce un numero tecnicamente corretto ma praticamente fuorviante. Un hit della back\/forward cache si completa in millisecondi. Una navigazione "a freddo" attende DNS, TCP, TLS e TTFB. Se il 20% delle tue sessioni sono hit della bfcache, questi abbassano il tuo p75 LCP e rendono più difficile vedere un problema reale sulle nuove navigazioni.

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

Il prerender è il caso più eclatante. Una pagina correttamente prerenderizzata dovrebbe mostrare un LCP vicino allo zero, perché il rendering è terminato prima ancora che l'utente cliccasse sul link. Se le tue pagine prerenderizzate mostrano numeri LCP normali, la configurazione delle Speculation Rules è errata e il prerender non si sta attivando o viene scartato prima dell'uso.

I tipi di navigazione (Navigation Types)

navigate

Una navigazione standard: l'utente ha digitato 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 caching. Il browser attraversa l'intera pipeline di richiesta, inclusi la ricerca DNS, lo stabilimento della connessione e il caricamento completo delle risorse. Nei dati di CoreDash, navigate rappresenta circa il 65% delle sessioni. È la tua base di riferimento. Ogni altro tipo di navigazione dovrebbe essere giudicato 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 rivalidazione per le risorse in cache, il che significa che il TTFB spesso appare peggiore di una navigazione nonostante l'utente sia sulla stessa pagina. Se il tuo TTFB di reload è drasticamente superiore al TTFB di navigate, i tuoi header di cache stanno innescando la rivalidazione ad ogni ricaricamento invece di servire contenuti obsoleti. Circa il 10% delle sessioni sono ricaricamenti nel traffico tipico di CoreDash.

back_forward

L'utente ha premuto il pulsante avanti o indietro del browser. Se la back\/forward cache (bfcache) sta funzionando, questo è il tipo di navigazione più veloce possibile. Il browser ripristina la pagina dalla memoria senza alcuna richiesta di rete. L'LCP per un hit della bfcache è effettivamente il tempo di dipingere dalla memoria, che è quasi istantaneo.

Se le tue metriche di back_forward sembrano simili a navigate, la bfcache non sta funzionando. Le cause più comuni sono i gestori di eventi unload, gli header di risposta Cache-Control: no-store e le connessioni IndexedDB aperte che non sono state chiuse prima della navigazione. I dati di CoreDash collocano le sessioni back\/forward intorno al 20%, rendendo questa una correzione ad alto rendimento.

prerender

La pagina è stata caricata in background utilizzando l'API Speculation Rules prima che l'utente cliccasse sul link. Quando l'utente clicca, il documento prerenderizzato viene attivato istantaneamente. L'LCP per un prerender attivato correttamente è vicino allo zero perché tutto il lavoro di rendering è terminato prima dell'evento di navigazione.

Se il tuo LCP di prerender appare normale, è successa una di queste tre cose: il prerender è stato scartato prima dell'attivazione, la regola di speculazione puntava agli URL errati o la pagina utilizza header o JavaScript che impediscono il prerendering. Circa il 3% delle sessioni di CoreDash sono attivazioni di prerender, ma tale quota aumenta rapidamente una volta implementate le Speculation Rules.

restore

La scheda è stata ripristinata dopo la chiusura del browser o il crash della scheda stessa. Il browser ricarica la pagina da zero, ma la sessione è considerata un ripristino piuttosto che una nuova navigazione. Le prestazioni sono simili a una navigazione a freddo. Questo rappresenta circa il 2% delle sessioni e raramente è il fulcro del lavoro di ottimizzazione, ma vale la pena monitorarlo se hai utenti con sessioni del browser instabili.

Workflow di debug

1. Confronta l'LCP di navigate con il tuo obiettivo LCP complessivo. Questa è la tua verità fondamentale per le prestazioni di caricamento a fresco. Se navigate sta già passando, il tuo problema è altrove.
2. Controlla back_forward rispetto a navigate. Se sono vicini, la bfcache è rotta. Apri i Chrome DevTools, vai al pannello Application ed esegui il test della bfcache. L'output di DevTools elencherà esattamente quali funzionalità o header stanno bloccando l'idoneità alla bfcache.
3. Controlla l'LCP di prerender. Se è superiore a 200ms, la pipeline di prerender non sta funzionando. Verifica che il JSON delle tue Speculation Rules sia valido, controlla che le pagine di destinazione non restituiscano logica di blocco e conferma che le attivazioni vengano conteggiate nei Chrome DevTools sotto Speculation Rules.

   Regola empirica per l'ingegneria

   • navigate: Dovrebbe soddisfare la tua soglia LCP attraverso la normale ottimizzazione: TTFB veloce, fetchpriority="high" sull'immagine LCP, nessuna risorsa che blocca il rendering.
   • back_forward: Dovrebbe essere da 10 a 20 volte più veloce di navigate. In caso contrario, la bfcache è rotta.
   • prerender: Dovrebbe mostrare un LCP inferiore a 200ms. In caso contrario, le tue Speculation Rules sono configurate in modo errato.
   • reload: Il TTFB non dovrebbe essere drasticamente peggiore di navigate. Se lo è, correggi i tuoi header di rivalidazione della cache.

     Il Navigation Type è la dimensione che separa "come sta performando la mia pagina?" da "come sta performando la mia pagina sotto ogni strategia di caricamento del browser?". Tale distinzione è la differenza tra tirare a indovinare ed eseguire il debug.

     [include]sidebarcoredash.html[\/include]