Dimensión Core/Dash: Origen de la navegación

Qué mide el Origen de la navegación

La dimensión Origen de la navegación divide tus datos de campo en dos grupos:

• Mismo origen (1) — la página anterior estaba en el mismo dominio.
• Origen cruzado (2) — el usuario llegó desde un dominio diferente, un motor de búsqueda, una plataforma social o escribió la URL directamente.

Esta distinción es importante porque las condiciones iniciales del navegador son completamente diferentes en cada caso. Una navegación del mismo origen puede reutilizar una conexión existente, aprovechar la caché HTTP para subrecursos y beneficiarse de cualquier precarga que tu sitio haya configurado. Una navegación de origen cruzado empieza desde cero.

Por qué las navegaciones de origen cruzado son más lentas

Cuando un usuario hace clic en un enlace desde un sitio externo, el navegador tiene trabajo que hacer antes de poder siquiera solicitar tu HTML:

1. Búsqueda DNS — resuelve tu dominio a una dirección IP.
2. Handshake TCP — abre una conexión con tu servidor.
3. Negociación TLS — completa el handshake HTTPS.

Juntos, estos pasos suelen añadir entre 200 y 500 ms en una conexión móvil antes de que se haya solicitado el primer byte de tu página. Ese costo se refleja directamente en el Time to First Byte (TTFB), y si tu elemento LCP depende de un recurso cargado después de que llega el HTML, también repercute en un peor Largest Contentful Paint (LCP).

Los subrecursos en caché tampoco están disponibles. Un visitante que hizo clic desde Google no tiene una copia en caché de tus fuentes, imagen principal o CSS crítico. Es probable que un visitante que acaba de llegar desde tu página de inicio tenga todo eso.

Navegaciones del mismo origen y la back-forward cache

Las navegaciones del mismo origen abren la puerta a dos ventajas de rendimiento que las navegaciones de origen cruzado no pueden utilizar con tanta fiabilidad.

Primero, la API de Speculation Rules te permite precargar o prerrenderizar páginas internas antes de que el usuario haga clic. El navegador puede tener la siguiente página completamente renderizada en una pestaña en segundo plano, haciendo que la navegación sea instantánea. Esto solo se aplica a destinos del mismo origen.

Segundo, la back-forward cache (bfcache) restaura una página desde la memoria cuando el usuario presiona el botón de retroceso. Los aciertos de la bfcache son extremadamente rápidos y obtienen buenas puntuaciones en todas las métricas de Core Web Vitals. Aparecen en tus datos como navegaciones del mismo origen. Si tu LCP del mismo origen es significativamente mejor que tu LCP de origen cruzado, es probable que la bfcache y el prefetch estén contribuyendo a esa diferencia.

Cómo interpretar esta dimensión en CoreDash

En CoreDash, usa el Origen de la navegación como filtro o como dimensión de desglose junto con cualquier métrica. La comparación más útil es el LCP por origen de la navegación. Una gran brecha entre el LCP del mismo origen y el de origen cruzado te indica una de tres cosas:

• Tus páginas de entrada de origen cruzado tienen un TTFB lento que infla el LCP.
• Las navegaciones del mismo origen se benefician del prefetch o la bfcache y tus páginas de origen cruzado no.
• Tus subrecursos en caché ayudan a los visitantes recurrentes, pero no a los que llegan por primera vez desde fuentes externas.

Los datos de origen cruzado suelen ser el número más importante para el SEO. El Chrome UX Report (CrUX) de Google incluye todos los tipos de navegación, pero el tráfico de búsqueda orgánica es casi en su totalidad de origen cruzado. Si tu LCP de origen cruzado se aprueba mientras que tu LCP del mismo origen falla, eso es inusual y vale la pena investigarlo. Lo contrario es mucho más común.

Reduciendo la penalización de origen cruzado

No puedes eliminar la penalización del inicio en frío por completo, pero puedes reducirla:

• Usa una CDN con un TTFB rápido. La sobrecarga de la conexión se reduce cuando tu servidor está geográficamente cerca del usuario y responde rápidamente. Apunta a un TTFB inferior a 200 ms para el documento HTML.
• Precarga la imagen del LCP. Un <link rel="preload"> en el <head> inicia la obtención de la imagen lo antes posible, reduciendo el tiempo entre la entrega del HTML y el pintado del elemento LCP.
• Incorpora el CSS crítico (inline). Al no haber solicitudes de hojas de estilo que bloqueen el renderizado, el navegador puede pintar antes, incluso en una conexión fría.
• Añade directivas preconnect para orígenes de terceros. Si tu imagen del LCP o un recurso que bloquea el renderizado está alojado en un dominio diferente, una indicación rel="preconnect" inicia el trabajo de TCP y TLS anticipadamente.

Para las navegaciones del mismo origen, la API de Speculation Rules es la mejora de mayor impacto disponible en la actualidad. Prerrenderizar la página siguiente más probable reduce el LCP a casi cero para esas transiciones.

El Origen de la navegación en contexto

El Origen de la navegación funciona bien junto con la dimensión Tipo de navegación (que separa navegación, recarga, retroceso-avance y prerrenderizado) y la dimensión Tipo de conexión efectiva. Una navegación de origen cruzado en una conexión lenta es el escenario más difícil al que se enfrenta tu sitio. Filtrar por esas dos condiciones juntas te mostrará tu verdadero rendimiento en el peor de los casos y dónde están disponibles las mayores mejoras.