Dimensão Core/Dash: Visitante Recorrente

Dimensão: Comportamento do Usuário: Visitante Recorrente (fv)

A dimensão Visitante Recorrente divide seus dados de desempenho em duas populações: usuários que já visitaram seu site e usuários que não. A diferença técnica entre esses grupos é o cache do navegador. Um visitante recorrente carrega suas fontes, scripts e imagens do disco. Um novo visitante busca cada byte na rede.

Isso é importante porque sua pontuação agregada de LCP é uma média ponderada de ambos. Se 40% das suas sessões são de novos visitantes, os tempos de carregamento deles com cache frio estão elevando o seu p75. Sem esta dimensão, você não consegue dizer se uma regressão no LCP é um problema real de infraestrutura ou um pico temporário na aquisição de novos usuários.

Por Que a Diferença de Desempenho é Maior do Que Você Espera

O cache do navegador elimina cadeias de requisições inteiras para visitantes recorrentes. Em um site de conteúdo típico, um visitante recorrente pula a busca DNS, o handshake TCP, a negociação TLS e a resposta do servidor para cada recurso em cache. O próprio recurso de LCP geralmente é servido a partir do cache de memória em menos de 5ms, em vez de levar de 200ms a 800ms pela rede. Essa não é uma melhoria marginal: é uma diferença estrutural na forma como a página carrega.

Nos dados do CoreDash em sites monitorados, os visitantes recorrentes geralmente apresentam pontuações de LCP 35% a 60% menores do que os novos visitantes nas mesmas páginas. A diferença é mais ampla em páginas com muitas imagens, onde a hero image é grande e o servidor de origem está geograficamente distante do usuário. Em páginas com renderização do lado do servidor (server-side rendering) e um elemento LCP de texto, a diferença diminui porque o atraso no carregamento de texto é quase zero para ambos os grupos.

As diferenças de INP entre os dois grupos são menores, mas ainda estão presentes. Novos visitantes frequentemente acionam mais parsing de JavaScript no primeiro carregamento, à medida que os bundles de módulos são avaliados pela primeira vez. Os visitantes recorrentes se beneficiam do cache de código do V8, que armazena bytecode compilado e pula inteiramente a etapa de parsing e compilação. Em páginas pesadas em JavaScript, isso pode reduzir o tempo de processamento de 50ms a 150ms.

Lendo os Três Valores

0: Visitante Recorrente

O navegador informou que esta não é a primeira sessão do usuário em sua origem. Recursos em cache estão disponíveis. Na maioria dos sites de marketing e editoriais rastreados no CoreDash, os visitantes recorrentes representam 55% a 70% de todas as sessões. Os dados de desempenho deles são a sua linha de base com cache quente (warm-cache baseline): o melhor cenário possível para usuários reais que conhecem o seu site. Se o seu LCP for ruim aqui, o problema não é o cache. Observe, em vez disso, recursos que bloqueiam a renderização (render-blocking), tempo de resposta do servidor ou atraso de renderização.

1: Novo Visitante

Sem cache. O navegador busca todos os recursos na rede. Este é o pior cenário possível com cache frio (cold-cache) e representa a primeira impressão para cada usuário que encontra você por meio de busca orgânica, anúncio pago ou compartilhamento social. Novos visitantes costumam representar de 30% a 45% das sessões. Suas pontuações de LCP chegam a ser de 300ms a 700ms maiores do que as dos visitantes recorrentes em páginas baseadas em imagens. Se o LCP de seus novos visitantes falhar no limite de 2.5s, mas o LCP de visitantes recorrentes passar, o seu alvo de otimização é claro: reduza o tamanho e o atraso do próprio recurso de LCP, pois você não pode depender de cache para este público.

2: Não Medido

O CoreDash não conseguiu determinar o tipo de visita para esta sessão. Isso geralmente ocorre quando o navegador bloqueia o acesso ao armazenamento necessário para distinguir visitantes novos de recorrentes, ou quando uma configuração de navegador focada em privacidade impede a verificação. Na maioria dos sites, esse grupo (bucket) representa menos de 5% das sessões. Trate isso como um ruído de fundo (noise floor) em vez de um segmento para o qual otimizar.

Fluxo de Trabalho de Depuração

1. Estabeleça a divisão da sua linha de base: Abra a dimensão Visitante Recorrente no CoreDash e observe a porcentagem de sessões novas em relação às recorrentes. Se os novos visitantes estiverem acima de 50% do tráfego, o desempenho com cache frio é a sua user experience dominante e deve ser o alvo principal de otimização.
2. Compare o LCP por tipo de visita: Filtre apenas para novos visitantes e registre o LCP no p75. Em seguida, filtre para visitantes recorrentes e registre a mesma métrica. Uma diferença acima de 500ms aponta o tamanho dos recursos ou o tempo de busca na rede como o gargalo. Uma diferença abaixo de 200ms sugere problemas do lado da renderização (render-side) que afetam ambos os grupos igualmente.
3. Mire diretamente no recurso de LCP: Para novos visitantes com um LCP lento, a solução é reduzir o tempo de carregamento do recurso. Comprima a imagem do LCP, sirva-a a partir de um edge node de CDN próximo aos seus usuários e aplique fetchpriority="high". Esses ganhos persistem independentemente do estado do cache. Não dependa de cache para compensar um recurso de LCP superdimensionado ou servido lentamente.
4. Valide com a dimensão Navigation Type: Faça um cruzamento de dados com a dimensão Navigation Type. As navegações de recarregamento (reload) e de voltar/avançar (back-forward) são inclinadas a visitantes recorrentes. Se o seu LCP de visitantes recorrentes parecer inesperadamente lento, uma alta proporção de navegações de recarregamento (onde recursos em cache são revalidados em vez de servidos diretamente) pode ser o motivo.

Regra Prática de Engenharia

• Alvo de LCP para novos visitantes: Menor que 2.5s no p75. Este alvo é mais difícil de atingir do que o LCP de visitantes recorrentes e exige trabalho real de infraestrutura: CDN, otimização de imagens e a prioridade de busca (fetch priority) correta.
• Diferença aceitável entre o LCP de visitantes novos e recorrentes: Até 400ms. Uma diferença maior indica que o seu site depende do cache do navegador para passar no Core Web Vitals, o que significa que as primeiras impressões estão falhando.
• Não Medido abaixo de 5%: Se esse grupo crescer para mais de 10%, investigue se uma implementação de consentimento de cookies ou mudança na permissão de armazenamento está bloqueando a detecção do tipo de visita.

A dimensão Visitante Recorrente é um dos primeiros filtros que eu aplico quando um site apresenta uma aprovação no limite (borderline pass) para o LCP. Dados de campo agregados escondem a verdadeira história. Dividir por tipo de visita mostra imediatamente se o trabalho de otimização é sólido ou se o site está se sustentando em acertos de cache (cache hits) de um público fiel recorrente, enquanto falha para cada novo usuário que chega a partir de uma busca.