O teu WordPress está lento? 9 causas e como resolver

O teu site WordPress demora quatro ou cinco segundos a carregar, o painel de administração está lento e o cliente diz que o site "está a girar". Este é um dos problemas mais comuns que os proprietários de sites nos trazem. A boa notícia é que, em nove de dez casos, a causa é uma das várias bem conhecidas e pode ser encontrada em uma hora.

Abaixo, encontras nove razões pelas quais o WordPress pode estar lento, por ordem de frequência. Para cada uma, explicamos como identificá-la e como a corrigir por ti mesmo.

Índice

1. Como verificar se o WordPress está realmente lento?
2. Será que a culpa é do alojamento partilhado?
3. Tens demasiados plug-ins?
4. As imagens são demasiado pesadas?
5. O site tem a cache ativada?
6. Que versão de PHP está a ser usada no site?
7. A base de dados não está sobrecarregada?
8. O tema ou o page builder não são demasiado pesados?
9. Os scripts externos não estão a bloquear o carregamento?
10. O wp-cron não está a consumir recursos?
11. Por onde começar a reparação?
12. FAQ

Como verificar se o WordPress está realmente lento?

Antes de alterares qualquer coisa, mede. Sem medição, não sabes se a correção ajudou, e "parece-me mais rápido" não é um resultado.

Três ferramentas são suficientes:

• O PageSpeed Insights (pagespeed.web.dev) mostra a pontuação do Google para telemóvel e computador, bem como os indicadores Core Web Vitals. O mais importante é o LCP, ou seja, o tempo que leva para o maior elemento da página ser visível. Um bom resultado é abaixo de 2,5 segundos.
• O GTmetrix ou o WebPageTest detalham o carregamento num gráfico em cascata. Mostra qual o ficheiro que leva mais tempo a carregar.
• O TTFB (Time To First Byte), ou seja, o tempo até ao primeiro byte da resposta do servidor. Podes verificá-lo em ambas as ferramentas ou no separador Rede do navegador (F12). Se o TTFB exceder 600 ms, o problema está no servidor ou no PHP. Se o TTFB for baixo, mas a página ainda demora muito a carregar, os ficheiros do lado do navegador são os culpados: imagens, scripts, tipos de letra.

Esta divisão é crucial. Um TTFB alto indica problemas com o alojamento, falta de cache, PHP antigo, base de dados congestionada ou wp-cron. Um TTFB baixo com carregamento lento indica problemas com imagens, temas pesados e scripts externos. Os plugins podem afetar ambos.

Mede a página principal e uma subpágina, por exemplo, uma publicação ou uma ficha de produto. Guarda os resultados, voltarás a eles após cada alteração.

A culpa é do alojamento partilhado?

Esta é a razão número um que o proprietário de um site normalmente não suspeita, porque "eu estou a pagar pelo alojamento, afinal".

No alojamento partilhado clássico, o teu site está num servidor juntamente com centenas de outros. O processador, a memória e o disco são partilhados. Quando um vizinho tem um pico de tráfego, envia uma newsletter ou alguém ataca o site dele, o teu WordPress também fica mais lento. Além disso, existem limites para os processos PHP. Quando várias pessoas entram na loja ao mesmo tempo, os pedidos seguintes ficam em fila de espera.

Como identificar: O TTFB salta. 300 ms de manhã, 2 segundos à noite, sem qualquer alteração na página. No painel de alojamento, são visíveis mensagens sobre a superação do limite de recursos (muitas vezes chamadas "resource limit reached" ou "508").

Como corrigir: A otimização do site só ajuda parcialmente. Se o servidor estiver sobrecarregado por outros, é necessário mudar para um alojamento onde os recursos são atribuídos a ti. No Saplo, cada Box é um contentor separado com a sua própria RAM e disco. O Box S tem 1 GB de RAM, o Box M tem 2 GB, o Box L tem 6 GB, e ninguém de fora consome esta memória. Os detalhes dos planos estão na lista de preços.

Tens demasiados plugins?

O número de plugins por si só não é um problema. Um site com quarenta plugins leves pode funcionar mais rapidamente do que um site com dez plugins pesados. O problema são os plugins que, em cada visita à página, fazem muitas consultas à base de dados ou carregam os seus scripts em todas as subpáginas, mesmo onde não são necessários.

