WordPress lento: como encontrar a causa e corrigir

O que é WordPress: como funciona, para que serve e quando usar

O que é um WordPress lento e por que ele fica assim

Lentidão no WordPress é a soma de atrasos em duas etapas. Na primeira, o servidor executa PHP, consulta o banco de dados e gera o HTML. Na segunda, o navegador baixa esse HTML, busca CSS, JavaScript, fontes e imagens e desenha a página. Quem ainda está entendendo como núcleo, tema e plugins se encaixam encontra a base no guia sobre o que é WordPress.

Sem cache, cada visita repete o trabalho completo da primeira etapa, e cada plugin ativo pode acrescentar consultas, chamadas externas e arquivos à página. O mesmo site pode abrir rápido no computador do escritório e demorar no celular de quem chega a uma página que ninguém visitou nas últimas horas. Para lentidão em sites de qualquer plataforma, o conteúdo sobre site lento trata das causas gerais.

O WordPress está em 40,0% de todos os sites e em 58,5% dos sites cujo gerenciador de conteúdo é identificado, segundo a W3Techs ↗^[1] em 14/10/2026. Com uma base instalada desse tamanho, as causas de lentidão se repetem de um site para outro, o que permite diagnosticá-las com método.

Quanto a lentidão pesa no negócio

A lentidão aparece no negócio em três pontos: o visitante que desiste antes de a página carregar, a equipe que perde tempo no painel e as métricas de experiência que o Google usa para avaliar páginas. Um exemplo ilustrativo: num site em WordPress institucional, o formulário de contato fica no fim de uma página que leva segundos para responder no celular, e parte de quem chega por anúncio sai antes de vê-lo.

Há estudo público sobre esse efeito em sites grandes. No relatório “Milliseconds Make Millions”, encomendado pelo Google à Deloitte e à agência 55, com dados de 37 marcas europeias e americanas e mais de 30 milhões de sessões no fim de 2019, uma melhora de 0,1 segundo na velocidade do site no celular coincidiu com 8,4% mais conversões em varejo e 10,1% em viagens (web.dev ↗^[2], consultado em 14/10/2026). O recorte é de sites grandes, no celular, com 30 dias de medição sem mudança de layout e métricas de carga da época; o resultado mostra correlação e serve como ordem de grandeza para um site WordPress, sem valor de previsão para ele.

Como medir antes de mexer

O PageSpeed Insights mostra dois tipos de dado. O de laboratório vem do Lighthouse, em dispositivo e rede fixos, e serve para depurar. O de campo vem do Chrome UX Report, reúne a experiência de usuários reais nos últimos 28 dias e, com pouco tráfego, cai para o agregado do domínio ou não aparece (documentação do PageSpeed Insights ↗^[3]).

Dois números orientam o diagnóstico:

• TTFB (tempo até o primeiro byte): mede redirecionamentos, DNS, conexão, TLS e o tempo até o servidor começar a responder. O web.dev considera bom até 0,8 segundo e ruim acima de 1,8 segundo (web.dev, TTFB ↗^[4]).
• LCP (maior elemento visível carregado): o alvo é até 2,5 segundos no percentil 75 das visitas, separado entre celular e computador (web.dev, Web Vitals ↗^[5]).

Sintoma, causa provável e correção

Sintoma	Causa provável	Como confirmar	Correção
TTFB alto em todas as páginas	Falta de cache de página, PHP antigo, hospedagem subdimensionada	PageSpeed Insights, Ferramentas > Saúde do site	Cache de página, PHP atualizado, revisão do plano de hospedagem
TTFB alto só em algumas páginas	Consulta pesada de plugin ou do tema	Query Monitor em homologação	Ajustar, substituir ou remover o componente
Painel administrativo lento	Chamadas HTTP externas, opções carregadas em excesso	Query Monitor, WP-CLI	Remover plugin responsável, limpar opções órfãs
TTFB alto com plugin de cache ativo	Cookie na resposta ou na requisição impedindo o cache (Set-Cookie de pixel gravado pelo servidor, cookie da CDN repassado à origem)	Cabeçalho de cache da resposta (HIT ou MISS) em janela anônima	Impedir que o servidor grave o cookie ou remover o cookie antes da origem
Picos de lentidão sem aumento de visitas no Analytics	Tráfego de robôs, que não executam a tag do Google Analytics e geram carga no PHP, ou, em sites com o WP-Cron padrão, tarefas agendadas disparadas pela visita	Log de acesso por user-agent; wp cron event list	Regras de bloqueio ou limite de robôs na CDN ou no servidor; desativar o disparo por visita e agendar o wp-cron.php no cron do servidor, em intervalo fixo
LCP alto com TTFB bom	Imagem principal pesada ou com lazy loading, CSS bloqueante	Diagnóstico de LCP no PageSpeed Insights	WebP, prioridade alta na imagem, CSS enxuto
Página demora a responder ao clique	JavaScript de plugins, construtores visuais e scripts de terceiros	Seção de INP no PageSpeed Insights	Carregar scripts só onde são usados

O que a experiência da Studio Visual mostra

