Pontos-chave
- Para resolver um site lento, primeiro meça com dados de usuários reais (PageSpeed Insights e Search Console) e só depois mexa no site.
- Cada sintoma aponta para uma causa: demora para aparecer qualquer coisa costuma ser servidor; imagem principal lenta, peso de mídia; página que pula, elementos sem espaço reservado; clique que demora a responder, JavaScript.
- Os limites de Core Web Vitals considerados bons são LCP de até 2,5 s, INP de até 200 ms e CLS de até 0,1, no percentil 75 das visitas.
- No WordPress, os suspeitos de sempre são construtor visual pesado, excesso de plugins, scripts de terceiros e falta de cache.
- O Google usa Core Web Vitals nos sistemas de ranking, mas bons números sozinhos não garantem posição.
Para resolver um site lento, comece medindo com dados de usuários reais, identifique qual dos sintomas aparece (demora para começar, imagem principal lenta, página que pula ou clique que não responde) e ataque primeiro a causa ligada a esse sintoma. Trocar de hospedagem, instalar plugin de otimização ou refazer o site antes de saber o que pesa é a forma mais cara de não resolver.
Este guia é a triagem que eu faço quando alguém me diz "meu site está lento". A parte teórica das métricas está no guia de Core Web Vitals. Aqui o foco é decidir o que fazer.
Lento para quem? Primeiro, meça do jeito certo
O teste que mais engana é abrir o site no próprio computador. Você tem o site em cache, internet boa e uma máquina rápida. O cliente que chega pelo Google, num celular intermediário, numa rede móvel, vive outra experiência. E o Google, desde que concluiu a indexação com prioridade para dispositivos móveis, usa a versão mobile do site para indexar.
Use duas fontes:
- PageSpeed Insights. Ele mostra dois tipos de dado. Os dados de campo vêm de usuários reais do Chrome e cobrem os últimos 28 dias. Os dados de laboratório vêm de um teste simulado com o Lighthouse, útil para achar a causa, mas que pode não refletir gargalos do mundo real. Se a página não tem visitas suficientes, a ferramenta mostra os dados do site inteiro; se nem isso existe, só o laboratório.
- Relatório de Core Web Vitals do Search Console. Agrupa as páginas por situação e mostra se o problema é de uma página ou de um modelo inteiro (todas as páginas de produto, por exemplo).
Os limites que o Google considera bons, medidos no percentil 75 das visitas, são:
| Métrica | O que mede | Bom |
|---|---|---|
| LCP | Quando o maior elemento visível (geralmente a imagem principal ou o título) aparece | Até 2,5 s |
| INP | Quanto a página demora para responder a cliques e toques | Até 200 ms |
| CLS | Quanto o conteúdo pula de lugar enquanto carrega | Até 0,1 |
O INP substituiu o antigo FID como Core Web Vital em março de 2024. Se você leu um tutorial que fala em FID, ele está desatualizado.
Qual é o sintoma? A causa costuma vir junto
Abra o site no celular, em rede móvel, como se fosse a primeira vez. Observe o que acontece e use a tabela.
| O que você vê | Causa provável | Onde olhar |
|---|---|---|
| Tela branca por um tempo antes de qualquer coisa aparecer | Servidor demorando para responder: hospedagem fraca, falta de cache, banco de dados lento | Tempo de resposta do servidor no PageSpeed (laboratório) |
| O texto aparece, mas a imagem principal demora | Imagem pesada, em formato antigo, ou carregada tarde | Elemento de LCP indicado no PageSpeed |
| O conteúdo pula quando banner, imagem ou fonte carregam | Elementos sem espaço reservado: imagens sem dimensões, avisos de cookies e anúncios que empurram o conteúdo | Diagnóstico de CLS no PageSpeed |
| A página aparece, mas o menu ou o botão demoram a reagir | JavaScript demais: construtor visual, sliders, chat, pixels e widgets de terceiros | Diagnóstico de INP e tempo de execução de scripts |
| Só algumas páginas são lentas | Problema no modelo daquelas páginas (galeria, vídeo incorporado, mapa) | Agrupamento do relatório no Search Console |
A ordem em que eu resolvo
A ordem abaixo prioriza o que costuma dar mais resultado com menos risco. Não é regra fixa: se a medição mostra que o problema é outro, a medição manda.
- A imagem principal. É comum o maior elemento da página ser uma foto enviada direto da câmera ou do banco de imagens, muito maior do que a tela precisa. Redimensionar, comprimir e usar formato moderno costuma ser a correção mais barata que existe. Essa imagem também não deve ser carregada de forma adiada (lazy load), porque é a primeira coisa que a pessoa vê.
- Scripts de terceiros. Chat, pixels de anúncio, mapas, widgets de avaliação, ferramentas de gravação de sessão. Cada um parece leve; juntos, travam a página. Liste todos e pergunte: alguém usa os dados disso? O que ninguém usa, sai.
- Espaço reservado para o que carrega depois. Imagens e vídeos com largura e altura declaradas, banners e avisos que não empurram o conteúdo. Resolve o CLS quase sempre.
- Cache e entrega. Cache de página no servidor, compressão, arquivos estáticos com cache no navegador. Se fizer sentido, uma CDN.
- Tema e plugins. Só depois dos itens anteriores, porque mexer aqui tem mais risco de quebrar algo.
- Hospedagem. Por último, e só se a medição mostrar que o servidor continua lento depois do cache.
Site lento no WordPress: os suspeitos de sempre
O WordPress não é lento por natureza. O que pesa é o que se instala em cima dele. Quando o site é WordPress, olho nesta ordem:
- Construtor visual. Alguns carregam muito código em todas as páginas, mesmo nas que não usam os recursos. Não precisa abandonar o construtor, mas vale conferir se ele tem opções para carregar só o necessário.
- Plugins. O problema não é o número em si, é o que cada um carrega no front-end. Um plugin de formulário que injeta scripts em todas as páginas, quando o formulário está só no contato, é um caso típico.
- Dois plugins fazendo a mesma coisa. Dois de cache, ou um de cache e outro de otimização com funções sobrepostas, podem conflitar e piorar.
- Sliders no topo. Pesam, atrasam a imagem principal e raramente alguém vê o terceiro slide.
- Falta de manutenção. Versão desatualizada do PHP, do tema e dos plugins. Além de desempenho, é segurança.
O guia de WordPress para SEO tem a configuração que eu uso como base. Se a dúvida é se o problema está na plataforma, o artigo Wix ou WordPress compara as duas.
Quanto a velocidade pesa no Google?
Pesa, mas não sozinha. O Google diz que os Core Web Vitals são usados pelos seus sistemas de ranking e, na mesma página, que bons resultados neles não garantem posição no topo. Conteúdo relevante continua decidindo mais.
Na prática, eu trato velocidade como requisito, não como estratégia. Um site lento perde gente antes de o conteúdo ser lido, e isso aparece no contato, não só no ranking. Mas um site rápido com páginas que não respondem à busca continua sem aparecer. Se o seu problema é sumir do Google, comece por meu site não aparece no Google, que cobre as causas mais comuns.
Otimizar ou refazer?
Uma árvore de decisão simples:
- O problema está em imagens, scripts de terceiros e cache? Otimize. Costuma ser trabalho de dias, não de meses.
- O problema está no tema ou no construtor, e cada correção quebra outra coisa? Considere refazer o modelo das páginas, mantendo as URLs.
- O site é antigo, lento, difícil de editar e não traz contato? Aí refazer pode sair mais barato do que remendar, e as decisões de um site novo estão em criar um site para empresa. Mas planeje a migração: trocar o site sem redirecionar as URLs antigas troca um problema de velocidade por um problema de indexação.
Velocidade também tem custo recorrente: hospedagem adequada, atualizações, revisão de plugins. O artigo quanto custa manter um site ajuda a colocar isso no orçamento.
Se você mediu, seguiu a ordem e o site continua lento, ou se cada correção quebra algo, é o momento de uma auditoria técnica. É o que faço no serviço de SEO técnico, começando pela medição de campo, não pela opinião.
Este artigo faz parte de Desempenho, migração e bastidores. A base conceitual está nos guias: Core Web Vitals, Migração de site sem perder posições.
Perguntas frequentes
Meu site é rápido no meu computador. Por que dizem que é lento?
Porque o seu computador provavelmente tem o site em cache, internet boa e processador rápido. Quem acessa pela primeira vez, num celular intermediário e numa rede móvel, vê outra coisa. Por isso os dados de campo do PageSpeed Insights, que vêm de usuários reais do Chrome, contam mais do que o seu teste.
Trocar de hospedagem resolve site lento?
Resolve quando o problema é o servidor, o que aparece como demora até a página começar a carregar. Se o peso está em imagens, scripts ou no tema, a hospedagem nova recebe o mesmo problema. Meça antes de trocar.
Plugin de cache resolve tudo no WordPress?
Ajuda bastante na parte do servidor, porque evita montar a página a cada visita. Não resolve imagem pesada, script de terceiro nem construtor visual que carrega código demais. E dois plugins de otimização fazendo a mesma coisa podem piorar.
Por que o PageSpeed Insights não mostra dados de usuários do meu site?
Porque o site ou a página ainda não tem visitas suficientes de usuários do Chrome no período medido. Nesse caso, a ferramenta tenta mostrar dados do site inteiro e, se também não houver, mostra só o teste de laboratório.
Fontes
- web.dev — Web Vitals (acesso em 09/10/2026)
- web.dev — INP becomes a Core Web Vital (12/03/2024) (acesso em 09/10/2026)
- Google for Developers — Sobre o PageSpeed Insights (acesso em 09/10/2026)
- web.dev — The most effective ways to improve Core Web Vitals (acesso em 09/10/2026)
- Google Search Central — Experiência na página nos resultados da Pesquisa Google (acesso em 09/10/2026)
- Google Search Central — Indexação com prioridade para dispositivos móveis (acesso em 09/10/2026)
Estrategista sênior de SEO e GEO em São Paulo, praticando SEO desde 2012. Atende o projeto de SEO e GEO do Sem Parar (Grupo Corpay). Sobre mim
Conte o que você precisa e eu digo, sem compromisso, qual caminho faz sentido: 48 horas, 1 semana ou WordPress.
Falar no WhatsApp