Como medir a velocidade de um site corretamente

O cliente abriu o PageSpeed Insights, viu 72/100 e achou que estava tudo bem. Uma semana depois, o Google Search Console mostrava 38% das URLs reprovando em LCP no relatório de Core Web Vitals. Não tinha contradição — eram dados de fontes diferentes medindo coisas diferentes. O score de 72 era laboratório; as reprovações eram da vida real.

Esse é o problema central de medir performance na web: as ferramentas existem, os dados existem, mas o que cada número significa depende de de onde ele veio.

Lab data vs field data: a diferença que define tudo

Todo número de performance que você vai encontrar pertence a uma dessas duas categorias.

Lab data é sintético. Uma ferramenta simula um dispositivo, uma conexão de rede e carrega a página uma vez em condições controladas. O Lighthouse usa um Moto G Power emulado em conexão 4G lenta (10 Mbps, 40 ms de RTT) como referência. O WebPageTest permite escolher a máquina real, localização e throttling. O resultado é reproduzível e isolado — bom para debugging, ruim para representar usuários reais.

Field data é coletado de usuários reais. O Chrome instrumenta métricas de performance silenciosamente para usuários que optaram em compartilhar dados, e esses dados são agregados no CrUX (Chrome User Experience Report). O CrUX alimenta o PageSpeed Insights e o Search Console. Ele reflete usuários em Xiaomi de entrada em São Paulo, em iPhone 14 em fibra em São Paulo, em conexão 3G em área rural — toda a diversidade real da sua audiência.

A implicação prática: lab data é onde você encontra o problema. Field data é onde você confirma que resolveu.

O que cada ferramenta mede de fato

PageSpeed Insights

O PageSpeed Insights (PSI) roda o Lighthouse sob o capô, mas não é só o Lighthouse. A diferença crucial é que o PSI camada dados do CrUX acima do resultado de laboratório — quando seu site tem dados suficientes.

A interface tem dois blocos distintos:

• "Dados de campo" (topo) → 28 dias de dados reais do CrUX, percentil 75
• "Diagnóstico de laboratório" (abaixo) → Lighthouse rodado nos servidores do Google

São informativos diferentes. O score de 0–100 é do laboratório. As barrinhas de LCP/INP/CLS que determinam se a URL passa ou não nos Core Web Vitals são do campo. Esse score de laboratório não afeta ranking — o que o Google usa para rankear é o campo.

Uma URL com score 95 no laboratório pode reprovar no campo se seus usuários reais estiverem em dispositivos mais lentos do que o Moto G Power simulado. E o inverso existe: score 60 no laboratório, mas campo verde, porque seus usuários estão em iPhones com fibra.

Lighthouse

O Lighthouse é a fundação do PSI, mas você o usa de formas distintas dependendo do contexto:

• DevTools: roda na sua máquina, com seu cache, suas extensões, seu hardware. Util para comparações rápidas durante desenvolvimento — mas os números absolutos não valem nada sem contexto.
• CLI: npx lighthouse https://exemplo.com --throttling-method=simulate em ambiente controlado. Bom para CI/CD — detectar regressões entre deploys antes de chegar em produção.
• PSI: roda nos servidores do Google, sem cache local, sem extensões, hardware consistente. É o Lighthouse mais confiável para comparação com concorrentes.

Um detalhe de implementação que muda os resultados: o Lighthouse usa throttling por software — simula latência adicionando delays programaticamente. O WebPageTest usa throttling por pacote — atrasa o tráfego no nível do sistema operacional. Throttling por pacote é mais fisicamente preciso e geralmente resulta em métricas piores (mais realistas) do que o Lighthouse para a mesma conexão simulada.

WebPageTest

O WebPageTest é a ferramenta de análise mais poderosa que existe de graça para performance de frontend. O que ele oferece além do Lighthouse:

