WordPress lento: como achar a causa e quando é a hospedagem

Um WordPress lento quase sempre vem de uma entre quatro origens: o servidor, a falta de cache, plugins e tema pesados ou imagens grandes demais. Para separar uma da outra, meça o TTFB, o tempo até o primeiro byte. Se ele é alto mesmo com cache, a causa está no servidor ou no PHP. Se é baixo e a página ainda demora, o peso está no que o navegador carrega.

Em vez de uma lista de dicas soltas, o texto traz um teste de três camadas que qualquer pessoa repete com o curl, uma tabela que liga cada resultado à causa provável e a ordem de correção do que rende mais para o que rende menos. Os números do exemplo vêm do próprio site da PW Host, lido em 15/10/2026. Se o seu site está fora do ar e não só lento, comece pelo roteiro de site fora do ar.

Quais números dizem que o WordPress está lento?

“Lento” precisa de número, senão cada pessoa mede de um jeito. O Google define três Core Web Vitals para a experiência do visitante, avaliados no 75º percentil dos acessos: o LCP, que mede o carregamento do maior elemento da página, o INP, que mede a resposta aos cliques, e o CLS, que mede o quanto o layout se mexe. O TTFB não é um deles, mas é o primeiro número a olhar, porque tudo o que vem depois espera por ele.

Métrica	O que mede	Limite para “bom”	Costuma indicar (leitura da equipe)
TTFB	Tempo até o primeiro byte da resposta	Até 0,8 s (ruim: acima de 1,8 s)	Servidor, cache, PHP, banco de dados
LCP	Carregamento do maior elemento visível	Até 2,5 s	Imagem grande, CSS e JavaScript que travam, TTFB alto
INP	Resposta às interações	Até 200 ms	JavaScript pesado, muitos plugins no navegador
CLS	Estabilidade do layout	Até 0,1	Imagens sem tamanho definido, fontes e anúncios que carregam tarde

O PageSpeed Insights mostra dois tipos de dado. Os de campo vêm de usuários reais do Chrome nos 28 dias anteriores. Os de laboratório vêm de uma simulação do Lighthouse, num celular intermediário em rede móvel, e servem para diagnóstico. Um site novo ou com pouco tráfego pode não ter dados de campo, e então só o laboratório responde. Por isso o teste a seguir não depende dele.

Como separar servidor, WordPress e página em 5 minutos?

A ideia é pedir três coisas diferentes ao mesmo servidor e comparar o tempo até o primeiro byte. No terminal, o comando é curl -o /dev/null -s -w "%{time_starttransfer}" ENDEREÇO (no Windows, troque /dev/null por NUL). Faça 3 leituras de cada e fique com a do meio, porque a primeira costuma ser a pior.

1. Um arquivo estático, como /wp-includes/js/jquery/jquery.min.js. Ele não executa PHP, então mede a rede e o servidor web.
2. O WordPress carregado, sem montar uma página, como /wp-json/. Mede o quanto custa iniciar o WordPress com todos os plugins.
3. A página inicial sem cache, acrescentando um parâmetro novo ao endereço, como /?teste=123. Mede a página completa, com tema, construtor e consultas.
4. A página inicial com cache, sem parâmetro. Mede o que o visitante comum recebe.

Fizemos isso no site da PW Host em 15/10/2026, entre 00:39 e 00:47, a partir do computador da equipe, com User-Agent próprio e intervalo de 2 segundos. O resultado:

Camada testada	Leituras (TTFB)	Mediana	Faixa do web.dev
Arquivo estático	0,096 s, 0,094 s e 0,186 s	0,096 s	Bom
WordPress carregado (/wp-json/)	1,422 s, 1,116 s e 1,118 s	1,118 s	Precisa melhorar
Página sem cache	7,302 s, 1,527 s, 1,583 s, 1,720 s e 1,594 s	1,594 s	Precisa melhorar (uma leitura em faixa ruim)
Página com cache	0,141 s, 0,104 s e 0,092 s	0,104 s	Bom