Os culpados mais comuns são os plugins de estatísticas abrangentes contados no servidor, os plugins de segurança "tudo em um" que verificam os ficheiros em tempo real, os plugins para publicações relacionadas, sliders e formulários carregados globalmente.

Como identificar: instala o plugin gratuito Query Monitor. Na barra de administração, ele mostrará o tempo de geração da página, o número de consultas à base de dados e qual plugin envia quantas. Uma página que demora mais de 0,5 segundos a gerar ou que tem centenas de consultas tem um problema.

Como corrigir:

1. Faz um backup do site.
2. Desativa os plugins que não usas há meses. Apaga-os, não apenas desativa.
3. Para plugins pesados, procura uma alternativa mais leve.
4. Usa um plugin como o Asset CleanUp ou o Perfmatters para desativar o carregamento dos scripts de um determinado plugin onde for desnecessário (por exemplo, scripts de formulários de contacto apenas na página de Contactos).
5. Mede novamente.

As imagens são muito pesadas?

Uma foto diretamente da câmara ou do telemóvel pesa entre 4 a 8 MB e tem uma largura de 4000 pixels. No site, é exibida com 800 pixels de largura, mas o navegador ainda tem de fazer o download do ficheiro completo. Três dessas fotos na página inicial e o LCP aumenta para vários segundos, especialmente no telemóvel.

Como reconhecer: No PageSpeed Insights, aparecem as recomendações "Servir imagens em formatos de nova geração" e "Dimensionar imagens corretamente". No gráfico em cascata, as barras mais longas são ficheiros JPG ou PNG.

Como corrigir:

• Antes de carregar, reduz as fotos para uma largura razoável, geralmente 1600 a 2000 pixels para fotos de largura total.
• Ativa a conversão para o formato WebP ou AVIF. Os plugins como Converter for Media, EWWW Image Optimizer ou ShortPixel fazem isso.
• Garante que o carregamento diferido (lazy loading) está ativo. O WordPress adiciona-o automaticamente a partir da versão 5.5, mas alguns temas desativam-no.
• A imagem visível no topo da página (por exemplo, a imagem no cabeçalho) não deve ser carregada de forma diferida. É ela que decide o LCP.

O site tem cache ativado?

Sem cache, o WordPress, a cada visita, executa PHP, conecta-se à base de dados, constrói a página com dezenas de queries e só depois a envia para o navegador. Com dez visitantes em simultâneo, o servidor faz o mesmo trabalho dez vezes.

Existem dois tipos de cache que vale a pena distinguir:

• Cache de páginas guarda o HTML pronto e serve-o aos visitantes seguintes sem executar PHP. É fornecido por plugins como WP Super Cache, W3 Total Cache, LiteSpeed Cache (apenas em servidores LiteSpeed) ou WP Rocket (pago).
• Cache de objetos (object cache) armazena os resultados das queries à base de dados em memória, geralmente no Redis. Ajuda onde o cache de páginas não funciona: no Painel de administração, no carrinho de compras e na Conta de cliente na loja WooCommerce.

Como identificar: no Query Monitor, verifica se o object cache está ativo. O TTFB na página, que atualizas pela segunda vez, deve diminuir significativamente. Se não diminuir, o cache de páginas não está a funcionar.

Como corrigir: instala um plugin de cache de páginas (não dois ao mesmo tempo, pois podem entrar em conflito) e ativa o object cache, se o hosting oferecer Redis. Na Saplo, a instalação do WordPress a partir do catálogo conecta automaticamente o Redis local na Box e ativa o plugin Redis Object Cache, com um prefixo e base de dados separados para cada site. Não é preciso configurar nada manualmente.

Qual é a versão do PHP que a página está a usar?

O WordPress é escrito em PHP, e cada nova versão do PHP é mais rápida que a anterior. A diferença entre o PHP 7.4 e o PHP 8.3 na mesma página pode ser notória, especialmente no painel de administração e em grandes lojas. O PHP 7.4 já não recebe atualizações de segurança.

Como identificar: No painel do WordPress, vai a Ferramentas, depois Estado do Site, depois Informações, secção Servidor. Vais ver a versão do PHP e o limite de memória.

