“Meu site está lento” quase sempre vem de uma impressão: o dono abriu no celular, no 4G, na fila do banco, e ficou olhando a tela branca. No wi-fi da loja, depois, abriu rápido.
Impressão não serve para decidir se vale gastar dinheiro com isso. O Google oferece uma ferramenta gratuita para medir, só que ela devolve uma nota de 0 a 100, meia dúzia de siglas e uma lista de avisos em vermelho que assusta quem não é da área.
O que vimos em 89 sites de uma avenida
Quando testamos os sites das empresas da Avenida Lédio João Martins, em São José, medimos o tempo que o servidor de cada um levava para entregar a página: 42 responderam em menos de 1 segundo, 34 levaram de 1 a 3 segundos e 13 passaram de 3.
Voltamos a esses números para ver o que os lentos tinham em comum. O primeiro palpite, página pesada, não se confirmou. O código da página inicial tem mediana de 141 KB, e o grupo mais pesado (25 sites acima de 300 KB) respondeu mais rápido que o grupo do meio. O que separou os sites foi outra coisa:
| Tempo de resposta | WordPress (32 sites) | Outros (57 sites) |
|---|---|---|
| Menos de 1 segundo | 6 | 36 |
| De 1 a 3 segundos | 18 | 16 |
| Mais de 3 segundos | 8 | 5 |
| Mediana | 1,8 s | 0,8 s |
Oito dos 13 sites mais lentos são WordPress. Antes de culpar a ferramenta, olhe a primeira linha: seis sites em WordPress responderam em menos de um segundo, com o mesmo sistema. Muda onde ele está hospedado e quanta coisa foi instalada em cima. Na outra coluna estão as plataformas de loja e os sites de rede, que têm estrutura maior por trás, o que provavelmente ajuda a puxar a mediana para baixo.
A ressalva: foi uma medição só por site, em banda larga, em 4 de outubro de 2026. Serve para comparar grupos e não como laudo de nenhum deles.
Como medir o seu
Abra pagespeed.web.dev, cole o endereço do site e toque em Analisar. Fique na aba de celular, que é de onde vem o seu cliente.
A tela tem duas partes, e misturar as duas é o erro mais comum. A documentação do PageSpeed Insights explica a diferença.
A de cima mostra a experiência de pessoas reais que abriram o site pelo Chrome nos últimos 28 dias. É o dado que vale. Em site de pequeno negócio, muitas vezes essa parte vem vazia, porque não houve visitas suficientes para o Google montar a estatística.
A de baixo é um teste de laboratório, feito na hora. O Google simula um celular intermediário (um Moto G4) em rede móvel, de propósito mais fraco que o aparelho do dono. Por isso a nota costuma ser pior do que a sensação de quem abre o site no próprio telefone. É dessa parte que sai a nota de 0 a 100.
Rode o teste três vezes. O resultado muda de uma para outra, e a documentação do Lighthouse, o motor por trás da nota, lista as causas: variação na rota da internet, anúncios que mudam a cada carga, testes A/B. Diferença de cinco pontos entre duas rodadas não quer dizer nada.
O que cada número significa
| Sigla | Em português claro | Limite bom |
|---|---|---|
| LCP | Quando o maior elemento da tela aparece | Até 2,5 s |
| INP | Demora entre o toque e a reação | Até 200 ms |
| CLS | Quanto a página pula enquanto carrega | Até 0,1 |
| FCP | Quando surge a primeira coisa na tela | Até 1,8 s |
| TTFB | Quanto o servidor demora a responder | Até 0,8 s |
Os três primeiros são o que o Google chama de Core Web Vitals, as métricas principais. Um site passa quando fica dentro do limite em três de cada quatro visitas.
O LCP é o que o cliente sente como “abriu”. Em site de comércio, o maior elemento costuma ser a foto ou o banner do topo. Acima de 4 segundos o Google classifica como ruim.
O INP mede o engasgo: a pessoa toca no menu e nada acontece por meio segundo. Aparece em site com muito recurso rodando ao mesmo tempo.
O CLS é aquele momento em que você vai tocar no botão do WhatsApp, um banner termina de carregar, empurra tudo para baixo e o dedo acerta outra coisa.
O TTFB é o mesmo tipo de medida que fizemos na avenida. O Google trata como métrica auxiliar: não faz parte das principais, mas tudo o que vem depois começa a contar a partir dele. Pela régua oficial de 0,8 segundo, 32 dos 89 sites que medimos ficariam dentro do limite, e 26 passariam de 1,8 segundo, a faixa ruim. A comparação é aproximada, porque o Google aplica esse limite à experiência de usuários reais e nós fizemos uma medição só.
Nota 100 não é o objetivo
A faixa verde vai de 90 a 100, a laranja de 50 a 89 e a vermelha fica abaixo de 50. A documentação do Lighthouse diz, com estas palavras, que a pontuação perfeita de 100 “é extremamente difícil de alcançar e não é esperada”, e que subir de 99 para 100 custa o mesmo esforço que ir de 90 para 94.
Na prática, um site de pequeno negócio com as três métricas principais no verde está resolvido, tenha nota 78 ou 96. Desconfie de proposta que promete “nota 100 no Google”. Uma página de nota 70 com o botão do WhatsApp à vista atende melhor o cliente do que uma de nota 98 em que ele precisa caçar o telefone.
As causas mais comuns e quem resolve
As causas abaixo são as que mais encontramos em site de comércio local. As recomendações citadas vêm do guia do Google para o LCP.
Imagem enorme. A foto vai do celular direto para o site, com vários megabytes, para ser exibida em uma faixa de 400 pixels de largura. A recomendação oficial é servir a imagem no tamanho em que ela aparece, comprimida e em formato moderno, como WebP ou AVIF. O dono consegue fazer: reduzir a foto antes de enviar já resolve boa parte.
Hospedagem fraca. É o que o TTFB denuncia. Plano compartilhado barato divide a mesma máquina com muitos outros sites e pode responder devagar. O dono resolve com um telefonema para a hospedagem ou trocando de plano. Migrar de empresa já pede alguém técnico.
Excesso de plugins. Muitos plugins de WordPress carregam os próprios arquivos em todas as páginas, inclusive onde não são usados. O Google explica que folhas de estilo e scripts colocados no começo da página seguram a exibição de tudo o que vem depois. O dono pode desativar o que não usa, um por vez e com cópia de segurança feita. O que sobra, quem montou o site ajusta.
Vídeo de fundo. Pesa muito no 4G do cliente. Trocar por uma foto boa é decisão do dono e não depende de mais ninguém.
Fontes e scripts de terceiros. Chat, mapa embutido, pixel de anúncio de uma campanha que acabou há dois anos, três famílias de fonte. Cada um é uma conexão a mais com outro servidor. O dono decide o que sai, e a remoção em si costuma ser de quem tem acesso ao código.
| Problema | Dono resolve | Precisa de quem fez |
|---|---|---|
| Fotos pesadas | Reduzir e reenviar | Conversão automática |
| Servidor lento | Mudar de plano | Migrar e ativar cache |
| Plugins demais | Desativar os sem uso | Ajustar o carregamento |
| Vídeo de fundo | Trocar por foto | Nada |
| Scripts de terceiros | Decidir o que sai | Remover do código |
Quando não vale mexer
Se as métricas principais estão no verde ou perto disso, pare. O tempo rende mais em outro lugar: no texto da página, nas fotos, no perfil do Google.
Se o site recebe poucas dezenas de visitas por mês, o problema maior é outro. Antes de pagar por otimização, vale entender por que ele não aparece nas buscas.
E se a lista de problemas for longa em um site antigo, some o custo dos remendos antes de autorizar. Há casos em que trocar a hospedagem e três fotos devolve um site rápido, e há casos em que o tema está tão carregado que cada ajuste quebra outra coisa. Peça a quem for mexer que diga, antes de começar, em qual dos dois o seu se encaixa.
