Dimensión Core/Dash: Visitante Recurrente

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

La dimensión Visitante Recurrente (Repeat Visitor) divide tus datos de rendimiento en dos poblaciones: usuarios que han visitado tu sitio anteriormente 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 es importante porque tu puntuación agregada de LCP es un promedio ponderado de ambos. Si el 40% de tus sesiones son nuevos visitantes, sus tiempos de carga sin caché 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 enteras de solicitudes para los visitantes recurrentes. En un sitio de contenido típico, un visitante recurrente omite la búsqueda DNS, el saludo TCP (handshake), la negociación TLS y la respuesta del servidor para cada recurso almacenado en caché. A menudo, el recurso del LCP se sirve desde la caché de memoria en menos de 5ms en lugar de tardar de 200ms a 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 a través de los sitios monitorizados, los visitantes recurrentes suelen mostrar puntuaciones de LCP entre un 35% y un 60% más bajas que los nuevos visitantes en las mismas páginas. La brecha es más amplia en páginas con muchas imágenes donde la imagen principal (hero image) es grande y el servidor de origen está geográficamente distante del usuario. En las páginas con renderizado del lado del servidor (SSR) y un elemento LCP de texto, la brecha se reduce porque el retraso de carga del texto es casi nulo para ambos grupos.

Las diferencias de INP entre los dos grupos son menores pero siguen presentes. Los nuevos visitantes a menudo desencadenan más análisis (parsing) de JavaScript en la primera carga a medida que los bundles 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 analizar y compilar por completo. En páginas pesadas en JavaScript, esto puede reducir el tiempo de procesamiento entre 50ms y 150ms.

Interpretando 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 web 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 con caché caliente (warm-cache): 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 en su lugar los recursos que bloquean el renderizado, el tiempo de respuesta del servidor o el retraso del renderizado (render delay).

1: Nuevo Visitante

Sin caché. El navegador obtiene cada recurso desde la red. Este es tu peor caso con caché fría (cold-cache), y representa la primera impresión para cada usuario que te encuentra a través de búsquedas orgánicas, un anuncio pagado o una publicación en redes sociales. 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 tus nuevos visitantes falla el umbral de 2.5s pero el LCP de tus visitantes recurrentes lo aprueba, tu objetivo de optimización es claro: reduce el tamaño y el retraso del propio recurso LCP, 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 ocurre típicamente cuando el navegador bloquea el acceso de almacenamiento requerido para distinguir a los visitantes nuevos de los recurrentes, o cuando una configuración del navegador centrada en la privacidad impide la verificación. En la mayoría de los sitios, este grupo representa menos del 5% de las sesiones. Trátalo como un nivel de ruido (noise floor) 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 sin caché es tu experiencia de usuario (UX) dominante y debe ser tu objetivo principal de optimización.
2. Compara el LCP por tipo de visita: Filtra solo a los nuevos visitantes 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 los nuevos visitantes con un LCP lento, la solución es reducir el tiempo de carga del recurso. Comprime la imagen del LCP, sírvela desde un nodo de borde de 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: Cruza los datos con la dimensión Tipo de navegación. Las recargas y las navegaciones de retroceso-avance (back-forward) 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 el nuevo visitante: Menos de 2.5s en el p75. Esto es más difícil de alcanzar que el LCP del visitante recurrente y requiere verdadero trabajo de infraestructura: CDN, optimización de imágenes y una prioridad de obtención (fetch priority) correcta.
• Brecha aceptable entre el LCP del visitante nuevo y el recurrente: 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 verdadera historia. Dividir por tipo de visita muestra de inmediato si el trabajo de optimización es sólido o si el sitio está sobreviviendo gracias a los aciertos de caché (cache hits) de una audiencia recurrente leal, mientras falla a cada nuevo usuario que llega desde una búsqueda.