O seu site WordPress está lento: Como acelerá-lo

#Porque o alojamento raramente resolve um site WordPress lento

O processo completo de otimização está no nosso guia de otimização do WordPress, e a visão geral de desempenho para 2026 no guia definitivo de performance WordPress.

Quando um site WordPress começa a perder velocidade, a reação instintiva é fazer um upgrade do plano de alojamento. Embora um servidor melhor ajude, muitas vezes apenas mascara problemas arquitetónicos subjacentes. Investir em alojamento antes de otimizar a camada da aplicação é apenas uma solução temporária para um problema permanente.

#O que torna o WordPress lento além do alojamento

Um servidor mais rápido terá melhor desempenho, mas se o seu site estiver sobrecarregado com recursos mal otimizados, estará apenas a correr código ineficiente num CPU mais veloz. Estes são os pontos de estrangulamento mais comuns que drenam o seu desempenho:

• Excesso de plugins e dívida de consultas: Cada plugin ativo não é apenas um ficheiro, é uma série potencial de consultas à base de dados e dependências externas. Muitas dessas consultas são redundantes: pedem os mesmos dados em cada pedido, quando poderiam ter sido guardadas em cache uma única vez.
• Imagens não geridas: Imagens de alta resolução sem formatos modernos (como AVIF ou WebP) são a causa n.º 1 de um LCP lento. Uma fotografia hero exportada diretamente da câmara ou de um banco de imagens pesa frequentemente várias vezes mais do que a mesma imagem codificada em AVIF no tamanho em que é realmente apresentada.
• Falta de object cache: Pedidos constantes à base de dados para dados estáticos forçam o servidor a um trabalho redundante. As opções do site, os menus de navegação e as definições dos widgets são lidos em cada carregamento de página, embora raramente mudem.
• Latência de scripts de terceiros: Trackers externos, fontes e embeds bloqueiam frequentemente a thread principal e prejudicam os seus Core Web Vitals. Fontes web carregadas a partir de um alojamento externo, píxeis de rastreio de redes sociais e widgets de chat ao vivo são os culpados habituais.

#Como ler os dados de campo do PageSpeed Insights num site WordPress

O PageSpeed Insights mostra dois tipos diferentes de números no mesmo ecrã, e confundi-los é um motivo comum para uma correção no WordPress parecer não ter efeito. A secção de campo vem do Chrome User Experience Report (CrUX): utilizadores reais do Chrome que deram consentimento, agregados ao longo do período de recolha dos 28 dias anteriores e apresentados no percentil 75 (documentação do PageSpeed Insights). A secção de laboratório é um único carregamento simulado num só dispositivo com condições de rede fixas, por isso os dois conjuntos de valores podem diferir.

Três consequências para o diagnóstico:

• Verifique a que nível correspondem os dados. Quando um URL não tem dados suficientes próprios, o PSI recorre aos dados da origem. Num artigo de blogue com pouco tráfego, o LCP de campo pode descrever todo o domínio e não essa página.
• Priorize com dados de campo, depure com dados de laboratório. O web.dev recomenda que, quando existem ambos, sejam os dados de campo a orientar as prioridades e os de laboratório a servir para depuração (web.dev: porque diferem os dados de laboratório e de campo). Os testes de laboratório carregam a página com a cache vazia e não conseguem prever quando um visitante real vai clicar, e é por isso que o Total Blocking Time é apenas um indicador aproximado do INP em laboratório, não um substituto. O nosso guia de otimização do INP explica o que fazer quando os dados de campo apontam para aí.
• Conte com um atraso. Como a janela é de 28 dias, uma correção publicada hoje só aparece por completo nos dados de campo cerca de quatro semanas depois. Uma pontuação de laboratório que melhora de um dia para o outro é um bom sinal, não uma prova.

#Como saber se o TTFB aponta para o servidor

O TTFB é onde a pergunta sobre a culpa do alojamento recebe uma resposta mensurável. O web.dev define o TTFB como a soma do tempo de redirecionamento, do arranque do service worker, da consulta DNS, da ligação e negociação TLS, e do pedido até ao primeiro byte da resposta. Considera 0,8 segundos ou menos uma referência aproximada para um bom valor, e acima de 1,8 segundos um valor fraco (web.dev: otimizar o Time to First Byte).

