Dimensión de Core/Dash: Visitante recurrente

Dimensión: Comportamiento del usuario: Visitante recurrente (fv)

La dimensión Visitante recurrente divide tus datos de rendimiento en dos poblaciones: usuarios que han visitado tu sitio antes y usuarios que no. La diferencia técnica entre estos grupos es la caché del navegador. Un visitante recurrente carga tus fuentes, scripts e imágenes desde el disco. Un visitante nuevo obtiene cada byte desde la red.

Esto importa porque tu puntuación agregada de LCP es un promedio ponderado de ambos. Si el 40% de tus sesiones son visitantes nuevos, sus tiempos de carga con caché fría están elevando tu p75. Sin esta dimensión, no puedes saber si una regresión de LCP es un problema real de infraestructura o un pico temporal en la adquisición de nuevos usuarios.

Por qué la brecha de rendimiento es mayor de lo que esperas

La caché del navegador elimina cadenas de solicitudes completas para los visitantes recurrentes. En un sitio de contenido típico, un visitante recurrente omite la búsqueda DNS, el saludo TCP, la negociación TLS y la respuesta del servidor para cada activo en caché. El recurso LCP en sí a menudo se sirve desde la caché de memoria en menos de 5ms en lugar de tardar entre 200ms y 800ms a través de la red. Esa no es una mejora marginal: es una diferencia estructural en cómo carga la página.

En los datos de CoreDash de los sitios monitorizados, los visitantes recurrentes suelen mostrar puntuaciones LCP un 35% a 60% más bajas que los visitantes nuevos en las mismas páginas. La brecha es más amplia en páginas con muchas imágenes donde la imagen hero es grande y el servidor de origen está geográficamente distante del usuario. En páginas con renderizado del lado del servidor y un elemento LCP de texto, la brecha se estrecha porque el retraso de carga del texto es casi cero para ambos grupos.

Las diferencias de INP entre los dos grupos son menores pero siguen presentes. Los visitantes nuevos a menudo desencadenan más análisis de JavaScript en la primera carga, ya que los paquetes de módulos se evalúan por primera vez. Los visitantes recurrentes se benefician de la caché de código de V8, que almacena el bytecode compilado y omite el paso de análisis y compilación por completo. En páginas con mucho JavaScript, esto puede reducir el tiempo de procesamiento entre 50ms y 150ms.

Leyendo los tres valores

0: Visitante recurrente

El navegador informó que esta no es la primera sesión del usuario en tu origen. Los recursos en caché están disponibles. En la mayoría de los sitios editoriales y de marketing rastreados en CoreDash, los visitantes recurrentes representan del 55% al 70% de todas las sesiones. Sus datos de rendimiento son tu línea base de caché caliente: el mejor de los casos para usuarios reales que conocen tu sitio. Si tu LCP es deficiente aquí, el problema no es la caché. Revisa los recursos que bloquean el renderizado, el tiempo de respuesta del servidor o el retraso de renderizado en su lugar.

1: Visitante nuevo

Sin caché. El navegador obtiene cada recurso desde la red. Este es tu peor caso de caché fría, y representa la primera impresión para cada usuario que te encuentra a través de una búsqueda orgánica, un anuncio pagado o una publicación social. Los nuevos visitantes típicamente representan del 30% al 45% de las sesiones. Sus puntuaciones de LCP son entre 300ms y 700ms más altas que las de los visitantes recurrentes en páginas basadas en imágenes. Si el LCP de tu visitante nuevo no supera el umbral de 2.5s pero el LCP de tu visitante recurrente sí, tu objetivo de optimización es claro: reduce el tamaño y el retraso del recurso LCP en sí, porque no puedes depender de la caché para esta audiencia.

2: No medido

CoreDash no pudo determinar el tipo de visita para esta sesión. Esto suele ocurrir cuando el navegador bloquea el acceso al almacenamiento requerido para distinguir a los visitantes nuevos de los recurrentes, o cuando una configuración del navegador centrada en la privacidad impide la comprobación. En la mayoría de los sitios, este grupo representa menos del 5% de las sesiones. Trátalo como un ruido de fondo en lugar de un segmento para el cual optimizar.

Flujo de trabajo de depuración

1. Establece tu división base: Abre la dimensión Visitante recurrente en CoreDash y anota el porcentaje de sesiones nuevas frente a las recurrentes. Si los visitantes nuevos superan el 50% del tráfico, el rendimiento de la caché fría es tu user experience dominante y debe ser el principal objetivo de optimización.
2. Compara el LCP por tipo de visita: Filtra solo a los visitantes nuevos y registra el p75 del LCP. Luego, filtra a los visitantes recurrentes y registra la misma métrica. Una brecha superior a 500ms apunta al tamaño del activo o al tiempo de obtención de la red como el cuello de botella. Una brecha inferior a 200ms sugiere problemas del lado del renderizado que afectan a ambos grupos por igual.
3. Apunta directamente al recurso LCP: Para visitantes nuevos con un LCP lento, la solución es reducir el tiempo de carga del recurso. Comprime la imagen LCP, sírvela desde un nodo perimetral de la CDN cercano a tus usuarios y aplica fetchpriority="high". Estas ganancias persisten independientemente del estado de la caché. No dependas de la caché para compensar un activo LCP sobredimensionado o servido lentamente.
4. Valida con la dimensión Navigation Type: Compara los datos con la dimensión Navigation Type. Las navegaciones de recarga y de retroceso-avance se inclinan hacia los visitantes recurrentes. Si el LCP de tu visitante recurrente parece inesperadamente lento, una alta proporción de navegaciones de recarga (donde los recursos en caché se revalidan en lugar de servirse directamente) podría ser la razón.

Regla general de ingeniería

• Objetivo de LCP para visitantes nuevos: Por debajo de 2.5s en el p75. Esto es más difícil de alcanzar que el LCP de visitantes recurrentes y requiere trabajo de infraestructura real: CDN, optimización de imágenes y una fetch priority correcta.
• Brecha aceptable entre el LCP de visitantes nuevos y recurrentes: Hasta 400ms. Una brecha mayor indica que tu sitio depende de la caché del navegador para aprobar los Core Web Vitals, lo que significa que las primeras impresiones están fallando.
• No medido por debajo del 5%: Si este grupo crece por encima del 10%, investiga si una implementación de consentimiento de cookies o un cambio en los permisos de almacenamiento está bloqueando la detección del tipo de visita.

La dimensión Visitante recurrente es uno de los primeros filtros que aplico cuando un sitio muestra un aprobado al límite en el LCP. Los datos de campo agregados ocultan la historia real. Dividir por tipo de visita muestra de inmediato si el trabajo de optimización es sólido o si el sitio está sobreviviendo a base de aciertos de caché de una audiencia recurrente leal mientras le falla a cada nuevo usuario que llega desde una búsqueda.