Como corrigir:

1. Faz um backup.
2. Atualiza o WordPress, o tema e os plugins para as versões mais recentes. Plugins antigos podem ser incompatíveis com o novo PHP.
3. Altera a versão do PHP no painel de alojamento para 8.2 ou 8.3.
4. Verifica a página principal, o formulário, o carrinho de compras e o painel. Se algo falhar, volta à versão anterior e procura qual o plugin incompatível.

Na Saplo, ao instalares o WordPress, escolhes a versão do PHP de uma lista que vai do 7.4 ao 8.5. Por padrão, definimos a 8.3, porque praticamente todos os plugins atuais são compatíveis com ela.

A base de dados não está cheia?

A base de dados do WordPress aumenta com o tempo. Acumulam-se revisões de publicações (cada gravação cria uma nova cópia), publicações no lixo, spam nos comentários, dados temporários expirados (transients) e opções de plugins que eliminaste há muito tempo. A tabela wp_options é particularmente perigosa. Algumas das suas linhas são carregadas pelo WordPress sempre que acedes à página (opções com a flag de carregamento automático). Se atingir vários megabytes, irá abrandar cada acesso.

Como reconhecer: no estado de saúde do site, o WordPress, a partir da versão 6.6, avisa se as opções de carregamento automático forem demasiado grandes. No Query Monitor, podes ver consultas lentas à base de dados.

Como corrigir:

• Limita o número de revisões, adicionando a linha define('WP_POST_REVISIONS', 5); ao ficheiro wp-config.php.
• Limpa a base de dados com o plugin WP-Optimize ou Advanced Database Cleaner: revisões, lixo, spam, transients expirados.
• Remove as opções dos plugins desinstalados. O Advanced Database Cleaner mostra a que plugin pertence cada opção.
• Antes de limpar, faz sempre uma cópia de segurança da base de dados.

O teu tema ou page builder é demasiado pesado?

Os temas "multifuncionais" vendidos com centenas de layouts pré-prontos carregam scripts e estilos para todas as suas funções em cada página, incluindo aquelas que não usas. Os page builders (Elementor, Divi, WPBakery) adicionam a isso um código HTML profundamente aninhado e os seus próprios ficheiros CSS e JS.

Isto não significa que tenhas de deitar fora o builder. Significa que tens de o configurar.

Como reconhecer: No PageSpeed Insights, as recomendações "Remover JavaScript não utilizado" e "Remover CSS não utilizado" apontam para ficheiros do tema ou do builder. A página tem vários megabytes de scripts.

Como corrigir:

• No Elementor, ativa as funcionalidades de desempenho nas definições (carregamento otimizado de recursos, carregamento de CSS num ficheiro em vez de inline).
• Desativa os módulos do tema que não usas (sliders, ícones, animações).
• Ao construíres um novo site, considera um tema leve, como GeneratePress, Kadence ou Astra, e um editor de blocos em vez de um builder pesado.

Os scripts externos não estão a bloquear o carregamento?

Um chat no site, o pixel do Facebook, Google Analytics, Tag Manager com dez tags, um mapa Google, um vídeo incorporado do YouTube, um widget de comentários, fontes do Google Fonts. Cada um deles é uma ligação separada a um servidor diferente e mais alguns kilobits de scripts sobre os quais não tens controlo.

Como identificar: no gráfico em cascata, vês muitos ficheiros de outros domínios. O PageSpeed Insights mostra a recomendação "Reduz o impacto do código de terceiros".

Como corrigir:

• Analisa o Tag Manager e remove as tags de campanhas antigas.
• Carrega o chat apenas após a interação do utilizador ou após alguns segundos.
• Incorpora vídeos do YouTube como uma miniatura que carrega o reprodutor apenas após um clique (por exemplo, o WP YouTube Lyte faz isso).
• Descarrega as fontes para o teu próprio servidor em vez de as carregares do Google Fonts. Além disso, resolves a questão do RGPD.

O wp-cron não consome recursos?