Esta decomposição importa no WordPress porque nem tudo é PHP. Um visitante que chega a http://, é redirecionado para https:// e depois para o host com www paga cada salto antes de o WordPress começar a trabalhar. O painel Network das DevTools mostra cada redirecionamento como um pedido separado, e a correção está na configuração do servidor ou da CDN, não na base de dados. No terreno, o TTFB obtém-se do CrUX ou da biblioteca JavaScript web-vitals; em laboratório, do painel Network das DevTools ou do WebPageTest.

O valor de 200 ms usado noutras partes deste artigo é um objetivo de trabalho mais exigente para uma página WordPress servida a partir da cache de página. Um valor entre 200 ms e 0,8 s não falha segundo a referência da Google. É um motivo para verificar se a cache de página está mesmo a ser usada.

#Como usar o Estado do site para detetar problemas de velocidade no WordPress

O WordPress inclui verificações próprias em Ferramentas, Estado do site, e algumas dizem respeito à velocidade. Desde o WordPress 6.1, o Estado do site verifica se existe uma cache de página completa e se o tempo de resposta do servidor é aceitável, com 600 ms como limite predefinido que os fornecedores de alojamento podem alterar com o filtro site_status_good_response_time_threshold. Também recomenda uma cache de objetos persistente quando os dados do site ultrapassam limites que o alojamento pode substituir com site_status_persistent_object_cache_thresholds (Make WordPress Core, verificações de cache no 6.1). As duas verificações só correm em produção, por isso uma cópia de staging não as mostra.

O WordPress 6.6 acrescentou uma verificação das opções com carregamento automático: assinala um problema quando as opções carregadas em cada pedido somam mais de 800 KB. A mesma versão deixou de carregar automaticamente qualquer opção individual com mais de 150.000 bytes, a menos que o código o peça explicitamente, um limite ajustável com o filtro wp_max_autoloaded_option_size (Make WordPress Core, alterações ao autoload no 6.6). Um aviso de autoload costuma levar às opções órfãs de plugins descritas na secção sobre a base de dados mais abaixo.

#Como encontrar o plugin lento com o Query Monitor

O Query Monitor transforma “o WordPress está lento” num componente com nome. O painel da base de dados assinala consultas lentas, duplicadas e falhadas, e agrupa-as por tipo de consulta, componente ou função que as chama, de modo que uma consulta que um plugin repete em cada pedido aparece com o nome desse plugin (Query Monitor no GitHub). Há outros dois painéis fáceis de ignorar:

• Chamadas à HTTP API: cada pedido do lado do servidor feito através da HTTP API do WordPress, com os pedidos falhados e as respostas diferentes de 200 destacados. Um plugin que contacta um servidor remoto enquanto a página é gerada soma essa ida e volta ao TTFB.
• Hooks e ações: cada hook disparado durante o pedido, com os seus callbacks, prioridades e componentes, o que mostra onde um plugin se liga a páginas onde não tem qualquer função visível.

Use-o numa cópia de staging sempre que possível. O Query Monitor mostra a sua informação a administradores com sessão iniciada, e esses pedidos costumam contornar a cache de página, por isso os números descrevem o caso sem cache: o trabalho que o servidor faz por cada visitante que a cache não cobre.

#Como acelerar um site WordPress lento

Os passos seguintes são aqueles para onde um diagnóstico aponta com mais frequência.

#1. Implementar object caching seletivo

Em vez de sobrecarregar a base de dados com as mesmas consultas, utilize a Transients API ou uma cache de objetos persistente (como Redis). Isto é crucial para sites dinâmicos onde a cache de página nem sempre é possível.

A Transients API funciona com um padrão de verificar e guardar. O WordPress procura primeiro o valor sob uma chave com nome. Se estiver lá e não tiver expirado, é devolvido de imediato sem tocar na tabela de artigos. Caso contrário, o seu código executa a consulta, guarda o resultado com um tempo de expiração e devolve-o.

function get_performance_optimized_posts() {
    // Tentar obter da cache primeiro
    $posts = get_transient('featured_posts_query');

    if (false === $posts) {
        $posts = new WP_Query([
            'posts_per_page' => 5,
            'no_found_rows'  => true, // Ignorar o overhead se a paginação não for necessária
            'post_status'    => 'publish',
        ]);

        // Guardar na cache por 12 horas
        set_transient('featured_posts_query', $posts, 12 * HOUR_IN_SECONDS);
    }

    return $posts;
}

O argumento no_found_rows merece atenção. Por predefinição, o WP_Query pede ao MySQL que conte todas as linhas correspondentes para poder construir as ligações de paginação. Um widget de “últimos cinco artigos” nunca pagina, por isso essa contagem é puro trabalho extra, e desativá-la retira esse trabalho a cada pedido que executa o widget.

