Dimensión: Navigation Type (nt)
Cada vista de página en sus datos de CrUX incluye un tipo de navegación. Este le indica cómo cargó el navegador la página, lo que determina qué sistemas del navegador intervinieron: el stack de red, la caché de retroceso\/adelanto (back\/forward cache), el pipeline de prerenderizado o una restauración de sesión. CoreDash expone esto como la dimensión nt para que pueda filtrar y comparar los Core Web Vitals en cada contexto de navegación por separado.
Los datos provienen de la API PerformanceNavigationTiming, específicamente de la propiedad type. Se lee con performance.getEntriesByType("navigation")[0].type. Chrome informa este valor junto con cada medición de web vitals enviada a CrUX, y CoreDash lo almacena e indexa para que pueda segmentar sin escribir ninguna instrumentación personalizada.
Por qué es importante el Navigation Type
Agregar LCP o INP en todos los tipos de navegación produce un número que es técnicamente correcto pero prácticamente engañoso. Un acierto en la caché de retroceso\/adelanto se completa en milisegundos. Una navegación "en frío" espera a DNS, TCP, TLS y TTFB. Si el 20 % de sus sesiones son aciertos de bfcache, estos reducirán su p75 de LCP y harán que sea más difícil ver un problema real en las navegaciones nuevas.
Lo contrario también es cierto. Si la bfcache no funciona en su sitio, las sesiones de retroceso\/adelanto tendrán un rendimiento tan malo como las navegaciones nuevas. Sin segmentar por tipo de navegación, nunca lo notará, porque el agregado se mantiene estable.
El caso de Prerender es el más dramático. Una página correctamente prerenderizada debería mostrar un LCP cercano a cero, porque el renderizado finalizó incluso antes de que el usuario hiciera clic en el enlace. Si sus páginas prerenderizadas muestran números de LCP normales, la configuración de las Speculation Rules es incorrecta y el prerenderizado no se está activando o se está descartando antes de su uso.
Los tipos de navegación (Navigation Types)
navigate
Una navegación estándar: el usuario escribió una URL, hizo clic en un enlace desde otro sitio o siguió un redireccionamiento. Se trata de una carga de página completa sin atajos de caché. El navegador pasa por todo el pipeline de solicitud, incluyendo la búsqueda de DNS, el establecimiento de la conexión y la carga completa de recursos. En los datos de CoreDash, navigate representa aproximadamente el 65 % de las sesiones. Es su punto de referencia. Cualquier otro tipo de navegación debe juzgarse en comparación con navigate.
reload
El usuario pulsó F5, hizo clic en el botón de recarga del navegador o su código llamó a location.reload(). El navegador envía solicitudes de revalidación para los recursos almacenados en caché, lo que significa que el TTFB a menudo parece peor que en una navegación normal, a pesar de que el usuario está en la misma página. Si su TTFB de reload es drásticamente más alto que el TTFB de navigate, sus encabezados de caché están activando la revalidación en cada recarga en lugar de servir contenido almacenado. Aproximadamente el 10 % de las sesiones son recargas en el tráfico típico de CoreDash.
back_forward
El usuario pulsó el botón de retroceso o avance del navegador. Si la caché de retroceso\/adelanto (bfcache) funciona, este es el tipo de navegación más rápido posible. El navegador restaura la página desde la memoria sin ninguna solicitud de red. El LCP para un acierto de bfcache es, efectivamente, el tiempo de pintado desde la memoria, que es casi instantáneo.
Si sus métricas de back_forward se parecen a las de navigate, la bfcache no está funcionando. Las causas más comunes son los controladores de eventos unload, los encabezados de respuesta Cache-Control: no-store y las conexiones de IndexedDB abiertas que no se cerraron antes de la navegación. Los datos de CoreDash sitúan las navegaciones de retroceso\/adelanto en torno al 20 % de las sesiones, lo que hace que esta sea una solución de gran impacto.
prerender
La página se cargó en segundo plano utilizando la API Speculation Rules antes de que el usuario hiciera clic en el enlace. Cuando el usuario hace clic, el documento prerenderizado se activa instantáneamente. El LCP para un prerenderizado activado correctamente es cercano a cero porque todo el trabajo de renderizado finalizó antes del evento de navegación.
Si su LCP de prerender parece normal, ha ocurrido una de estas tres cosas: el prerenderizado se descartó antes de la activación, la regla de especulación apuntó a las URL incorrectas o la página utiliza encabezados o JavaScript que impiden el prerenderizado. Aproximadamente el 3 % de las sesiones de CoreDash son activaciones de prerender, pero esa proporción aumenta rápidamente una vez que se implementan las Speculation Rules.
restore
La pestaña se restauró después de que se cerrara el navegador o la pestaña fallara. El navegador recarga la página desde cero, pero la sesión se considera una restauración en lugar de una navegación nueva. El rendimiento es similar al de una navegación en frío. Esto representa aproximadamente el 2 % de las sesiones y rara vez es el foco del trabajo de optimización, pero vale la pena monitorearlo si tiene usuarios con sesiones de navegador inestables.
Flujo de trabajo de depuración
- Compare el LCP de navigate con su objetivo de LCP global. Esta es su verdad fundamental para el rendimiento de carga inicial. Si navigate ya está pasando, su problema está en otra parte.
- Verifique back_forward frente a navigate. Si están cerca, la bfcache está rota. Abra Chrome DevTools, vaya al panel Application y ejecute la prueba de bfcache. La salida de DevTools enumerará exactamente qué características o encabezados están bloqueando la elegibilidad para la bfcache.
- Verifique el LCP de prerender. Si es superior a 200 ms, el pipeline de prerenderizado no está funcionando. Verifique que el JSON de sus Speculation Rules sea válido, compruebe que las páginas de destino no devuelvan lógica de bloqueo y confirme que las activaciones se estén contando en Chrome DevTools bajo Speculation Rules.
Reglas prácticas de ingeniería
- navigate: Debe cumplir con su umbral de LCP mediante una optimización normal: TTFB rápido, fetchpriority="high" en la imagen de LCP, sin recursos que bloqueen el renderizado.
- back_forward: Debería ser entre 10 y 20 veces más rápido que navigate. Si no es así, la bfcache está rota.
- prerender: Debería mostrar un LCP inferior a 200 ms. Si no es así, sus Speculation Rules están mal configuradas.
- reload: El TTFB no debería ser drásticamente peor que el de navigate. Si lo es, corrija sus encabezados de revalidación de caché.
El Navigation Type es la dimensión que separa "¿cómo está rindiendo mi página?" de "¿cómo está rindiendo mi página bajo cada estrategia de carga del navegador?". Esa distinción es la diferencia entre adivinar y depurar.