O WordPress tem um agendador de tarefas incorporado, o wp-cron. Não funciona como um cron de sistema real, mas sim quando os visitantes acedem ao site. Num site com muito tráfego, é ativado com demasiada frequência; num site com pouco tráfego, as tarefas (publicação de posts agendados, cópias de segurança, envio de e-mails da loja) são executadas com atraso e podem atrasar um acesso aleatório que as ativou.

Como identificar: acessos individuais são visivelmente mais lentos do que os restantes, sem razão aparente. O plugin WP Crontrol mostra uma lista de tarefas e, muitas vezes, tarefas de plugins eliminados que permanecem por anos.

Como corrigir:

1. No WP Crontrol, remove tarefas de plugins que já não tens.
2. Desativa a execução do wp-cron por visitantes, adicionando a linha define('DISABLE_WP_CRON', true); ao wp-config.php.
3. Configura um cron de sistema real que, a cada 5 minutos, chama wp cron event run --due-now ou o endereço wp-cron.php. Na Saplo, a partir do Box M, tens acesso SSH com sudo completo, por isso podes configurá-lo numa única linha do crontab.

Por onde deves começar a corrigir?

Se não sabes por onde começar, segue esta ordem, porque do topo para baixo as mudanças são as mais baratas e com maior efeito:

1. Mede a página em PageSpeed Insights e regista o TTFB e o LCP.
2. Faz uma cópia de segurança de toda a página e da base de dados.
3. Atualiza o WordPress, os plugins e o PHP para 8.2 ou 8.3.
4. Ativa o cache das páginas e, se puderes, o object cache no Redis.
5. Otimiza as imagens e converte-as para WebP.
6. Analisa os plugins no Query Monitor e remove os desnecessários.
7. Limpa a base de dados e limita as revisões.
8. Otimiza os scripts externos e configura o tema.
9. Mede novamente. Se o TTFB continuar a variar dependendo da hora do dia, o problema está no alojamento e não na página.

Neste último caso, nenhum plugin ajudará. É preciso migrar a página para um local onde os recursos do servidor são só teus. Se estás a considerar a Saplo, migramos o WordPress por ti: a migração é gratuita, juntamente com a base de dados e o email, sem interrupção da página. Mais sobre como o WordPress funciona na Saplo, encontrarás na página WordPress no Catálogo de aplicações e na página de alojamento WordPress.

Perguntas Frequentes

Demasiados plugins no WordPress?

Não existe um limite único. O que importa é o que os plugins fazem, não o número deles. Um site com trinta plugins leves pode ser rápido, enquanto um plugin mal escrito pode bloqueá-lo. Verifica o tempo de geração da página e o número de consultas no Query Monitor, e não a contagem de itens na lista.

Um plugin de cache é suficiente para acelerar o WordPress?

Frequentemente, proporciona o maior aumento de velocidade de uma só vez, mas não resolve tudo. O cache de páginas não funciona no painel de administração, no carrinho de compras ou para clientes de loja com sessão iniciada. Nessas situações, o cache de objetos no Redis, uma versão atualizada do PHP e a organização dos plugins ajudam. O cache também não irá resolver problemas com imagens pesadas ou um servidor sobrecarregado.

Por que o painel de administração do WordPress funciona lentamente, mas o site é rápido?

Porque os visitantes recebem páginas prontas da cache, e o painel de administração é sempre gerado em tempo real por PHP e pela base de dados. Um painel lento é geralmente um sinal de plugins pesados, de uma tabela wp_options congestionada, de um PHP antigo ou da falta de object cache. Começa com o Query Monitor aberto no painel.

Qual é a boa pontuação no PageSpeed Insights?

Uma pontuação de 90 ou mais é muito boa, e de 50 a 89 indica que são necessárias melhorias. Mais importantes do que o número são as métricas Core Web Vitals: LCP abaixo de 2,5 segundos, INP abaixo de 200 ms e CLS abaixo de 0,1. Estas métricas são as que afetam a classificação do teu site no Google.

Mudar de alojamento vai acelerar o WordPress?

Sim, se o problema for o servidor, ou seja, um TTFB elevado e instável e mensagens sobre limites de recursos. Não, se a página tiver imagens pesadas e dezenas de scripts desnecessários, porque os mesmos ficheiros terão de ser descarregados do novo servidor. Primeiro, mede, depois decide.