Quando usar transients e quando usar Redis:

• Transients: para resultados de consultas com um tempo de expiração claro. Sem uma cache de objetos persistente ficam guardados na tabela wp_options; com uma instalada, o WordPress guarda-os em Redis ou Memcached.
• Redis ou Memcached: para uma cache de objetos persistente que sobrevive entre pedidos HTTP. Compensa em sites com muito tráfego, lojas WooCommerce e sites de membros, onde muitas páginas não podem ser servidas a partir de uma cache de página completa porque o visitante tem sessão iniciada ou um carrinho.

#2. Ir além da simples compressão

“Comprimir” imagens é apenas metade do trabalho. Deve apostar no suporte a AVIF e no dimensionamento responsivo para garantir que os utilizadores móveis não descarregam ficheiros dimensionados para desktop.

Uma estratégia de imagens por camadas:

1. Formato: sirva AVIF primeiro, WebP como alternativa e JPEG ou PNG apenas como último recurso.
2. Dimensões: use srcset e sizes para que o navegador escolha um ficheiro adequado à largura do ecrã.
3. Carregamento diferido: aplique loading="lazy" às imagens abaixo da área visível inicial e nunca à própria imagem LCP, que deve carregar o mais cedo possível.
4. CDN de imagens: serviços como Cloudinary ou imgix podem redimensionar e converter imagens em tempo real, se não quiser gerar cada variante.

<!-- Exemplo de uma imagem responsiva bem construída -->
<picture>
  <source type="image/avif" srcset="imagem-400.avif 400w, imagem-800.avif 800w, imagem-1200.avif 1200w">
  <source type="image/webp" srcset="imagem-400.webp 400w, imagem-800.webp 800w, imagem-1200.webp 1200w">
  <img src="imagem-800.jpg" alt="Descrição" loading="lazy" width="800" height="450"
       srcset="imagem-400.jpg 400w, imagem-800.jpg 800w, imagem-1200.jpg 1200w"
       sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px">
</picture>

Os atributos explícitos width e height importam tanto como o formato. Permitem ao navegador reservar o espaço antes de o ficheiro chegar, e é isso que mantém o CLS baixo.

#3. Otimizar o buffer de saída

Se não estiver a usar um plugin de cache dedicado, pode implementar a compressão Gzip ao nível do PHP, embora fazê-lo via .htaccess ou configuração do Nginx seja normalmente mais eficiente.

// Lógica básica de compressão caso a configuração ao nível do servidor não esteja disponível
add_action('init', function() {
    if (!ob_start("ob_gzhandler")) ob_start();
});

#4. Auditar os plugins antes de tudo

Uma auditoria de plugins é normalmente a alteração com melhor retorno para o esforço. Os sites acumulam plugins ao longo de anos, cada um instalado para uma campanha ou uma funcionalidade, e ninguém verifica quanto custam em cada pedido.

Como fazer a auditoria:

1. Instale o Query Monitor: mostra quantas consultas à base de dados cada plugin gera, quanta memória usa e quanto tempo demoram os seus hooks na página que está a ver.
2. Encontre os pesados: ordene por número de consultas e tempo e procure plugins que fazem muito trabalho em páginas onde não têm função visível.
3. Pondere alternativas: para cada plugin pesado, pergunte se um plugin mais leve faz o mesmo ou se a funcionalidade é pequena o suficiente para algumas linhas no tema.
4. Desative o que não precisa: plugins de segurança duplicados, construtores de formulários que ninguém usa, um plugin de slider que serve uma única página.

Plugins que muitas vezes custam mais do que dão:

• Construtores de páginas (Elementor, Divi) a carregar os seus recursos em páginas que não foram construídas com eles.
• Plugins de partilha social que carregam scripts em todas as páginas.
• Plugins de SEO com todos os módulos opcionais ativados.
• Plugins de estatísticas que gravam cada visita na base de dados do WordPress.

#5. Limpar a base de dados

Com o tempo, a base de dados do WordPress acumula dados que tornam as consultas mais lentas:

• Revisões de artigos: o WordPress guarda uma revisão sempre que grava, por isso um artigo editado muitas vezes arrasta uma longa cauda de cópias antigas.
• Transients expirados: podem ficar em wp_options até que algo os limpe.
• Opções órfãs: plugins desinstalados deixam muitas vezes as suas definições para trás, por vezes com autoload ativo, e são carregadas em cada pedido.
• Metadados órfãos: metadados de artigos, utilizadores e comentários que apontam para registos que já não existem.

