Por que o score do PageSpeed não conta a história inteira

O dev mostrou orgulhoso: "100/100 no PageSpeed em mobile e desktop". Duas semanas depois, o mesmo site aparecia reprovando em Core Web Vitals no Search Console — LCP "ruim" para 31% das URLs. Não era um bug. O 100/100 estava correto. E o site ainda estava lento para usuários reais.

Esse é o paradoxo que ninguém explica direito: você pode ter nota máxima no PageSpeed e ainda assim ter um site que frustra o usuário e perde posição no ranking.

O que o score do PageSpeed realmente mede

O número de 0 a 100 que o PageSpeed Insights exibe não é uma medição direta de velocidade. É uma média ponderada de métricas de laboratório, calculada pelo Lighthouse rodando em condições simuladas nos servidores do Google.

Em 2026, os pesos aproximados são:

Dois pontos críticos aqui.

Primeiro: TBT não é um Core Web Vital. É um proxy de laboratório para INP — mede tempo de main thread bloqueado durante o carregamento. A correlação existe, mas é imperfeita. Um site pode ter TBT baixíssimo no laboratório e INP horrível no campo se o trabalho pesado acontece em interações pós-carregamento, não durante o boot.

Segundo: CLS tem peso de 25%, mas afeta o score de forma não-linear. Um CLS de 0.05 (bom) pontua bem. Um CLS de 0.12 (precisa melhorar por apenas 0.02 acima do threshold) pode derrubar o score consideravelmente. Isso cria incentivo para otimizar o que mexe mais no número — não necessariamente o que mais impacta o usuário.

Por que 100/100 não significa site rápido

O Lighthouse roda em condições específicas: Moto G Power emulado, conexão 4G lenta simulada via throttling de software (10 Mbps down, 40 ms RTT). Essa é uma condição. A sua audiência é outra.

Se seus usuários estão em Xiaomi Redmi 12 com 3G instável no interior de SP, eles têm hardware e rede piores do que o benchmark do Lighthouse. Se sua audiência é majoritariamente desktop com fibra no exterior, o Lighthouse está sendo mais pessimista do que a realidade. Em ambos os casos, o score de laboratório e a experiência real divergem.

O cenário de score alto + experiência ruim acontece tipicamente quando:

1. O site carrega rápido, mas fica lento depois do mount

SPAs (Single Page Applications) são campeões aqui. O Lighthouse mede o carregamento inicial. Se a página monta em 1.2s mas passa os próximos 3 segundos fazendo fetch de dados e populando componentes, o Lighthouse dá nota boa. O usuário vê spinner. O CrUX vai pegar isso no INP, mas o score de laboratório não.

2. Throttling de software subestima redes móveis ruins

O Lighthouse simula 4G atrasando pacotes via software, o que não captura os efeitos de jitter e perda de pacotes de redes móveis reais. O WebPageTest com throttling de hardware (ou teste em dispositivo físico com proxy) consistentemente mostra métricas piores para a mesma conexão nominal. Você passa no Lighthouse, reprova na realidade.

3. O elemento LCP muda entre desktop e mobile

Você otimizou o hero desktop com fetchpriority="high" e preload. No mobile, o layout é diferente — o "maior elemento" é um bloco de texto no meio da página que nem tem preload. Score desktop: 94. Score mobile: 61. E CrUX segmenta por dispositivo também.

4. Recursos de terceiros carregam depois da janela de medição

O Lighthouse tem uma janela de medição limitada. Scripts de terceiros (chat widgets, tracking pixels, A/B test scripts) que carregam 4–6 segundos depois do DOMContentLoaded não afetam o score de laboratório. Mas eles travam o main thread quando chegam, aumentando INP nos momentos em que o usuário está tentando interagir. Field data pega isso. Lab data não.

O número que afeta ranking não é o score

Esse ponto merece ser explícito: o Google não usa o score de 0–100 como fator de ranking. O que afeta ranking são os Core Web Vitals medidos no campo, via CrUX.

A avaliação é binária por métrica: passa ou não passa. O threshold em 2026:

• LCP ≤ 2.5s (campo, p75) — passa
• INP ≤ 200ms (campo, p75) — passa
• CLS ≤ 0.1 (campo, p75) — passa

Se 75% dos seus usuários reais têm LCP abaixo de 2.5s, você passa. Se o Lighthouse simula 1.8s mas usuários reais no p75 têm 3.1s, você reprova — independente do score.

Em junho de 2026, 55.9% das origens rastreadas pelo CrUX passam nos três Core Web Vitals simultaneamente. Quase metade dos sites na web ainda reprova em pelo menos uma métrica, apesar de muitos terem scores de laboratório aparentemente aceitáveis.

As otimizações que só melhoram o número

Existe uma classe de otimizações que melhoram o score sem melhorar a experiência real. Reconhecê-las evita desperdício de esforço.

Remover recursos que o Lighthouse detecta mas não afetam usuários reais

O Lighthouse penaliza JavaScript não utilizado. Ferramentas automatizadas de tree-shaking agressivo podem remover código de interação que só é ativado por eventos — o que parece "não utilizado" no carregamento inicial mas é crítico para INP. Score sobe, interações ficam quebradas.

Otimizar só a página testada

O PageSpeed avalia uma URL por vez. Alguns times otimizam a homepage até 95+ e ignoram as pages de produto — que têm mais tráfego, mais impacto de conversão, e estão em 55. CrUX vai pegar as URLs de produto no Search Console.

