Antes de trocar a hospedagem, instalar plugin de cache ou refazer o tema, meça. Sem o número de antes, não dá para saber se a mudança ajudou, e é fácil gastar dinheiro na correção errada. Rode o PageSpeed Insights em três páginas que importam (a home, uma página de serviço ou produto e o contato), sempre no celular, e anote os dados de campo e de laboratório. Como ler cada número está em Core Web Vitals: o que são e como saber se o seu site passa.
Um teste simples ajuda a separar as causas. Se o painel do WordPress também está lento para salvar um post, o problema provavelmente está no servidor, no banco de dados ou num plugin pesado. Se só as páginas públicas estão lentas, olhe primeiro para cache, imagens e scripts.
A hospedagem e o PHP estão segurando o site?
A hospedagem define o teto de velocidade do WordPress. A documentação oficial de desempenho lembra que o que dá para fazer depende do tipo de plano (compartilhado, gerenciado, VPS ou dedicado) e que mais CPU, memória e disco SSD ou NVMe ajudam. Confira três pontos com o seu provedor:
- Versão do PHP. O WordPress recomenda PHP 8.3 ou superior. Versões novas tendem a ser mais rápidas, e o PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026.
- Banco de dados. A recomendação é MariaDB 10.11 ou MySQL 8.0 em diante.
- OPcache ativo. É o acelerador do PHP que a própria documentação indica.
- Onde fica o servidor. Para um público brasileiro, servidor no Brasil, ou uma CDN com pontos no país, encurta a distância entre o visitante e o site.
Num plano compartilhado lotado, as otimizações internas ajudam, mas esbarram no limite do plano.
O site tem cache de verdade?
Cache é guardar pronto o que não muda a cada visita. A documentação do WordPress fala em três camadas:
- Cache de página: salva a página como arquivo estático e poupa o servidor de montar tudo de novo. Em páginas que mudam pouco, é o maior ganho de todos.
- Cache de objetos persistente: reduz as consultas ao banco de dados. Depende de um servidor de cache oferecido pela hospedagem e de um plugin compatível.
- Cache do navegador: cabeçalhos que pedem ao navegador do visitante para guardar imagens, CSS e JavaScript por um tempo.
Em loja WooCommerce, as páginas de carrinho, checkout e minha conta ficam fora do cache de página, porque mostram dados de cada cliente; a documentação do WooCommerce é explícita nisso. Uma CDN, rede que entrega os arquivos a partir de servidores mais perto do visitante, completa o conjunto.
Quantos plugins são demais?
O número importa menos que o peso de cada um. Um plugin bem escrito quase não pesa; um único plugin mal feito de formulário, slider ou estatística pode carregar scripts em todas as páginas. A documentação recomenda desativar e remover o que não é necessário e testar a desativação um a um para achar quem mais pesa.
Faça esse teste numa cópia do site, nunca no site no ar. E apague, em vez de só desativar, o que não vai voltar a usar: plugin parado também é risco de segurança.
Construtores visuais de página, como Elementor e Divi, merecem atenção à parte. Eles facilitam a edição, mas carregam scripts e estilos que pesam nas Core Web Vitals. Por isso, nos projetos da Buzz, o padrão é um tema próprio e enxuto.
Imagens e scripts de terceiros: onde o peso se esconde?
- Imagens enviadas direto da câmera ou do banco de imagens, com vários megabytes. Redimensione para o tamanho em que aparecem, comprima e prefira WebP, formato que a documentação do WordPress cita como tendendo a ser menor.
- Imagens abaixo da primeira tela carregando todas de uma vez. Elas podem esperar o visitante rolar a página; a foto principal do topo, não.
- Vídeo incorporado no topo, que baixa o player inteiro antes de o visitante decidir assistir.
- Scripts de terceiros: chat, pixels de anúncio, mapas, avaliações, botões sociais. Liste todos, descubra quem usa cada um e carregue só nas páginas que precisam.
- Fontes em muitos pesos e estilos. Duas famílias com poucos pesos costumam bastar.
O que pedir a quem vai mexer no site?
Otimização sem registro vira palpite. Antes de liberar o trabalho, combine com o desenvolvedor quatro entregas:
- Backup completo antes de começar, com a data anotada.
- Os testes de antes: PageSpeed Insights das mesmas três páginas, no celular, salvos em PDF ou imagem.
- A lista do que foi mudado, item por item: plugin removido, imagem trocada, configuração de cache, versão de PHP.
- Os testes de depois, nas mesmas páginas e condições, e uma nova leitura dos dados de campo quatro semanas mais tarde.
Com isso em mãos, você sabe o que comprou e tem um mapa para a próxima revisão.
Em que ordem corrigir o WordPress lento?
Comece pelo que dá mais resultado com menos risco e deixe a reconstrução para o fim:
| Ordem | Correção | Esforço | Risco de quebrar algo |
|---|---|---|---|
| 1 | Cache de página e do navegador configurados | Baixo | Baixo, com carrinho e checkout fora do cache |
| 2 | Imagens redimensionadas e comprimidas | Baixo a médio | Baixo |
| 3 | Plugins e scripts de terceiros revisados | Médio | Médio; teste numa cópia |
| 4 | PHP atualizado e hospedagem adequada | Médio | Médio; teste a compatibilidade |
| 5 | Tema refeito sem construtor pesado | Alto | Planejado como projeto |
Meça de novo depois de cada etapa, com os mesmos testes do início. Assim você sabe o que funcionou e onde vale pôr o próximo real.
Quando a lentidão vem do tema ou de anos de remendos, a saída é um projeto de desenvolvimento WordPress com tema próprio. Para ajustes pontuais, dá para contratar um programador WordPress da nossa equipe.