Dimensión de CoreDash: Origen de navegación

Qué mide el Origen de navegación

La dimensión Origen de navegación divide sus 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 los subrecursos y beneficiarse de cualquier precarga (prefetching) que su sitio haya configurado. Una navegación de origen cruzado comienza desde cero.

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

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

1. Búsqueda de DNS — resuelve su dominio a una dirección IP.
2. Enlace TCP (TCP handshake) — abre una conexión con su servidor.
3. Negociación TLS — completa el enlace HTTPS.

En conjunto, 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 su página. Ese costo se refleja directamente en el Time to First Byte (TTFB), y si su elemento LCP depende de un recurso cargado después de que llega el HTML, también se refleja en cascada en un peor Largest Contentful Paint (LCP).

Los subrecursos almacenados en caché tampoco están disponibles. Un visitante que hizo clic desde Google no tiene una copia en caché de sus fuentes, imagen principal (hero image) o CSS crítico. Un visitante que acaba de llegar desde su página de inicio probablemente tenga todos ellos.

Navegaciones del mismo origen y la caché de avance/retroceso (bfcache)

Las navegaciones del mismo origen abren la puerta a dos ventajas de rendimiento que las navegaciones de origen cruzado no pueden utilizar de manera tan confiable.

Primero, la API de Speculation Rules le permite pre-obtener (prefetch) o pre-renderizar 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, lo que hace que la navegación sea instantánea. Esto solo se aplica a los destinos del mismo origen.

Segundo, la caché de avance/retroceso (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 todos los Core Web Vitals. Aparecen en sus datos como navegaciones del mismo origen. Si su LCP de mismo origen es significativamente mejor que su LCP de origen cruzado, es probable que la bfcache y el prefetch estén contribuyendo a esa diferencia.

Cómo leer esta dimensión en CoreDash

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

• Sus 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 sus páginas de origen cruzado no.
• Sus subrecursos almacenados en caché ayudan a los visitantes recurrentes pero no a los que llegan por primera vez desde fuentes externas.

Los datos de origen cruzado son típicamente 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 su LCP de origen cruzado se aprueba mientras que su LCP del mismo origen falla, eso es inusual y vale la pena investigarlo. Lo contrario es mucho más común.

Reducción de la penalización de origen cruzado

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

• Use una CDN con un TTFB rápido. La sobrecarga de conexión se reduce cuando su servidor está geográficamente cerca del usuario y responde rápidamente. Apunte a un TTFB inferior a 200 ms para el documento HTML.
• Precargue la imagen LCP. Un <link rel="preload"> en el <head> inicia la obtención de la imagen lo antes posible, acortando el tiempo entre la entrega del HTML y el renderizado (paint) del elemento LCP.
• Integre el CSS crítico en línea (inline). La ausencia de una solicitud de hoja de estilos que bloquee el renderizado significa que el navegador puede pintar antes incluso en una conexión fría.
• Añada pistas preconnect para orígenes de terceros. Si su imagen LCP o un recurso que bloquea el renderizado están alojados en un dominio diferente, una sugerencia 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. Pre-renderizar la página siguiente más probable reduce el LCP a casi cero para esas transiciones.

El Origen de navegación en contexto

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