O desenho é típico de um WordPress com muitos plugins. A rede e o servidor web respondem em cerca de 0,1 s. Iniciar o WordPress custa mais de 1 s. Montar a página completa acrescenta por volta de meio segundo. E o cache devolve tudo a 0,1 s. A conclusão é prática: neste site, o gargalo não é a distância nem o servidor web, e sim o PHP carregando tudo a cada visita sem cache.

O que o resultado diz sobre a causa?

Se você vê	A causa provável é	Comece por
O arquivo estático já passa de 0,8 s	Rede ou servidor web lentos, ou conta no limite	Repetir em outro horário e outra rede; olhar o Uso de Recursos; falar com a hospedagem
Estático bom, WordPress (/wp-json/) acima de 0,8 s	PHP antigo, plugins pesados, banco lento	Versão do PHP, desativar plugins um a um, cache de objetos
WordPress bom, página sem cache muito mais lenta	Tema, construtor de páginas ou consultas da página	Menos blocos e widgets, imagens menores, cache de página
Página com cache também acima de 0,8 s	Cache desligado, não funcionando ou servidor sobrecarregado	Conferir o cabeçalho de cache; se estiver em hit, suspeite do servidor
TTFB bom e página ainda demora	Peso no navegador: imagens, CSS, JavaScript, fontes	PageSpeed, imagens em WebP, menos scripts

O que mudar primeiro, em ordem de ganho?

1. Ligue o cache de página. Foi o maior ganho do nosso teste: de 1,594 s para 0,104 s de mediana. Segundo a documentação do plugin LiteSpeed Cache, uma página em cache permite que o servidor passe por cima do PHP e do banco de dados. Os recursos exclusivos do plugin exigem um servidor LiteSpeed. O passo a passo está em LiteSpeed Cache no WordPress. Confira o cabeçalho x-litespeed-cache: hit e use só um plugin de cache.
2. Use um PHP atual. O WordPress.org pede PHP 8.3 ou superior (página atualizada em 07/05/2026). Pelo calendário do php.net, em 15/10/2026 o PHP 8.2 só recebe correções de segurança e deixa de receber qualquer atualização em 31/12/2026, e o 8.3 recebe só correções de segurança até 31/12/2027. Escolha a versão mais nova que o seu tema e os seus plugins aceitem, depois de um backup, e confira o site.
3. Enxugue plugins e tema. Desative e apague o que não usa e evite dois plugins para a mesma função. Para achar o culpado, desative um por vez e meça de novo. O plugin Query Monitor, que tem mais de 200 mil instalações ativas, mostra consultas lentas ao banco e o plugin ou tema responsável por elas.
4. Reduza as imagens. O MDN informa que imagens WebP com perda são, em média, 25% a 35% menores que JPEG de qualidade visual parecida. Comprima antes de enviar e use as dimensões que a página realmente mostra.
5. Ligue o cache de objetos, se o painel do WordPress é o lento. O Redis guarda na memória o resultado de consultas ao banco. O ganho é maior em sites com muitos plugins ou com loja, e pequeno num site simples que já tem cache de página. O caminho na PW Host está em Ativar o Redis.
6. Considere uma CDN. Ela serve imagens e arquivos estáticos de servidores perto do visitante. Ajuda quando o público está longe do servidor e não resolve um PHP lento.

O tutorial Site lento: diagnóstico básico traz o mesmo roteiro no painel da PW Host. Mude uma coisa por vez e meça de novo, para saber o que funcionou.

O Elementor deixa o WordPress lento?

Um construtor de páginas acrescenta HTML, CSS e JavaScript a cada página, e isso aparece na linha “página sem cache” do teste, não na do WordPress carregado. Não é motivo para trocar de ferramenta sem medir. O Elementor informa que, a partir da versão 3.19, as melhorias que reduzem os elementos extras do HTML passaram a fazer parte do núcleo e deixaram de ser opcionais (página de ajuda atualizada em 01/02/2024), então manter o Elementor atualizado já ajuda. O resto é disciplina de página: menos seções e widgets empilhados, imagens do tamanho certo, cache ligado e poucos plugins complementares.

O painel do WordPress está lento e o site abre rápido: o que é?