// Limitar as revisões de artigos no wp-config.php
define('WP_POST_REVISIONS', 5);

// Ou desativá-las por completo (não recomendado em sites com vários editores)
define('WP_POST_REVISIONS', false);

Ferramentas para o trabalho:

• WP-Optimize: limpeza agendada de revisões, transients e dados órfãos.
• phpMyAdmin: para consultas manuais quando sabe exatamente o que está a apagar.
• WP-CLI: wp transient delete --expired e wp db optimize na linha de comandos, a opção mais segura em sites com tabelas grandes.

Faça uma cópia de segurança da base de dados antes de qualquer limpeza. Uma consulta errada contra wp_postmeta não se resolve com um botão de anular.

#6. Colocar uma CDN à frente do site

Uma CDN (content delivery network) copia os seus ficheiros estáticos para servidores em todo o mundo, para que os visitantes os descarreguem de um local próximo em vez do servidor de origem.

O que uma CDN dá a um site WordPress:

• TTFB mais baixo para ficheiros estáticos: os ficheiros vêm do ponto de presença mais próximo.
• Menos carga na origem: imagens, CSS e JavaScript deixam de chegar ao seu servidor.
• Proteção DDoS: a maioria das CDN absorve o tráfego de ataque antes de chegar até si.

Um ponto de partida sensato no Cloudflare para WordPress:

1. Defina SSL/TLS como “Full (strict)” para que o tráfego vá cifrado até ao seu servidor.
2. Crie regras de cache para ficheiros estáticos e ignore a cache em /wp-admin/, para utilizadores com sessão iniciada e nas páginas de carrinho e checkout do WooCommerce.
3. Mantenha a compressão Brotli ativa.
4. Nos planos pagos, considere o Polish para otimização automática de imagens, ou continue a fazê-la no WordPress se já gera AVIF.

#Como monitorizar o desempenho do WordPress

O trabalho de desempenho não é uma tarefa única. Os sites WordPress mudam constantemente com novos conteúdos, atualizações de plugins e ajustes de configuração, e sem monitorização a velocidade volta a degradar-se aos poucos. Para alertas e configurações de longo prazo em sites maiores, veja o nosso guia de monitorização de desempenho WordPress.

Ferramentas de monitorização que vale a pena usar:

• Google PageSpeed Insights: verificações pontuais dos Core Web Vitals de um único URL.
• Google Search Console: dados de campo de utilizadores reais do Chrome, agrupados por padrão de URL.
• GTmetrix: uma cascata detalhada de todos os pedidos da página.
• Query Monitor: depuração da base de dados e dos hooks numa cópia de staging ou de desenvolvimento.

Os scripts de terceiros merecem aqui uma verificação à parte. Na UE, a Diretiva relativa à privacidade e às comunicações eletrónicas (2002/58/CE, artigo 5.º, n.º 3) exige consentimento antes de guardar cookies não essenciais (texto no EUR-Lex), por isso os scripts de rastreio só devem carregar depois de o visitante os aceitar. Bem feito, isso também os mantém fora do primeiro carregamento para todos os que ainda não clicaram no banner.

Métricas a acompanhar:

Os limites de LCP, INP e CLS são os valores “bons” publicados pela Google, medidos no percentil 75 dos carregamentos de página (web.dev: Web Vitals). O INP substituiu o FID como Core Web Vital em março de 2024, por isso qualquer relatório que ainda mostre FID está desatualizado. O valor de TTFB é o limite de trabalho deste artigo para decidir quando olhar para o servidor, não um Core Web Vital da Google.

#Checklist para um site WordPress lento

Se o seu site estiver lento, não adivinhe, meça. Utilize o Query Monitor para encontrar chamadas dispendiosas à base de dados e o PageSpeed Insights para identificar scripts que bloqueiam a renderização.

• Verifique a sua contagem de consultas: Está a fazer mais de 100 consultas para um único carregamento de página?
• Audite a sua secção hero: A imagem principal é servida em AVIF ou WebP em vez de PNG/JPEG?
• Teste o seu TTFB: Se for superior a 200 ms, então considere otimizar o alojamento ou a base de dados.
• Reveja os scripts de terceiros: Quantos scripts externos carregam e quanto tempo bloqueiam a thread principal?

Muitas vezes a causa é aquele “plugin simples” que ninguém se lembrou de desativar.

Saiba mais sobre desenvolvimento WordPress profissional. Para o lado da execução, mantemos este tema na auditoria de Core Web Vitals.