Core Web Vitals
O Zenovay coleta os Core Web Vitals do Google (LCP, CLS, INP) além de duas métricas complementares (FCP, TTFB) de cada sessão de visitante real. Os dados aparecem na aba Performance do painel de cada domínio.
Nada a instalar. A coleta de Web Vitals faz parte do tracker padrão do Zenovay. Se o seu script de rastreamento já está rodando, os vitals começam a fluir assim que os visitantes carregarem suas páginas.
O que os Web Vitals medem
Os Core Web Vitals são os sinais estáveis do Google para a experiência real de página. Eles aparecem no Google Search Console, influenciam o ranqueamento e se correlacionam fortemente com taxa de rejeição e conversão.
| Métrica | O que mede | Bom | A melhorar | Ruim |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Quando o conteúdo principal se torna visível | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s |
| CLS — Cumulative Layout Shift | Quanto o conteúdo visível se desloca inesperadamente | ≤ 0,1 | ≤ 0,25 | > 0,25 |
| INP — Interaction to Next Paint | Pior atraso entre clique/toque e o próximo render | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| FCP — First Contentful Paint | Quando o primeiro texto/imagem é renderizado | ≤ 1,8 s | ≤ 3,0 s | > 3,0 s |
| TTFB — Time to First Byte | Quando o primeiro byte chega do servidor | ≤ 800 ms | ≤ 1,8 s | > 1,8 s |
Os limiares seguem as recomendações publicadas pelo Google e se refletem diretamente na codificação de cores do painel do Zenovay (verde / âmbar / vermelho).
Como o Zenovay coleta os dados
A coleta acontece inteiramente no navegador via a API padrão PerformanceObserver e a entrada Navigation Timing — sem biblioteca de terceiros, sem script adicional.
Fluxo curto:
- Assim que o tracker é inicializado, ele registra observers para
largest-contentful-paint,layout-shift,event(para INP) epaint(para FCP). - TTFB é lido uma vez a partir de
performance.getEntriesByType('navigation')[0].responseStart. - Os valores finais são agrupados em um único payload e enviados para
POST /api/track/<seu-código-de-rastreamento>/performancequando o visitante sai da página (visibilitychange→ hidden, maispagehidepara o bfcache mobile). - A API marca cada linha com
country_code,device_type,browsere — quando disponível —connection_type.
O payload não carrega valores de formulário, nem conteúdo do DOM, nem PII além do que já faz parte de um pageview analítico (a URL).
Um beacon por ciclo de vida de página. Os vitals são enviados exatamente uma vez quando o visitante sai de uma página. SPAs que roteiam no cliente enviam um beacon novo a cada transição — assim como eventos de pageview.
Onde ver seus dados
Abra qualquer domínio em app.zenovay.com e clique na aba Performance.
Você verá:
- Uma barra lateral de métricas com o valor atual, a classificação por limiar e a distribuição por percentil para LCP / CLS / INP / FCP / TTFB.
- Um painel de detalhe com a tendência da métrica selecionada no intervalo escolhido, mais uma explicação contextual do que a afeta.
- Detalhamentos por Rotas e Países mostrando quais páginas e regiões têm o pior desempenho.
- Controles para:
- Dispositivo — Todos / Desktop / Mobile
- Percentil — P75 / P90 / P95 / P99 (Google usa P75 por padrão)
- Intervalo de tempo — limitado por plano (ver abaixo)
Orientação sobre percentis
O Google usa o 75º percentil dos usuários reais para sinais de ranqueamento no Search Console. Percentis mais altos (P90, P95, P99) destacam seus visitantes mais lentos — úteis ao investigar uma regressão específica ou uma cauda de dispositivos lentos.
Disponibilidade por plano e retenção
A coleta de Web Vitals está incluída em todos os planos, inclusive Free. O acesso ao intervalo é escalonado por plano:
| Plano | Intervalo do Performance |
|---|---|
| Free | Últimos 7 dias |
| Pro | Últimos 30 dias |
| Scale | Últimos 90 dias |
| Enterprise | Até 1 ano |
Esses limites espelham os níveis de retenção analítica mais amplos — veja Preços e limites de plano para as regras subjacentes.
Desativando Web Vitals para um site específico
Os vitals estão ativos por padrão. Para desativá-los em um único site rastreado, defina a feature flag nas configurações desse site:
{
"feature_flags": {
"enable_core_web_vitals": false
}
}
Quando a flag está em false:
- O tracker não registra os observers (custo zero no navegador).
- O endpoint da API aceita o beacon, mas não armazena nada (no-op silencioso para requisições em trânsito).
Para reativar, defina a flag de volta como true ou remova-a (ativada por padrão).
Perguntas frequentes
Por que o INP está ausente no Safari?
O Safari só implementou o tipo de entrada event do PerformanceObserver com interactionId muito recentemente. Em versões antigas do Safari, o Zenovay reporta LCP, CLS, FCP e TTFB e deixa INP como null para aquela sessão. O painel simplesmente mostrará menos amostras de INP até que a cobertura do Safari aumente — nenhuma ação é necessária da sua parte.
SPAs recebem um beacon por mudança de rota?
Sim. O tracker reinicia os observers a cada transição de página rastreada (incluindo rotas SPA que disparam pushState ou replaceState). Você verá uma linha de performance por pageview, e não uma por sessão de navegador.
A coleta de vitals afeta a performance do meu site?
PerformanceObserver é uma API de navegador passiva projetada exatamente para esse caso de uso. Os observers disparam em eventos existentes do navegador; não há polling nem trabalho extra na thread principal. O único beacon no descarregamento da página é enviado via fetch com keepalive: true, então ele não bloqueia a navegação.
Por que meus números não batem com os dados do CrUX do Google?
Duas razões normais:
- População amostrada. O Zenovay mede cada visitante real que carrega seu site. O CrUX mede apenas usuários Chrome que optaram pela anonimização de URL — um subconjunto estrito.
- Janela temporal. CrUX é uma janela móvel de 28 dias, somente com dados do Chrome. O Zenovay permite escolher sua própria janela e segmentar por dispositivo, percentil, rota e país.
Ambos os sinais são válidos; eles respondem perguntas levemente diferentes. O Google usa CrUX para ranqueamento; você usa o Zenovay para depurar.
Onde encontro os valores de limiar no código?
Eles vivem em app-zenovay/lib/api/performance.ts (constantes do frontend) e refletem os limiares publicados pelo Google. Mudá-los exige uma atualização de código — deliberadamente não são configuráveis pelo cliente, para que os rótulos «Bom» / «A melhorar» / «Ruim» permaneçam comparáveis em todo o produto.
Solução de problemas para painéis vazios
Se a aba Performance mostrar o estado vazio («No performance data yet»):
- Verifique se o tracker está disparando. Abra o diagnóstico Install Health. Se os pageviews não estão fluindo, os vitals também não estarão.
- Confira a feature flag. Garanta que
feature_flags.enable_core_web_vitalsnão esteja explicitamente emfalsenas configurações do site. - Dê algum tráfego. Os beacons de vitals disparam no descarregamento da página. Um site com tráfego muito baixo — ou testado apenas por você com cache recém-limpo — pode precisar de algumas sessões antes que os números apareçam.
- Amplie o intervalo de tempo. Um site novo no Free mostra por padrão os últimos 7 dias — recém-instalado, amplie para o máximo permitido pelo seu plano.
- Abra as DevTools → Rede. Com o filtro
Performance, procure umPOSTpara/api/track/<code>/performance. A resposta é um pequeno JSON comsuccess: true.
Se a requisição está sendo enviada mas nenhum dado aparece, contate [email protected] com seu código de rastreamento — existe uma flag de opt-out por site e podemos confirmar que ela não está definida.
Relacionado
- Install Health — confirme se o tracker está disparando
- Rastreamento em tempo real — veja visitantes assim que chegam
- Conformidade de privacidade — quais dados o tracker envia e por quê