O cache de página não vale para o painel, porque o wp-admin sempre executa o PHP. Quando só ele é lento, as causas mais comuns são plugins que fazem muita coisa ao carregar, um banco de dados com consultas pesadas e a falta de cache de objetos. O Query Monitor ajuda a ver quais consultas demoram, e o Redis costuma ajudar. Se o painel fica lento junto com erros 503 ou 508 nos picos, o problema pode ser o limite de recursos da conta, e o Uso de Recursos do painel mostra isso.

Quando a culpa é da hospedagem?

Quando o teste de três camadas aponta para o servidor e a correção do lado do site não resolve. Os sinais, por ordem de força:

• O arquivo estático, que não executa PHP, passa de 0,8 s em várias leituras e horários.
• A página com cache em hit continua acima de 0,8 s, ou o TTFB varia muito sem que você mude nada.
• O Uso de Recursos mostra o site limitado nos mesmos horários mesmo depois de ligar o cache e enxugar o site.
• Outros sites seus na mesma hospedagem estão igualmente lentos.

Antes de culpar o servidor, vale lembrar que o tempo sem cache também depende do seu site: o nosso, com muitos plugins, ficou na faixa “precisa melhorar” sem cache e em 0,1 s com cache. Na avaliação de 30/09/2026, o WordPress da PW Host levou de 0,6 a 2,3 s sem cache. Ou seja, o cache não é opcional num site cheio de plugins.

Se mesmo assim a hospedagem é o limite, admita: um site com muito tráfego logado ou uma loja com muitos pedidos ao mesmo tempo pode precisar de VPS ou cloud, e o cache ajuda pouco em páginas que mudam para cada visitante. O roteiro de como trocar de hospedagem mostra como mudar sem tirar o site do ar, e o guia de como escolher hospedagem de site lista o que comparar. Se o site ainda está em construção, o passo a passo de como criar um site no WordPress já inclui a escolha da hospedagem.

E na PW Host, como fica?

A PW Host é hospedagem compartilhada, com servidores LiteSpeed e SSD em São Paulo, e o plugin LiteSpeed Cache é o caminho para o cache de página. O Redis pode ser ativado no painel, e a versão do PHP é escolhida por domínio no próprio painel. Cada conta tem limites técnicos, como até 5 núcleos de CPU e 3 GB de RAM, que protegem os outros clientes (Termos de Uso, item 6.2). Quando a conta chega a um limite, o site pode ficar lento ou mostrar erros temporários.

O suporte atende servidor, painel, DNS, SSL, e-mail e acesso. Ele não otimiza nem conserta o seu site: escolher plugins, ligar o cache e manter o WordPress atualizado é tarefa do cliente (itens 8 e 10 dos Termos). O domínio, a migração e a criação do site não estão incluídos, e o pagamento é único, sem mensalidade de hospedagem. Quem quer conhecer o plano pode ver a hospedagem com LiteSpeed e pagamento único, e o texto completo em Termos e Políticas.

Perguntas frequentes

Fontes

• web.dev, Time to First Byte (TTFB): limites de bom e ruim e o que entra na medida (atualizada em novembro de 2025).
• web.dev, Web Vitals: LCP, INP e CLS e o 75º percentil (atualizada em 31/10/2024).
• Google, PageSpeed Insights: dados de campo e de laboratório (atualizada em 21/10/2024).
• WordPress.org, LiteSpeed Cache e Query Monitor (consultados em 15/10/2026).
• WordPress.org, Requirements: PHP 8.3 ou superior (modificada em 07/05/2026) e php.net, Supported Versions (consultado em 15/10/2026).
• MDN, Image file type and format guide: WebP (modificada em 08/10/2026).
• Elementor, Optimized DOM Output and custom code (atualizada em 01/02/2024).
• PW Host, Termos e Políticas, versão 1.1 (Termos de Uso, itens 6.2, 8 e 10).

Texto da Equipe PW Host, escrito com apoio de IA e revisado pela equipe. As medições são da equipe e valem para 15/10/2026. Preços, versões e regras conferidos em 15/10/2026 nas páginas oficiais, que podem mudar sem aviso.