Dimensión de Core/Dash: Navigation Type

Dimensión: Navigation Type (nt)

Cada vista de página en tus datos de CrUX incluye un tipo de navegación. Te indica cómo cargó el navegador la página, lo que determina qué sistemas del navegador intervinieron: la pila de red, el back/forward cache, el pipeline de prerender o una restauración de sesión. CoreDash expone esto como la dimensión nt para que puedas filtrar y comparar tus Core Web Vitals en cada contexto de navegación por separado.

Los datos provienen de la API PerformanceNavigationTiming, específicamente de la propiedad type. Puedes leerla con performance.getEntriesByType("navigation")[0].type. Chrome reporta este valor junto con cada medición de Core Web Vitals enviada a CrUX, y CoreDash lo almacena e indexa para que puedas segmentar sin tener que escribir instrumentación personalizada.

Por qué importa el tipo de navegación

Agregar el LCP o el INP de todos los tipos de navegación produce un número que es técnicamente correcto pero prácticamente engañoso. Un acierto en el back/forward cache se completa en milisegundos. Una navegación en frío espera a DNS, TCP, TLS y TTFB. Si el 20% de tus sesiones son aciertos en el bfcache, bajan tu LCP p75 y hacen que un problema real en las navegaciones nuevas sea más difícil de ver.

Lo contrario también es cierto. Si el bfcache está roto en tu sitio, las sesiones back/forward tendrán un rendimiento tan malo como las navegaciones nuevas. Sin segmentar por tipo de navegación, nunca te darás cuenta, porque el agregado se mantiene estable.

El prerender es el caso más dramático. Una página prerenderizada correctamente debería mostrar un LCP cercano a cero, porque el renderizado terminó antes de que el usuario hiciera clic en el enlace. Si tus páginas prerenderizadas muestran números de LCP normales, la configuración de Speculation Rules es incorrecta y el prerender no se está activando o se está descartando antes de usarse.

Los tipos de navegación

navigate

Una navegación estándar: el usuario escribió una URL, hizo clic en un enlace de otro sitio o siguió una redirección. Esta es una carga de página completa sin atajos de caché. El navegador pasa por todo el pipeline de solicitudes, incluyendo la resolución 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 tu línea de base. Cualquier otro tipo de navegación debe evaluarse según cómo se compare con navigate.

reload

El usuario presionó F5, hizo clic en el botón de recarga del navegador o tu 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 el de navigate, a pesar de que el usuario está en la misma página. Si el TTFB de tu reload es drásticamente mayor que el TTFB de navigate, tus cabeceras de caché están activando la revalidación en cada recarga en lugar de servir contenido obsoleto. Aproximadamente el 10% de las sesiones son recargas en el tráfico típico de CoreDash.

back_forward

El usuario presionó el botón de retroceso o avance del navegador. Si el back/forward cache (bfcache) está funcionando, este es el tipo de navegación más rápido posible. El navegador restaura la página desde la memoria sin realizar ninguna solicitud de red. El LCP para un acierto de bfcache es efectivamente el tiempo para pintar desde la memoria, lo cual es casi instantáneo.

Si tus métricas de back_forward se ven similares a las de navigate, el bfcache no está funcionando. Las causas más comunes son los controladores de eventos unload, las cabeceras de respuesta Cache-Control: no-store y las conexiones abiertas a IndexedDB que no se cerraron antes de la navegación. Los datos de CoreDash sitúan las navegaciones back/forward en torno al 20% de las sesiones, lo que hace de esto una optimización de gran impacto.

prerender

La página se cargó en segundo plano mediante la API Speculation Rules antes de que el usuario hiciera clic en el enlace. Cuando el usuario hace clic, el documento prerenderizado se activa de forma instantánea. El LCP para un prerender activado correctamente es cercano a cero porque todo el trabajo de renderizado finalizó antes del evento de navegación.

Si el LCP de tu prerender parece normal, ocurrió una de estas tres cosas: el prerender se descartó antes de la activación, la regla de especulación apuntaba a las URL incorrectas, o la página utiliza cabeceras 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 cerrar el navegador o de que la pestaña fallara. El navegador vuelve a cargar la página desde cero, pero la sesión se considera una restauración (restore) 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 tienes usuarios con sesiones de navegador inestables.

Flujo de depuración

1. Compara el LCP de navigate con tu objetivo de LCP global. Esta es tu referencia real para el rendimiento de cargas nuevas. Si navigate ya cumple el objetivo, tu problema está en otra parte.
2. Compara back_forward con navigate. Si están cerca, el bfcache está roto. Abre Chrome DevTools, ve al panel Application y ejecuta la prueba de bfcache. La salida de DevTools mostrará exactamente qué características o cabeceras están bloqueando la elegibilidad de bfcache.
3. Verifica el LCP de prerender. Si supera los 200 ms, el pipeline de prerender no está funcionando. Verifica que el JSON de tus Speculation Rules sea válido, comprueba que las páginas de destino no devuelvan lógica de bloqueo y confirma que las activaciones se estén registrando en Chrome DevTools en la sección Speculation Rules.

Regla práctica de ingeniería

• navigate: Debe cumplir con tu umbral de LCP mediante optimizaciones normales: un TTFB rápido, fetchpriority="high" en la imagen del LCP y sin recursos render-blocking.
• back_forward: Debe ser de 10 a 20 veces más rápido que navigate. Si no, el bfcache está roto.
• prerender: Debe mostrar un LCP inferior a 200 ms. Si no, tus Speculation Rules están mal configuradas.
• reload: El TTFB no debe ser drásticamente peor que el de navigate. Si lo es, corrige tus cabeceras de revalidación de caché.

Navigation Type es la dimensión que separa "¿cómo rinde mi página?" de "¿cómo rinde mi página bajo cada estrategia de carga del navegador?". Esa distinción es la diferencia entre adivinar y depurar.