• Filmstrip: screenshots frame a frame do carregamento — você vê exatamente quando a página ficou visualmente completa
• Waterfall detalhado: cada recurso, com timing de DNS lookup, TCP connect, TTFB, download, blocking time
• Múltiplas localizações: testar do Brasil, EUA, Europa, Ásia na mesma sessão
• Múltiplas rodadas: faz 3–5 corridas e mostra mediana e desvio — o Lighthouse faz só uma
• Teste de usuário real via WebDriver: simula cliques e interações para medir INP em fluxos específicos

O WebPageTest é o lugar certo quando o Lighthouse diz "tudo bom" mas usuários reclamam de lentidão, ou quando você precisa comparar performance em localizações geográficas diferentes.

CrUX e Search Console

O CrUX agrega dados do Chrome em três granularidades: URL específica, grupo de páginas similares (origin-level), e domínio. O Google Search Console expõe esses dados com filtros por tipo de dispositivo e URL.

Um ponto que confunde: se sua URL tem pouco tráfego, o CrUX pode não ter dados suficientes para ela individualmente. Nesse caso, o Search Console mostra os dados do domínio como fallback. Um post novo não tem dados de campo — o Lighthouse é tudo que você tem até acumular visitas suficientes.

O relatório "Core Web Vitals" no Search Console é a visão mais acionável para SEO: lista URLs agrupadas por problema, com status "ruim/precisa melhorar/bom". É dali que você prioriza o que consertar.

Por que o Lighthouse mente (e quando confiar nele)

O score do Lighthouse é uma média ponderada de métricas com pesos diferentes. Em 2026, os pesos são aproximadamente: LCP 25%, TBT 30%, Speed Index 10%, FCP 10%, CLS 25%. O TBT (Total Blocking Time) é o proxy de laboratório para INP — mede tempo de main thread bloqueado, que correlaciona com interações lentas.

O problema é que TBT alto no laboratório nem sempre vira INP alto no campo — e vice-versa. Um site com muitos event listeners complexos pode ter TBT baixo (nenhuma long task durante o carregamento) mas INP alto (cada clique dispara trabalho pesado). O Lighthouse não captura isso.

Outro ponto de atenção: o Lighthouse mede o carregamento inicial. Se sua página é um SPA que faz fetch de dados após o mount, o Lighthouse pode não capturar a experiência real — os dados chegam depois da janela de medição. O field data pega isso.

Os casos em que o Lighthouse mente mais:

1. Sites que dependem de autenticação — o Lighthouse não faz login, então testa a landing page pública, não o produto real
2. Pages com conteúdo personalizado — A/B tests, banners dinâmicos baseados em geolocalização
3. Sites com heavy client-side rendering — o score pode parecer ok mas o usuário vê spinner por 3 segundos

Para entender LCP, INP e CLS em detalhes — o que cada threshold significa e como resolver cada um — o post Core Web Vitals: LCP, INP e CLS explicados cobre isso em profundidade.

O número que o Google usa para rankear: percentil 75

Os Core Web Vitals são avaliados no percentil 75 das sessões reais coletadas pelo CrUX nos últimos 28 dias. Não a média. O percentil 75.

Isso significa: 75% dos seus usuários precisam ter LCP ≤ 2.0s (threshold atual em 2026, após o ajuste do Google em março de 2026), INP ≤ 200ms e CLS ≤ 0.1 para a página passar. Os 25% mais lentos determinam se você reprova.

A implicação prática: otimizar só para o caso médio não basta. Se seu site é rápido em fibra mas tem usuários em 4G, esses 25% em conexão lenta são o que determina se você passa ou não.

Em maio de 2026, 55.9% das origens rastreadas pelo CrUX passam nos três Core Web Vitals simultaneamente. Ou seja: quase metade dos sites na web ainda reprova. As métricas individuais: 68.6% passam em LCP, 81.3% em CLS, 86.6% em INP.

Como montar um workflow de medição que faz sentido

