Google PageSpeed: o que Medir e o que Ignorar
O PageSpeed Insights é a ferramenta gratuita do Google que avalia o desempenho de uma página e entrega dois blocos diferentes de informação: os dados reais de quem visitou o site e uma simulação feita na hora. A nota colorida que todo mundo olha vem da simulação e não é o que o Google usa para avaliar experiência. O que conta são os Core Web Vitals medidos em usuários reais.
- A nota de 0 a 100 é diagnóstico de laboratório, não critério de classificação.
- Os Core Web Vitals atuais são LCP, INP e CLS — o FID foi aposentado em 2024.
- Para ser considerada boa, a página precisa passar nos três ao mesmo tempo, no percentil 75.
- Dado de campo só aparece quando a página tem tráfego suficiente nos últimos 28 dias.
- Velocidade é critério de desempate, não de posicionamento: conteúdo fraco e rápido continua fraco.
- Perseguir nota 100 costuma custar mais do que rende.
Poucos relatórios geram tanta ansiedade quanto esse. Uma nota vermelha aparece, alguém pede providência urgente, e o trabalho começa pelo item errado.
Aqui explicamos o que a ferramenta mede de fato, a diferença entre as duas metades do relatório, quais métricas importam hoje e o que priorizar quando o orçamento é limitado.
O que o PageSpeed Insights realmente mede?
O PageSpeed Insights mede duas coisas ao mesmo tempo, e confundir uma com a outra é a origem de quase toda decisão errada sobre velocidade. Ele exibe dados de usuários reais e, separadamente, uma simulação executada no momento da consulta.
A parte de cima do relatório traz a experiência real, coletada de usuários do Chrome que visitaram aquela página nos últimos 28 dias. A parte de baixo traz a auditoria técnica, feita em um ambiente controlado, com a nota de 0 a 100 e a lista de oportunidades.
| Bloco | Origem | Serve para | Conta para o Google? |
|---|---|---|---|
| Dados de campo | Usuários reais do Chrome, 28 dias | Saber como está de verdade | Sim |
| Dados de laboratório | Simulação feita na hora | Descobrir o que corrigir | Não |
| Nota de 0 a 100 | Cálculo da simulação | Comparar antes e depois | Não |
Em texto: use o campo para saber se existe problema e o laboratório para descobrir onde ele está. A nota serve como termômetro de progresso entre duas medições suas, e não como meta.
Um detalhe que explica muita confusão: páginas com pouco tráfego não têm dados de campo, porque não há visitas suficientes para formar a amostra. Nesses casos o relatório mostra apenas a simulação, e a avaliação real fica indisponível.
Quais são os Core Web Vitals hoje?
São três métricas, e uma delas mudou recentemente. Elas medem carregamento, resposta a interação e estabilidade visual, sempre a partir de usuários reais.
- LCP, Largest Contentful Paint. Mede quanto tempo leva até o maior elemento visível aparecer. Bom até 2,5 segundos.
- INP, Interaction to Next Paint. Mede quanto tempo a página leva para responder às interações do usuário. Bom até 200 milissegundos.
- CLS, Cumulative Layout Shift. Mede o quanto o conteúdo se mexe sozinho durante o carregamento. Bom até 0,1.
O INP substituiu o FID, First Input Delay, em março de 2024. A diferença importa: o FID media apenas o atraso da primeira interação, enquanto o INP considera as interações ao longo de toda a visita. Sites que passavam com folga no FID começaram a reprovar no INP, e não porque pioraram.
A régua de aprovação tem duas condições que costumam ser esquecidas:
- É preciso passar nas três métricas, não em duas.
- A medição usa o percentil 75, ou seja, 75% das visitas precisam ter experiência boa.
O percentil 75 é o que torna a média enganosa. Um site pode ter média excelente e ainda reprovar, porque um quarto dos usuários enfrenta uma experiência ruim em conexões lentas ou aparelhos modestos.
A nota do PageSpeed afeta o posicionamento?
A nota não afeta. As métricas de experiência afetam, e de forma menor do que se costuma imaginar.
O Google trata experiência da página como um sinal entre muitos, e ele funciona principalmente como critério de desempate. Entre dois resultados equivalentes em relevância e autoridade, o mais rápido leva vantagem. Entre um resultado excelente e lento e um raso e veloz, a relevância continua ganhando.
O que a velocidade realmente decide:
- Conversão, porque página lenta perde visitante antes de carregar.
- Rastreamento, já que site lento consome mais tempo do robô e limita a frequência de visita.
- Experiência em celular, onde o impacto é maior e o público brasileiro está.
- Desempate, em disputas equilibradas.
Um exemplo hipotético deixa a proporção clara. Um site com nota 45 e conteúdo aprofundado, assinado por especialista, tende a superar um concorrente com nota 98 e texto genérico. Corrigir a velocidade do primeiro melhora o resultado; corrigir o conteúdo do segundo melhora muito mais.
O que priorizar quando o orçamento é limitado?
Priorize o que aparece nos dados de campo, na ordem em que afeta o usuário. Ignorar a lista de oportunidades do laboratório e olhar primeiro o que os visitantes reais enfrentam economiza semanas.
A ordem que costuma render mais:
- Imagens, quase sempre a maior causa de LCP ruim. Formato moderno, tamanho correto e carregamento adiantado do elemento principal.
- Hospedagem e resposta do servidor, porque nenhum ajuste de front-end compensa um servidor lento.
- Scripts de terceiros, como chats, mapas, pixels e ferramentas de teste, que costumam dominar o INP.
- Fontes e CSS, que atrasam a primeira renderização quando carregados sem critério.
- Reserva de espaço para elementos, que resolve a maior parte do CLS.
O item 3 é o mais subestimado e o mais político. Cada script foi instalado por alguém com um motivo, e a conversa sobre remover costuma ser mais difícil que a correção técnica.
Um exemplo hipotético mostra o tamanho do problema. Um site institucional acumula chat, mapa incorporado, dois pixels de anúncio e uma ferramenta de mapa de calor. Cada um parece pequeno isolado, e juntos eles ocupam a thread principal do navegador justamente quando o visitante tenta clicar no botão de contato.
O resultado aparece no INP, não no LCP. A página carrega rápido, parece pronta, e trava por meio segundo no primeiro toque — que é exatamente a experiência que a métrica foi criada para capturar.
Nós da Cloud Market começamos essa análise pelo que o visitante enfrenta e não pela lista de sugestões da ferramenta, porque a lista de laboratório mistura ganho real com ganho irrelevante para o seu público. Um aviso que representa 20 milissegundos de melhoria ocupa a mesma linha de um que representa dois segundos.
Vale a pena perseguir a nota 100?
Não vale, na maioria dos casos. O esforço para sair de 90 para 100 costuma ser maior que o de sair de 40 para 80, e o retorno é muito menor.
A razão é matemática. As primeiras correções resolvem problemas grandes e evidentes; as últimas exigem reescrever comportamento de plugins, remover recursos que a equipe usa e reestruturar o carregamento da página inteira.
Vale considerar o custo do que se perde no caminho:
- Remover um chat pode melhorar o INP e reduzir contato de cliente.
- Adiar o carregamento de imagens demais pode piorar a percepção de qualidade.
- Simplificar o layout pode melhorar o CLS e enfraquecer a conversão.
O critério prático é passar nos três Core Web Vitals com margem e parar. Página que passa com folga já capturou o benefício disponível, e o esforço seguinte rende mais aplicado em conteúdo ou em trabalho de otimização para o Google.
Velocidade importa para a busca com IA?
Importa por um caminho indireto e pouco comentado: rastreamento. Sistemas que geram respostas só usam páginas que conseguiram acessar, ler e processar.
Site lento consome mais tempo de rastreamento por página, o que reduz quantas páginas são visitadas em cada passagem do robô. Em site pequeno isso raramente pesa; em site grande, atrasa a descoberta de conteúdo novo e a reavaliação do conteúdo atualizado.
O que não muda: velocidade não faz uma página ser citada. A citação depende de responder bem, ter autoridade e trazer informação própria, assunto que tratamos em o que mudou na busca com IA.
A leitura correta é de pré-requisito, não de vantagem. Uma página inacessível ou lenta demais fica fora da disputa; uma página rápida apenas entra nela como todas as outras.
Quais erros aparecem no trabalho de velocidade?
Os erros vêm de tratar a nota como objetivo. Cada um tem correção conhecida.
- Otimizar pela nota de laboratório. Acontece porque é o número visível; a consequência é corrigir o que não afeta usuário real. A correção é priorizar pelos dados de campo.
- Testar sempre a página inicial. Acontece por hábito; a consequência é ignorar as páginas que recebem tráfego de busca. A correção é medir as páginas de entrada reais.
- Instalar plugin de cache e considerar resolvido. Acontece pela promessa de solução única; a consequência é mascarar problema de servidor ou de imagem. A correção é medir antes e depois.
- Comprimir imagem sem trocar o formato. Acontece por falta de ferramenta; a consequência é ganho pequeno com perda de qualidade. A correção é converter para formato moderno e redimensionar.
- Medir uma única vez. Acontece na pressa de fechar a tarefa; a consequência é confundir variação normal com melhoria. A correção é acompanhar por semanas.
O segundo erro é o mais comum em relatório de agência. A home costuma ser a página mais leve do site, e a página de serviço que realmente recebe busca fica sem medição.
Perguntas frequentes sobre o PageSpeed Insights
Por que meu site tem notas diferentes a cada teste?
Porque a simulação de laboratório depende de condições que variam a cada execução, como carga do servidor no momento e infraestrutura de teste. Variação de alguns pontos é normal e não indica mudança real. Os dados de campo são estáveis justamente por serem uma média de 28 dias.
Por que não aparecem dados de usuários reais na minha página?
Porque ela não teve tráfego suficiente no período para formar uma amostra confiável. Nesse caso, use os dados de origem do site inteiro quando disponíveis e trate a simulação como diagnóstico, sem concluir que a experiência real é boa ou ruim.
Qual a diferença entre PageSpeed Insights e Search Console?
O PageSpeed Insights analisa uma URL por vez e mostra o que corrigir. O relatório de experiência do Search Console mostra o site inteiro, agrupando URLs com o mesmo problema. Use o Search Console para descobrir a escala e o PageSpeed para investigar cada caso.
Trocar de hospedagem melhora os Core Web Vitals?
Melhora quando o problema é tempo de resposta do servidor, que afeta o LCP diretamente. Não resolve nada quando a causa é imagem pesada, script de terceiro ou layout instável, que são a maioria dos casos em sites institucionais.
Site rápido garante mais conversão?
Não garante, mas remove um obstáculo conhecido. Lentidão faz visitante desistir antes de ver a oferta; velocidade apenas permite que ele chegue. O que converte continua sendo a clareza da proposta e a facilidade do contato.
Preciso corrigir o CLS se meu layout parece estável?
Vale conferir nos dados de campo antes de concluir. O CLS aparece com frequência em celular e em conexões lentas, situações em que fontes e imagens carregam fora de ordem, e o problema costuma passar despercebido em teste feito no desktop do escritório.
Como usar o PageSpeed sem perder tempo
O Google PageSpeed é uma ferramenta de diagnóstico excelente e uma meta péssima. O uso correto começa pelos dados de usuários reais, passa pela lista de oportunidades para localizar a causa e para quando as três métricas entram na faixa boa.
O critério para decidir quanto investir é o tipo de página. Página que recebe tráfego de busca e converte merece atenção contínua. Página institucional secundária pode passar com um ajuste de imagem e não voltar ao assunto.
O que não muda é a ordem de prioridade geral: velocidade resolve obstáculo, conteúdo resolve resultado. Site rápido com material genérico continua invisível.
Se quiser uma leitura das suas páginas de entrada com os dados reais dos seus visitantes, veja como conduzimos o trabalho contínuo de otimização e fale com um especialista.
