Core Web Vitals: porque a monitorização de uptime não chega

Em resumo: O servidor devolve HTTP 200, a monitorização diz "UP" - e ainda assim perdes tráfego do Google. Os Core Web Vitals (LCP, INP, CLS) medem a experiência real do utilizador. Um web lento é, da perspetiva do Google, "down" tal como um indisponível.

Em resumo: O servidor devolve HTTP 200, a monitorização diz "UP" - e ainda assim perdes tráfego do Google. Os Core Web Vitals (LCP, INP, CLS) medem a experiência real do utilizador. Um web lento é, da perspetiva do Google, "down" tal como um indisponível.

Três métricas CWV

O Google introduziu em 2020 os Core Web Vitals como fator de ranking. Desde março de 2024 são compostos por:

LCP (Largest Contentful Paint) - quando aparece o maior elemento da página. Bom: ≤ 2,5 s. A melhorar: 2,5-4 s. Mau: > 4 s.
INP (Interaction to Next Paint) - com que rapidez a página reage às interações do utilizador (clique, tap). Substituiu o FID em março de 2024. Bom: ≤ 200 ms. A melhorar: 200-500 ms. Mau: > 500 ms.
CLS (Cumulative Layout Shift) - quanto os elementos da página se movem visualmente durante o carregamento. Bom: ≤ 0,1. A melhorar: 0,1-0,25. Mau: > 0,25.

Porque a monitorização não o apanha

Um monitor de uptime clássico envia um pedido HTTP GET e mede:

Código de status (200 = OK)
Time to first byte (TTFB)
Opcionalmente keyword match no HTML

Mas não renderiza a página no browser. Não vê que:

O bundle JavaScript tem 3 MB e o parsing demora 4 segundos
A imagem hero carrega sincronamente e bloqueia o paint
Terceira parte (analytics, publicidade) bloqueia o main thread
O layout salta à medida que os elementos carregam

Da perspetiva do visitante o web é lento e inutilizável - da perspetiva da monitorização tudo está "UP".

Lab vs field data

Os CWV medem-se de duas maneiras:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - browser controlado, rede definida (tipicamente 4G), dispositivo específico. Reproduzível, adequado para testes de regressão após deploys.

Field data / RUM (Chrome User Experience Report, JS próprio) - recolha de dados de visitantes reais nas suas condições reais. O que o Google usa para ranking. Reflete a variabilidade real (cliente móvel 3G de um comboio, desktop fibra, etc.).

Lab data são uma boa referência, field data são a verdade.

Nota: ePulz.io atualmente não rastreia métricas CWV. Para medi-las, use ferramentas especializadas (PageSpeed Insights, WebPageTest, Lighthouse CI ou seu próprio snippet RUM JS). Para regressões visuais, ePulz.io oferece um monitor do tipo visual que compara screenshots - isso cobre parcialmente cenários de "a página renderiza completamente diferente", mas não mede LCP/INP/CLS.

Estratégia prática de monitorização

Synthetic uptime check - monitor HTTP clássico a cada 1-5 min. Deteta hard downtime, 5xx, certificados expirados.
Medição CWV (fora do ePulz) - Lighthouse CI no pipeline de deployment ou cron noturno ou Chrome headless uma vez por dia. Deteta regressão após implementação (LCP subiu de 1,8 s para 4,2 s após o deploy de um novo bundle JS).
Visual regression check - screenshot diff. Deteta quando a página renderiza completamente diferente de antes (CSS partido, font fail, JS error).
Real User Monitoring - snippet JS na página recolhe CWV de visitantes reais. Segues o percentil 75 das métricas.

Principais causas de CWV maus

LCP demasiado alto:

Imagens hero grandes sem priority hint (fetchpriority="high")
Servidor lento / TTFB (CDN cache miss, query DB lenta)
Blocking resources no <head> (analytics, fonts sem display=swap)
Web fonts carregadas de CDN de terceiros sem preconnect

INP demasiado alto:

Grande bundle JS a bloquear o main thread
Event listeners síncronos que fazem trabalho pesado
Scripts de terceiros lentos (chat widgets, A/B testing)

CLS demasiado alto:

Imagens sem atributos width e height explícitos
Anúncios sem espaço reservado
Conteúdos injetados dinamicamente acima do fold
Web fonts com FOUT (Flash of Unstyled Text) sem fallback adequado

Impacto SEO

O Google usa CWV como tie-breaker. Com conteúdo igualmente relevante prefere a página mais rápida. Em nichos competitivos é decisivo.

Impacto prático:

Um site com CWV no intervalo "good" tem em média ~20% mais baixo bounce rate
O conversion rate sobe a cada -100 ms LCP
Mobile-first indexing significa que o Google avalia a versão mobile - testa aí

Conclusão

A monitorização de uptime responde "O servidor está alcançável?". Os Core Web Vitals respondem "O web é usável?". Ambas as métricas são independentes e ambas precisas seguir. O servidor pode ter 100% de uptime e o web ainda assim perder tráfego devido a LCP acima de 4 segundos.

Monitorização para além do uptime

A visual regression deteta mudanças visuais mesmo quando o servidor devolve 200. A monitorização do response time apanha endpoints lentos.

Experimentar ePulz.io →