Core/Dash Dimension: 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 antes e usuários que não. A diferença de engenharia entre esses grupos é o cache do navegador. Um visitante recorrente carrega suas fontes, scripts e imagens a partir do disco. Um novo visitante busca cada byte da 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 sem cache estão puxando seu p75 para cima. Sem essa dimensão, você não consegue dizer se uma regressão de LCP é um problema real de infraestrutura ou um pico temporário na aquisição de novos usuários.

Por Que a Lacuna de Desempenho é Maior do Que Você Espera

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

Nos dados do CoreDash em sites monitorados, visitantes recorrentes normalmente apresentam pontuações de LCP 35% a 60% mais baixas do que os novos visitantes nas mesmas páginas. A lacuna é maior em páginas carregadas de imagens onde a imagem hero é grande e o servidor de origem está geograficamente distante do usuário. Em páginas com renderização do lado do servidor e um elemento LCP de texto, a lacuna 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 análises de JavaScript no primeiro carregamento, à medida que os pacotes de módulos são avaliados pela primeira vez. Visitantes recorrentes se beneficiam do cache de código do V8, que armazena bytecode compilado e pula inteiramente a etapa de análise e compilação. Em páginas com muito JavaScript, isso pode reduzir de 50ms a 150ms o tempo de processamento.

Lendo os Três Valores

0: Visitante Recorrente

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

1: Novo Visitante

Sem cache. O navegador busca todos os recursos da rede. Este é o seu pior cenário sem cache, e representa a primeira impressão para cada usuário que encontra você por meio de pesquisa orgânica, um anúncio pago ou um compartilhamento social. Novos visitantes normalmente representam de 30% a 45% das sessões. Suas pontuações de LCP chegam a ser de 300ms a 700ms mais altas do que as de visitantes recorrentes em páginas baseadas em imagens. Se o LCP dos seus novos visitantes não atingir o limite de 2.5s, mas o LCP dos visitantes recorrentes passar, seu alvo de otimização é claro: reduza o tamanho e o atraso do próprio recurso LCP, porque você não pode contar com o cache para este público.

2: Não Medido

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

Fluxo de Trabalho de Depuração

1. Estabeleça sua divisão de linha de base: Abra a dimensão Visitante Recorrente no CoreDash e anote a porcentagem de sessões novas em comparação com as recorrentes. Se os novos visitantes representarem mais de 50% do tráfego, o desempenho sem cache é a sua user experience dominante e deve ser o principal alvo de otimização.
2. Compare o LCP por tipo de visita: Filtre apenas para novos visitantes e registre o LCP no p75. Depois, filtre para visitantes recorrentes e registre a mesma métrica. Uma lacuna acima de 500ms aponta o tamanho do recurso ou o tempo de busca na rede como o gargalo. Uma lacuna abaixo de 200ms sugere problemas do lado da renderização que afetam ambos os grupos de forma igual.
3. Direcione o recurso de LCP diretamente: Para novos visitantes com LCP lento, a correçã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 confie no cache para compensar um recurso de LCP superdimensionado ou servido lentamente.
4. Valide com a dimensão Navigation Type: Faça referência cruzada com a dimensão Navigation Type. Navegações de recarregamento e de voltar/avançar são inclinadas a ser de visitantes recorrentes. Se o LCP de seus visitantes recorrentes parecer inesperadamente lento, uma alta proporção de navegações de recarregamento (onde recursos em cache são revalidados em vez de serem servidos diretamente) pode ser o motivo.

Regra Prática de Engenharia

• Alvo de LCP para novo visitante: Abaixo de 2.5s no p75. Isso é mais difícil de atingir do que o LCP de visitante recorrente e exige trabalho real de infraestrutura: CDN, otimização de imagem e prioridade de busca correta.
• Lacuna aceitável entre LCP de visitante novo e recorrente: Até 400ms. Uma lacuna maior indica que seu site depende do cache do navegador para passar nos Core Web Vitals, o que significa que as primeiras impressões estão falhando.
• Não Medido abaixo de 5%: Se esse grupo crescer acima de 10%, investigue se uma implementação de consentimento de cookies ou alteração de permissão de armazenamento está bloqueando a detecção do tipo de visita.

A dimensão Visitante Recorrente é um dos primeiros filtros que aplico quando um site apresenta uma aprovação limítrofe no 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 baseando em acertos de cache de um público fiel que retorna, enquanto falha para cada novo usuário que chega pela pesquisa.