Na Studio Visual, diagnosticar lentidão é uma demanda frequente nos sites WordPress que mantemos, e a causa costuma aparecer na combinação de hospedagem, cache e plugins atuando juntos.

Em março de 2026, o site da Inforchannel, revista B2B de tecnologia em WordPress, operava com o servidor no limite: todos os 30 processos PHP ocupados e páginas sem cache levando de 7 a 12 segundos para serem geradas. O diagnóstico encontrou três causas: 11,8 MB de opções carregadas em toda requisição (a documentação recomenda menos de 800 KB), cerca de 100 avisos de PHP por minuto nos templates e 65% do tráfego vindo de robôs. Depois de mover as opções grandes para fora do autoload, corrigir 25 templates e bloquear os robôs, o autoload caiu para 185 KB, a página sem cache passou a sair em 25 a 38 milissegundos e a carga do servidor caiu de 3,12 para 0,59. A medição foi feita no servidor, sem cache, em 24 e 25/03/2026, e fica fora do dado de campo do Chrome UX Report.

Passo a passo do diagnóstico e da correção

Pré-requisitos: acesso de administrador ao WordPress, acesso ao painel da hospedagem ou ao servidor e uma cópia do site em homologação.

1. Meça home, um post e uma página de conversão no PageSpeed Insights, sem estar logado e no perfil de celular. Anote TTFB e LCP.
2. Com TTFB alto, confira versão do PHP e cache (seção de servidor abaixo).
3. Com TTFB alto só em algumas páginas, rode o Query Monitor em homologação e isole plugin ou tema.
4. Confira opções com autoload e tarefas agendadas pelo WP-CLI.
5. Com TTFB bom e LCP alto, trate imagem principal, CSS e scripts.
6. Aplique uma correção por vez e meça de novo antes da próxima.

Na rotina da equipe, uma tarefa de performance costuma caber em algumas horas de trabalho. Correções que mexem em código seguem um plano aprovado antes de começar.

Servidor, versão do PHP e cache

Com TTFB alto em qualquer página, o gargalo fica antes do navegador. A primeira verificação é a versão do PHP: o WordPress.org recomenda PHP 8.3 ou superior e MySQL 8.0 ou MariaDB 10.11 ou superior (requisitos do WordPress ↗^[6]). A tela Ferramentas > Saúde do site aponta PHP desatualizado entre os itens a corrigir, e o núcleo atualizado (core update) entra na mesma checagem.

A documentação de cache do WordPress ↗^[7] descreve quatro camadas:

1. Cache de página: o plugin ou o servidor entrega a página como arquivo estático para visitantes anônimos. Em sites de conteúdo, é a camada com efeito mais direto no TTFB.
2. Cache de objetos persistente, com Redis ou Memcached: alivia o banco em páginas dinâmicas, como carrinho e área logada. Depois de ativar, confira a taxa de acerto (hit rate) do cache de objetos, porque o servidor de cache pode estar contratado e o WordPress nunca se conectar a ele.
3. Cache de opcode (OPcache): evita que o PHP recompile o código a cada requisição. Fica no servidor, fora do alcance de plugin.
4. Cache de navegador: cabeçalhos Cache-Control e Expires em imagens, CSS e JavaScript.

Hospedagem compartilhada costuma limitar o que se pode configurar nessas camadas. Se o cache de página já funciona e o TTFB continua alto em páginas simples, o plano de hospedagem entra na lista de suspeitos.

Plugins e tema: como achar o que pesa

Um plugin de formulário que carrega scripts em todas as páginas pode custar mais tempo que dez plugins pequenos que só atuam no painel, e só a medição mostra qual é o caso. O Query Monitor ↗^[8] é um plugin de depuração que lista consultas ao banco lentas, duplicadas ou com erro, agrupadas por plugin ou tema, além de chamadas HTTP externas e dos scripts carregados em cada página. Use em homologação ou por tempo curto em produção, restrito a administradores.

Quando nenhum componente se destaca, a desativação controlada resolve: numa cópia do site, desative plugins em blocos, meça o TTFB a cada rodada e isole o responsável. O tema entra no mesmo teste. Construtores visuais como o Elementor acrescentam scripts e estilos próprios à página; quando o tema permite, comparar a mesma página montada com blocos nativos do editor Gutenberg mostra quanto desse peso vem do construtor. A documentação de otimização do WordPress ↗^[9] recomenda desativar e excluir plugins desnecessários.

Banco de dados e tarefas agendadas

O banco de dados acumula revisões de posts, transients expirados e opções deixadas por plugins removidos. O ponto que mais afeta velocidade é a tabela de opções: tudo que está marcado como autoload é carregado em todas as requisições, e a documentação de otimização orienta manter esse volume abaixo de 800 KB. Pelo WP-CLI, wp option list --autoload=on --fields=option_name,size_bytes --orderby=size_bytes --order=desc lista as opções maiores, e wp transient delete --expired remove transients vencidos (referência do WP-CLI ↗^[10]).

