WordPress lento em uma VPS pode ter várias causas: PHP esperando uma API externa, consultas caras no banco, memória insuficiente, imagens grandes ou JavaScript bloqueando a interação. Aumentar a máquina e instalar vários plugins de otimização antes de medir pode elevar o custo sem resolver o gargalo.
Neste guia, vamos seguir uma ordem de diagnóstico: medir a experiência, conferir a infraestrutura, investigar a execução do WordPress e otimizar cache e recursos do navegador. Os exemplos são procedimentos para adaptar ao seu ambiente; não representam uma auditoria ou comandos executados no Blog DevBetortiz.
Antes de otimizar: descubra onde está o problema
Escolha páginas e cenários representativos
Teste a página inicial, um artigo, uma busca e o painel administrativo. Se houver loja, inclua produto, carrinho e checkout. Separe visitante anônimo de usuário autenticado: o cache e o conteúdo podem mudar completamente entre os dois.
Registre dispositivo, rede, região, horário e estado do cache. Repita as medições em condições semelhantes e compare a mediana, não apenas a melhor execução.
Diferencie servidor lento de página pesada
Tempo até o primeiro byte, ou TTFB, mostra quanto a requisição leva até receber o início da resposta. Ele inclui rede, negociação e processamento; não é uma medida isolada de PHP. Um HTML que chega rápido ainda pode resultar em uma página lenta por imagens, fontes e scripts.
Use a aba Network do navegador para descobrir quais recursos atrasam. PageSpeed Insights e Lighthouse ajudam com diagnóstico do carregamento; dados de usuários reais complementam o teste de laboratório. Sites novos podem ainda não ter volume suficiente para um relatório de campo.
As Core Web Vitals observam carregamento do conteúdo principal, resposta a interações e estabilidade visual. Avalie LCP, INP e CLS ao longo do uso real. Não trate a pontuação de uma execução como garantia de boa experiência.
Meça uma requisição HTTP
curl -sS -L -o /dev/null \
-w 'HTTP=%{http_code}\nDNS=%{time_namelookup}\nConexao=%{time_connect}\nTLS=%{time_appconnect}\nPrimeiroByte=%{time_starttransfer}\nTotal=%{time_total}\n' \
https://SEU_DOMINIO/ARTIGO/Execute de um local comparável ao seu público e use uma URL canônica, sem redirecionamentos desnecessários. Os valores são tempos acumulados; o comando não mede renderização nem interação no navegador. Ele também não autentica um usuário do WordPress.
Para revisar a infraestrutura de origem, veja Como instalar WordPress com Dokploy em uma VPS.
CPU, memória e disco da VPS
Verifique o host e os containers
uptime
free -h
df -h
vmstat 1 5
docker stats --no-streamObserve recursos durante a lentidão, não apenas quando o site está ocioso. Memória “livre” pequena, isoladamente, não prova falta de RAM: examine memória disponível, swap e sinais de pressão. Em vmstat, as amostras após a primeira ajudam a observar o intervalo atual.
CPU alta pode vir do WordPress, do banco, de um build ou de outra aplicação na VPS. Espera de I/O pode indicar pressão no armazenamento. Disco cheio pode impedir logs, uploads e gravações do banco.
Limites e reinícios de containers
docker inspect NOME_DO_CONTAINER \
--format 'OOMKilled={{.State.OOMKilled}} RestartCount={{.RestartCount}} MemoryLimit={{.HostConfig.Memory}}'Substitua o marcador pelo container correto no host de execução. Limites de memória e CPU podem restringir o processo mesmo quando a VPS tem folga. Um evento de OOM ou reinício exige investigar a causa; aumentar o limite sem verificar consumo pode apenas deslocar o problema.
Quando aumentar recursos
Aumente a VPS quando a carga legítima, depois das correções principais, exceder a capacidade ou quando faltar margem operacional. Se o pico acontece durante builds e backups, uma mudança de horário ou servidor pode ser mais eficiente que ampliar toda a stack.
PHP, PHP-FPM e OPcache
Identifique como o PHP é executado
Nem todo WordPress em Docker usa PHP-FPM. A stack com imagem wordpress:apache do nosso guia usa a variante Apache; configurações de pool FPM não se aplicam automaticamente a ela. Confira imagem, módulos e processo web antes de copiar parâmetros.
Utilize uma versão PHP suportada e compatível com tema e plugins. Faça o teste de atualização em um ambiente separado: mudanças de versão podem afetar extensões e código personalizado.
OPcache e memória por requisição
OPcache reduz recompilação de scripts PHP. Confira se está habilitado no processo que atende HTTP e se há espaço para os scripts utilizados. Uma consulta pela CLI pode usar outra configuração, então não presuma que seu resultado representa o servidor web.
Aumentar memory_limit pode permitir requisições pesadas, mas não elimina a origem do consumo. Vários processos com consumo alto podem esgotar a VPS. Registre a memória observada e deixe margem para banco, proxy e sistema.
Se você usa PHP-FPM
Revise fila, slowlog e limites do pool. pm.max_children controla a quantidade máxima de processos de atendimento; elevá-lo sem memória suficiente pode provocar swap ou encerramentos. Dimensione com a memória real por worker e a parcela disponível para PHP.
Não exponha publicamente páginas de status, informações de configuração ou slowlogs. Use-os para localizar scripts e requisições caras, depois valide as mudanças com a mesma carga.
Banco de dados
Consultas lentas e chamadas externas
Uma consulta lenta pode vir de falta de índice, volume crescente ou lógica de plugin. Um request também pode ficar esperando HTTP externo mesmo que o banco esteja rápido. Separe essas causas antes de alterar parâmetros do MySQL ou MariaDB.
Use uma ferramenta de diagnóstico como Query Monitor para observar consultas e chamadas HTTP durante o teste. Requisições autenticadas com diagnóstico ativo têm custo e podem escapar do cache; compare esse perfil ao cenário que você quer otimizar.
Se habilitar slow query log no banco, escolha duração e retenção controladas. O log pode conter dados sensíveis e crescer rapidamente. Corrija consultas identificadas e teste índices antes de aplicá-los em produção.
Autoload das opções
Opções carregadas automaticamente podem aumentar trabalho e memória em muitas requisições. Verifique o volume e a origem em Saúde do site e ferramentas compatíveis com sua versão. Não use uma consulta que considera apenas autoload = yes como inventário universal: versões atuais também usam outros valores.
Identifique a extensão responsável por cada opção grande. Alterar autoload ou apagar opções sem conhecer seu uso pode causar regressões. Otimizar exige remover o que realmente ficou obsoleto e confirmar o comportamento do plugin.
Limpeza e manutenção
Revisões antigas, tabelas órfãs e transients podem ocupar espaço, mas uma base menor não garante uma página mais rápida. Evite exclusões genéricas e comandos de otimização durante picos: algumas operações podem bloquear tabelas ou consumir muito I/O.
Antes de mudanças no banco, tenha uma cópia recuperável. Nosso guia de backup no Dokploy inclui a organização das cópias e o teste de restauração.
Cache: páginas, objetos e navegador
Page cache
Cache de páginas reutiliza HTML pronto e pode reduzir o trabalho de PHP e banco para visitantes anônimos. Comece com uma camada definida e regras claras, em vez de ativar várias soluções que disputam invalidação.
Exclua login, painel e respostas personalizadas. Em lojas, carrinho, checkout e conta precisam de regras próprias. Teste também publicação de conteúdo, comentários e formulários para confirmar que a invalidação não deixa dados antigos visíveis.
Object cache e Redis
O cache de objetos guarda resultados e estruturas usadas pelo WordPress. Uma implementação persistente mantém esse conteúdo entre requisições; ela é diferente do cache de páginas.
Subir Redis na rede não conecta o WordPress automaticamente. É necessário configurar integração compatível, prefixos por site, autenticação quando aplicável, limites e política de memória. Monitore a taxa de acerto e teste o efeito sobre as páginas dinâmicas.
Redis não deve ser publicado na internet para esse uso. Também não trate uma limpeza de cache como rotina sem custo: ela pode produzir um pico de recomputação e consultas.
Cache do navegador
Defina cache adequado para imagens, fontes, CSS e JavaScript. Use versionamento para que alterações de assets gerem URLs novas. Conteúdo personalizado requer regras diferentes de arquivos estáticos.
CDN e Cloudflare
Uma CDN pode aproximar arquivos do usuário e reduzir tráfego na origem. O cache de HTML exige configuração explícita e exclusões adequadas. Não assuma que ativar o proxy já acelera toda requisição do WordPress.
Ao criar regras, confira cookies de sessão, caminhos de autenticação, métodos HTTP e respostas com dados pessoais. Teste com duas sessões diferentes para verificar isolamento. Considere headers do cache e confirme se a regra realmente foi aplicada.
Evite mudar cache, minificação e imagens ao mesmo tempo: isso dificulta identificar o efeito. Registre também como purgar cada camada quando publicar ou corrigir conteúdo.
Imagens, fontes e JavaScript
Otimize o conteúdo principal
Uma imagem de capa grande pode dominar o carregamento de um artigo. Entregue tamanho adequado ao espaço exibido e use formatos eficientes quando suportados pelo seu fluxo. Confira imagens responsivas e defina dimensões para reduzir mudanças de layout.
A imagem principal visível no primeiro trecho da página pode precisar de carregamento prioritário. Aplicar lazy loading indiscriminadamente nela pode atrasar o conteúdo principal. Use carregamento adiado nas imagens fora da área inicial conforme o comportamento real.
Reduza trabalho no navegador
Revise scripts de analytics, widgets e embeds; cada integração acrescenta rede e execução. Carregue código onde ele é necessário e teste qualquer adiamento de JavaScript com menus, formulários e consentimento.
Limite famílias e variações de fonte. Minificar ajuda no tamanho, mas não resolve lógica pesada nem remove trabalho do navegador. Uma página pode obter bom tempo de servidor e ainda responder mal a cliques.
Plugins, temas e tarefas agendadas
A quantidade de plugins, sozinha, não explica performance. Um único plugin pode executar consultas caras ou chamar APIs em toda requisição. Avalie tempo, consultas e recursos carregados.
Em staging, teste a desativação de extensões suspeitas uma por vez e registre o resultado. Trocar o tema também exige validar layout e funcionalidades. Mantenha código personalizado em tema filho e revise hooks que rodam em muitas páginas.
Verifique tarefas de sincronização, otimização de imagens, backup e filas. Eventos recorrentes acumulados podem competir com visitas. Se mover WP-Cron para um agendador externo, configure e valide esse agendador antes de desabilitar o acionamento por visitas.
A manutenção contínua está detalhada em WordPress em VPS: checklist de desempenho, segurança e manutenção.
Um roteiro prático para corrigir a lentidão
- Registre páginas, sessões e métricas de referência.
- Durante o problema, observe host, containers e reinícios.
- Descubra se a espera está na origem ou nos recursos do navegador.
- Localize consultas, scripts e chamadas externas caras.
- Ajuste uma causa por vez e repita o cenário medido.
- Configure cache com exclusões e invalidação verificadas.
- Valide login, formulários, uploads e compra, se houver.
- Documente resultado e acompanhe após a mudança.
Se a melhora existe apenas com cache quente, teste também a primeira visita após expiração. Se a melhora aparece só para anônimos, investigue separadamente o painel e as rotas dinâmicas.
Checklist final de otimização
- Páginas representativas avaliadas em celular e desktop.
- TTFB, carregamento e interação analisados separadamente.
- Recursos da VPS e limites dos containers com margem.
- PHP e extensões compatíveis, com configuração web verificada.
- Consultas e chamadas externas caras identificadas.
- Cache de páginas e objetos com funções claras.
- Sessões e conteúdo personalizado protegidos nas regras de cache.
- Imagens e scripts revisados.
- Backup e plano de retorno disponíveis.
Conclusão
O caminho para um WordPress rápido na VPS começa com evidência: descubra qual etapa consome tempo, corrija a causa e compare o mesmo cenário depois. Cache ajuda muito em páginas públicas; consultas, tarefas e JavaScript exigem intervenções próprias.
Com uma rotina de medição e mudanças pequenas, você consegue escolher entre corrigir código, ajustar configuração e aumentar infraestrutura com menos tentativa e erro.
Referências oficiais
- WordPress: otimização
- WordPress: desempenho do PHP
- WordPress: cache de objetos
- PHP: configuração do FPM
- web.dev: Web Vitals
- Cloudflare: regras de cache