Minificar tudo que não precisa ser minificado

Minificação tem retorno decrescente rápido. Se o HTML já está gzipado na CDN, economizar 2KB num arquivo de 8KB não vai mover needle em LCP. Mas vai ocupar horas de dev que poderiam ir para investigar por que o CrUX mostra LCP ruim em mobile.

Substituir fontes web por system fonts só pra eliminar o audit

O Lighthouse penaliza fontes que causam FOUT. Trocar Inter por -apple-system, Segoe UI, sans-serif elimina o aviso e sobe o score — mas também elimina consistência visual entre plataformas. É uma decisão de produto, não uma otimização de performance. Não deixe um audit de laboratório tomar essa decisão por você.

Como ler o PageSpeed Insights sem ser enganado

O PSI tem dois blocos distintos e a maioria das pessoas olha só o score:

┌─────────────────────────────────┐
│  DADOS DE CAMPO (CrUX)          │  ← isso afeta ranking
│  LCP: 2.1s ✓  INP: 180ms ✓     │
│  CLS: 0.08 ✓                    │
├─────────────────────────────────┤
│  Performance: 87               │  ← score de laboratório
│  (Diagnóstico Lighthouse)       │  ← não afeta ranking
└─────────────────────────────────┘

Regra prática: leia de cima pra baixo, não de baixo pra cima. O bloco de campo está no topo por uma razão — é o mais importante. O score está embaixo porque é secundário.

Se o bloco de campo mostrar as três métricas em verde, você passou no que importa para o Google. O score de laboratório ainda é útil para diagnosticar regressões e encontrar problemas, mas não é a linha de chegada.

Se o bloco de campo estiver ausente ("Não há dados de campo disponíveis"), seu site tem tráfego insuficiente no CrUX. Nesse caso, trabalhe com lab data como proxy, instrumente a biblioteca web-vitals para coletar seu próprio field data, e aceite que os Core Web Vitals podem não ser um fator de ranking ativo ainda.

Quando o score alto é um sinal de alerta

Existe uma situação específica onde um score muito alto deve levantar suspeita: quando ele foi conquistado recentemente após um período de score baixo, sem mudanças óbvias no código.

Às vezes, o que acontece é que o site ficou menor — em funcionalidade. Scripts de terceiros foram removidos sem verificação de impacto. Componentes de interação foram simplificados. Fontes foram trocadas. O score subiu porque o produto encolheu, não porque ele ficou mais eficiente.

O score de laboratório não mede valor entregue. Mede características técnicas de carregamento em condições simuladas. Um site que faz menos coisas sempre vai pontuar melhor que um site equivalente que faz mais. Às vezes isso é ótimo (remover peso desnecessário). Às vezes é perigoso (remover funcionalidade que tem valor).

Para entender o que o Search Console está mostrando em termos de field data real — separado por tipo de dispositivo e URL — o post como medir a velocidade do seu site de verdade detalha o workflow completo, incluindo como interpretar os dados do CrUX por URL específica.

Perguntas frequentes

Por que meu score muda entre duas rodadas seguidas?

Lab data tem variância natural. O Lighthouse roda em servidores compartilhados do Google — estado de CPU, timing de requests de terceiros, CDN cache hit ou miss podem variar entre rodadas. Diferença de ±5–8 pontos é normal e esperada. O que importa é a tendência ao longo de várias rodadas, não uma leitura isolada. Para reduzir ruído, rode três vezes e use a mediana.

Score alto no PageSpeed garante bom posicionamento no Google?

Não diretamente. O score de laboratório não é usado como fator de ranking. O que o Google avalia são os Core Web Vitals do campo (CrUX), medidos no percentil 75 dos usuários reais. É possível ter score 95 no laboratório e reprovar no campo — geralmente porque usuários reais estão em dispositivos ou redes piores do que o benchmark do Lighthouse.

Vale a pena chegar em 100/100 ou é desperdício de tempo?

Depende. Se você está em 50/100 com INP ruim e LCP de 4 segundos, subir para 85 vai melhorar experiência real e SEO. Se você está em 90/100 com todas as métricas de campo verdes, gastar tempo para chegar em 100 é rendimento marginal decrescente — o esforço provavelmente é melhor alocado em conteúdo ou funcionalidade. O threshold que importa é o campo estar verde, não o laboratório estar em 100.

Como saber se meus usuários reais estão tendo uma experiência boa?

Pelo Search Console (relatório "Core Web Vitals"), pelo bloco de "Dados de campo" no topo do PageSpeed Insights, e pela biblioteca web-vitals instrumentada no seu código. Essas três fontes mostram o que está acontecendo com usuários reais — não o que o laboratório simula.

O score é o termômetro, não a febre

Score de PageSpeed é útil como termômetro de diagnóstico — indica que algo pode estar errado e onde investigar. Mas ele não é a febre. A febre é LCP alto para usuários reais, INP lento em interações críticas, CLS quebrando o layout no scroll.

Otimizar para o número em vez de para a experiência é como tomar antitérmico para parecer saudável na medição. O termômetro cai, a infecção continua.

Para gerar e testar as meta tags do site enquanto trabalha em performance — og:image, description, title — uso o Meta Tag Generator para checar o preview antes de subir, sem precisar fazer um deploy inteiro para ver como vai aparecer no Google e nas redes sociais.