Medir uma vez não é monitorar. Performance regride — um deploy novo, uma imagem sem otimização, um script de terceiro. O setup que funciona na prática:

Durante desenvolvimento:

# Lighthouse CLI integrado ao CI
npx lighthouse https://staging.exemplo.com \
  --output json \
  --output-path report.json \
  --chrome-flags="--headless"

# Checar score mínimo (ex: falhar build se LCP > 2.5s)
node -e "
const r = require('./report.json');
const lcp = r.audits['largest-contentful-paint'].numericValue;
if (lcp > 2500) process.exit(1);
"

Após deploy em produção:

• PageSpeed Insights para ver se o campo ainda está verde
• Search Console para ver se novas URLs estão acumulando problemas

Para debugging de problemas específicos:

• WebPageTest com filmstrip para ver exatamente quando o LCP elemento aparece
• DevTools Performance panel para identificar long tasks ligadas a interações (INP)
• web-vitals library instrumentada no código para coletar field data customizado:

import { onLCP, onINP, onCLS } from 'web-vitals';

// envia para seu analytics
onLCP(({ value, id }) => analytics.track('web_vital', { metric: 'LCP', value, id }));
onINP(({ value, id }) => analytics.track('web_vital', { metric: 'INP', value, id }));
onCLS(({ value, id }) => analytics.track('web_vital', { metric: 'CLS', value, id }));

Com isso, você tem field data próprio — não dependente do CrUX ter volume suficiente — e consegue filtrar por país, dispositivo, versão do app.

Perguntas frequentes

Por que meu score no PageSpeed muda toda vez que rodo?

Lab data tem variância natural — processos concorrentes no servidor do Google, estado diferente de CDN, timing de requests de terceiros. Diferenças de ±5 pontos entre rodadas são normais. O que importa é a tendência ao longo de várias rodadas, não o número de uma rodada específica. O WebPageTest roda múltiplas vezes e mostra a mediana justamente por isso.

Qual ferramenta usar para medir velocidade de site: PageSpeed ou Lighthouse?

Depende do que você precisa. Se a pergunta é "meus usuários reais estão tendo uma experiência boa?", use PageSpeed Insights e olhe o bloco de field data. Se a pergunta é "o que está causando lentidão para eu consertar?", use Lighthouse no DevTools ou o WebPageTest para o waterfall detalhado. São ferramentas complementares, não substitutas. Em projetos que monitoro, uso PageSpeed para a visão executiva e WebPageTest quando preciso investigar algo específico.

Score alto no Lighthouse garante bom rankeamento?

Não diretamente. O score de laboratório não é o que o Google usa para ranking — são os Core Web Vitals do campo (CrUX). É possível ter score 90 no laboratório e reprovar no campo. O que conta para SEO é o percentil 75 das métricas reais dos seus usuários, não o resultado sintético da simulação.

Meu site é novo e não tem dados no Search Console. O que fazer?

Para sites novos, o CrUX demora algumas semanas para acumular dados suficientes. Enquanto isso, trabalhe com lab data: rode o Lighthouse na versão de produção (não localhost), use condições de throttling que representem sua audiência, e instrumente a web-vitals library para coletar seu próprio field data desde o início.

Medir direito antes de otimizar

Performance no browser é medida em camadas — e cada camada pode mentir sobre as outras. O score de laboratório é útil para encontrar problemas e detectar regressões em CI. O field data é o que determina se o usuário real está tendo uma experiência boa e se o Google vai te rankear melhor.

O erro mais comum que vejo é tratar o score do Lighthouse como objetivo final. O objetivo é o percentil 75 do campo estar verde — LCP ≤ 2.0s, INP ≤ 200ms, CLS ≤ 0.1. O Lighthouse é um instrumento de diagnóstico no caminho até lá, não a linha de chegada.

Para gerar e validar as meta tags de SEO do seu site enquanto trabalha na performance — título, description, og:image — uso o Quick Tools Meta Tag Generator para checar o preview antes de subir.