O WP-Cron é o agendador interno do WordPress e verifica a lista de tarefas a cada carregamento de página (manual de plugins, WP-Cron ↗^[11]). Em loja WooCommerce ou site com importações e sincronizações, um visitante pode pagar o tempo dessa execução, e wp cron event list mostra o que está agendado. A correção documentada é adicionar define( 'DISABLE_WP_CRON', true ); ao wp-config.php e agendar uma chamada periódica a wp-cron.php pelo cron do servidor. A gente adota essa prática nos sites que mantém em hospedagem gerenciada, e a tarefa agendada sai da página de quem está navegando.

Imagem principal, CSS e scripts

Se o TTFB está bom e o LCP continua alto, o atraso vem do front-end. O web.dev divide o LCP em TTFB, atraso até começar a baixar o recurso, tempo de download e atraso de renderização (web.dev, otimizar LCP ↗^[12]):

• Atraso para começar o download: a imagem principal não pode ter lazy loading. Marque-a com fetchpriority="high" e, se ela vier de CSS, faça preload.
• Download lento: imagem em WebP, dimensionada para o espaço que ocupa, com cache de navegador ou CDN. Peso total da página e Core Web Vitals são métricas diferentes: trocar um vídeo de topo por uma imagem estática pesada pode piorar o LCP, então meça o LCP depois de cada troca no elemento principal.
• Atraso de renderização: CSS e JavaScript bloqueantes. Reduza folhas de estilo e adie scripts que não participam do primeiro desenho.

Scripts de terceiros (chat, mapas, pixels, vídeos incorporados) acrescentam requisições e trabalho de JavaScript e costumam explicar uma página que responde devagar ao toque.

Erros comuns ao tentar resolver

• Empilhar plugins de otimização: dois plugins de cache ou de minificação ativos ao mesmo tempo disputam a mesma tarefa e podem quebrar layout. Num site de catálogo em Elementor que atendemos, dois plugins de otimização juntos derrubaram a nota de desktop do Lighthouse de 99 para 63, e o tempo de bloqueio subiu de 70 ms para 1,69 s; ficou só um.
• Medir logado: o administrador costuma receber a página sem cache e com a barra do painel, o que distorce o TTFB.
• Corrigir tudo de uma vez: sem medir entre as mudanças, fica impossível saber o que funcionou.
• Trocar de hospedagem com TTFB bom: se o atraso está no navegador, o servidor mais caro entrega o mesmo resultado.
• Confiar só na nota do laboratório: a nota do Lighthouse varia entre execuções; o dado de campo é o que mostra a experiência real.

OPINIÃO DE ESPECIALISTA

“Na maioria dos casos que atendemos, a lentidão tinha causa corrigível dentro do WordPress. Na Inforchannel, a página sem cache levava de 7 a 12 segundos para ser gerada. Com opções de autoload enxutas, avisos de PHP corrigidos e robôs filtrados, passou a sair em 25 a 38 milissegundos, sem trocar de plataforma. O WordPress perde o sentido quando a lentidão vem do desenho do produto: páginas diferentes para cada usuário, que não podem ir para cache, ou integrações que o site espera a cada clique. Nesse caso, vale discutir arquitetura antes de comprar servidor maior.”

Quanto esforço a correção exige

O esforço depende da causa. Ajustar versão do PHP e ativar cache de página costuma ser tarefa de configuração, enquanto reescrever tema, trocar construtor visual ou refazer integrações é trabalho de desenvolvimento. Ajustes de configuração, como cache, versão do PHP ou um cookie que anula o cache, ficam em horas. Correções de código pedem de algumas horas a alguns dias, com plano aprovado antes, e uma reestruturação de infraestrutura, como uma camada de cache com Nginx e Varnish num portal de grande audiência, vira projeto. Quando a correção esbarra na estrutura do site, o orçamento é de projeto, e o conteúdo sobre quanto custa um site em WordPress ajuda a dimensionar. Se a dúvida é a própria plataforma, a comparação Wix ou WordPress mostra o que muda em controle de desempenho.

Como acompanhar o resultado

Repita a medição nas mesmas páginas, no mesmo perfil de dispositivo e sem estar logado. O dado de laboratório muda na hora; o de campo é uma média móvel dos últimos 28 dias, então a melhora aparece aos poucos e só se completa depois desse período. As métricas para acompanhar são TTFB e LCP por tipo de página e o status do relatório de Core Web Vitals do Search Console. Junto com elas, acompanhe o evento de conversão da página no GA4 (envio de formulário em site institucional; begin_checkout e purchase em loja), comparando os 28 dias antes e os 28 dias depois da correção, para coincidir com a janela do dado de campo. A métrica de negócio vem do GA4 porque, em sites com muito robô, o servidor recebe muito mais acessos do que o GA4 registra como visitas. Depois da correção, manter o site rápido vira rotina de atualização, imagens, banco de dados e plugins.

Quando vale chamar um especialista

O diagnóstico por medição pode ser feito internamente com as ferramentas deste artigo. Mudanças em servidor, cache de objetos, cron do sistema e tema pedem alguém com acesso e experiência para desfazer um problema. Para esses casos, a Studio Visual tem uma página sobre o trabalho de especialista em WordPress.