Otimização de velocidade WordPress, guia WPO completo | WPPoland

Mariusz Szatkowski

Otimização completa do WordPress, como acelerar o site? (WPO)

Última verificação: 12 de outubro de 2026

22 min de leitura

Guia

500+ projetos WP

“O meu WordPress está lento”. Ouvi esta frase milhares de vezes. E normalmente a resposta não é “instale mais um plugin”, mas “arrume o que tem”. Otimização de performance (WPO, Web Performance Optimization) atravessa base de dados, código, cache, servidor e entrega de ficheiros ao mesmo tempo. Comprimir imagens não chega se a base de dados “tosse” a cada consulta.

Na wppoland.com ouvimos esta queixa todas as semanas, e o caminho passa por perceber onde está o estrangulamento e corrigi-lo na origem. A WPO é uma disciplina sistemática, feita por camadas, que toca no alojamento, no código, nos recursos e no comportamento do navegador. Este guia percorre cada camada, da configuração do servidor até à última pintura no ecrã, com números reais e código que pode aplicar hoje.

Aqui está o mapa completo de otimização WordPress, do básico às técnicas avançadas.

Saiba mais sobre os serviços de desenvolvimento WordPress da WPPoland.

#Como a velocidade do site WordPress afeta as conversões

A velocidade mede dinheiro. A investigação da própria Google mostra que, quando o tempo de carregamento de uma página passa de 1 para 3 segundos, a probabilidade de rejeição aumenta 32%. Aos 5 segundos, essa probabilidade sobe para 90%. No comércio eletrónico, a Amazon mediu que cada 100 ms de latência adicional lhe custava 1% das vendas (Greg Linden, Amazon, 2006).

As Core Web Vitals passaram a ser um sinal de classificação confirmado pela Google em 2021. Os sites que cumprem os três limites (LCP abaixo de 2,5 segundos, CLS abaixo de 0,1 e INP abaixo de 200 ms) recebem um impulso de classificação nos resultados de pesquisa em dispositivos móveis. Segundo os dados do Chrome User Experience Report (CrUX) do final de 2025, apenas 43% das origens WordPress cumprem as três Core Web Vitals em dispositivos móveis. Mais de metade dos sites WordPress está, portanto, a desperdiçar potencial de classificação.

O estudo “Milliseconds Make Millions” da Deloitte concluiu que uma melhoria de 0,1 segundos na velocidade do site em dispositivos móveis aumentou as taxas de conversão em 8,4% no retalho e em 10,1% nos sites de viagens. Quando faz as contas com o seu próprio tráfego, o custo de um site lento torna-se concreto. Uma loja WooCommerce que fatura 50 000 € por mês pode estar a perder 4000 a 5000 € todos os meses por ter um site que carrega em 4 segundos em vez de 2.

A otimização da velocidade é o investimento técnico com maior retorno que pode fazer, e não convém adiá-lo.

Lembre-se: um site rápido não é um objetivo em si. É uma ferramenta para maior conversão e melhor SEO. Cada 100ms de atraso custa-lhe clientes perdidos.

#Como medir a velocidade do site WordPress

Nunca comece a otimizar sem uma linha de base. Precisa de dados, não de palpites.

O PageSpeed Insights (PSI) dá-lhe dados de laboratório (Lighthouse) e dados de campo (CrUX). Os dados de laboratório servem para depurar, mas são os dados de campo, recolhidos junto de utilizadores reais do Chrome ao longo de 28 dias, que a Google usa para a classificação. Consulte sempre o “Origin Summary” para ver o desempenho de todo o domínio, e não apenas de páginas individuais.

O WebPageTest (webpagetest.org) oferece gráficos em cascata, vistas em película e testes em vários passos. Execute os testes a partir de um local próximo do seu público-alvo. Use a “repeat view” para ver como a cache afeta os carregamentos seguintes. O gráfico em cascata é a melhor ferramenta de diagnóstico para identificar scripts de terceiros lentos e recursos que bloqueiam a renderização.

O separador Performance do Chrome DevTools permite gravar um carregamento completo da página e inspecionar cada frame, cada mudança de layout e cada tarefa longa. Use o separador “Coverage” (Ctrl+Shift+P e depois escreva “Coverage”) para encontrar CSS e JavaScript não utilizados: é assim que identifica candidatos a remover ou a adiar.

O CrUX Vis (cruxvis.withgoogle.com) mostra a evolução histórica dos dados através da CrUX History API. A Google descontinuou o antigo CrUX Dashboard em Looker Studio a favor desta ferramenta. Acompanhe as suas Core Web Vitals ao longo do tempo, porque uma pontuação isolada não diz nada sem contexto. Configure monitorização automática com ferramentas como SpeedCurve ou Calibre para apanhar regressões antes de chegarem à produção.

Registe as suas linhas de base: TTFB, LCP, CLS, INP, peso total da página e número de pedidos. Sem estes números, não consegue provar que as otimizações resultaram.

#Quais fundamentos de hosting e DNS aceleram o WordPress

Se o seu servidor responde lentamente (TTFB > 600ms), nenhum plugin vai ajudar.

Versão PHP: PHP 8.3 ou superior, como recomenda o WordPress.org.
Base de dados: MySQL 8.0 ou superior ou MariaDB 10.11 ou superior.
Protocolo: HTTP/2 ou HTTP/3 (QUIC) é obrigatório. Permite ao navegador descarregar muitos ficheiros ao mesmo tempo por uma única ligação.

Como referência, o Time to First Byte (TTFB) deve ficar abaixo de 200 ms para páginas em cache e abaixo de 600 ms para respostas dinâmicas.

#Qual a versão de PHP mais rápida para WordPress

O WordPress.org recomenda PHP 8.3 ou superior. O PHP 8.1 e os ramos mais antigos já não recebem correções de segurança, por isso ficar parado neles custa velocidade e segurança ao mesmo tempo. Quanto um site concreto ganha com a atualização depende do tema, dos plugins e da cache. Meça o TTFB antes e depois da mudança em vez de confiar num multiplicador. Verifique a sua versão de PHP com phpinfo() ou em Ferramentas, Saúde do site, Informação, e teste a atualização primeiro em staging: plugins antigos são a origem habitual de erros fatais depois de um salto de versão do PHP.

#Como configurar o OPcache para WordPress

O OPcache compila os scripts PHP em bytecode e guarda-os em memória partilhada. Ative-o e ajuste estes valores no php.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128M

A definição jit=1255 ativa o tracing JIT no PHP 8.x, o que beneficia operações pesadas para o CPU, como a construção de páginas.

#Cache de objetos com Redis ou Memcached

Por defeito, o WordPress guarda transients, resultados de consultas e dados de sessão na tabela wp_options. O Redis ou o Memcached passam estes dados para armazenamento em memória, o que reduz drasticamente as consultas à base de dados. Uma página WordPress típica que dispara 50 a 80 consultas pode descer para 5 a 10 com uma cache de objetos persistente. Instale a extensão PHP redis, acrescente WP_REDIS_HOST ao wp-config.php e use um drop-in como o object-cache.php do plugin Redis Object Cache.

#HTTP/2, HTTP/3 e CDN para WordPress

A multiplexação do HTTP/2 elimina o antigo problema de bloqueio head-of-line do HTTP/1.1. O HTTP/3 (QUIC) vai mais longe, com estabelecimento de ligação sem ida e volta e melhor tratamento da perda de pacotes. A Cloudflare, a Fastly e a AWS CloudFront já suportam HTTP/3.

Coloque os seus recursos estáticos (imagens, CSS, JS, fontes) em servidores de extremidade da CDN. No WordPress, configure a CDN para guardar em cache páginas HTML completas para visitantes sem sessão iniciada: só isto pode baixar o TTFB para menos de 50 ms em todo o mundo.

#Porque é que o alojamento partilhado torna o WordPress lento

O alojamento partilhado é o principal estrangulamento que encontramos na wppoland.com. Servidores sobrecarregados, versões de PHP desatualizadas e falta de suporte para cache de objetos tornam a otimização quase impossível. Mude para alojamento WordPress gerido ou para um VPS com uma configuração NGINX/LiteSpeed adequada.

#Quais truques de programador aceleram o WordPress

Bloquear Hotlinking: Não deixe outros sites roubar a sua largura de banda ao mostrar as suas imagens nas suas páginas.
CDN (Content Delivery Network): Se tem tráfego de todo o mundo, use Cloudflare para servir ficheiros do servidor mais próximo do utilizador.

#Como otimizar o backend e a base de dados WordPress

É aqui que acontece a “magia” que não vê mas sente quando trabalha no painel de admin. As bases de dados WordPress acumulam lixo com o tempo: revisões de posts, metadados órfãos, transients expirados e comentários de spam aumentam o tamanho das tabelas e tornam as consultas mais lentas.

Revisões: O WordPress por defeito guarda versões infinitas de cada post. Se editar um post 100 vezes, tem 100 cópias na base de dados. Limite isto no wp-config.php: define( 'WP_POST_REVISIONS', 5 );
Transients: Limpe os “transients” antigos (dados temporários) da base de dados. Plugins frequentemente deixam lixo lá.
Heartbeat API: Limite o “pulso” do WordPress (guardar automático, notificações admin) com o plugin “Heartbeat Control” para reduzir a carga do CPU do servidor.

#Como limpar revisões, transients e opções autoload

No mesmo wp-config.php, pode também esvaziar o lixo automaticamente ao fim de 14 dias:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );

Os transients expirados acumulam-se quando os plugins não limpam o que deixam para trás. Execute este SQL para ver quanto pesam as opções carregadas automaticamente:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Se o resultado ultrapassar 1 MB, tem um problema. Identifique as linhas mais pesadas com:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Os culpados habituais são definições de plugins abandonados, dados serializados de widgets e opções de tema inchadas. Remova o que não precisa.

#Como encontrar consultas lentas à base de dados

Use o plugin Query Monitor para identificar consultas lentas durante o carregamento da página. Procure consultas sem índices adequados, consultas executadas dentro de ciclos (o problema N+1) e consultas que carregam dados que nunca são apresentados. Nas consultas personalizadas, use sempre WP_Query com fields, posts_per_page e no_found_rows => true específicos quando não precisa de paginação:

$query = new WP_Query( [
    'post_type'      => 'product',
    'posts_per_page' => 10,
    'no_found_rows'  => true,
    'fields'         => 'ids',
] );

O parâmetro no_found_rows evita a chamada dispendiosa SQL_CALC_FOUND_ROWS, o que pode reduzir para metade o tempo da consulta em tabelas grandes.

#WP-Optimize ou limpeza manual da base de dados

O WP-Optimize é um plugin sólido para limpezas agendadas de revisões, rascunhos, posts no lixo, comentários de spam e transients. Nos sites em que precisa de controlo total, combine uma limpeza manual em SQL com eventos agendados no wp-cron. O que conta é a regularidade: faça a manutenção da base de dados todas as semanas, e não uma vez por ano quando algo avaria.

#Como otimizar o frontend WordPress (o que o utilizador vê)

Aqui lutamos pela pontuação no PageSpeed Insights e Core Web Vitals.

Minificação: Remova espaços desnecessários e comentários de CSS/JS/HTML. (Plugins como Autoptimize ou WP Rocket fazem isto).
Defer JS: Empurre o carregamento JavaScript para o fim (após o HTML carregar) para não bloquear a renderização da página.
Fontes: Carregue fontes Google localmente ou use font-display: swap para que o texto seja visível imediatamente, antes da fonte bonita carregar.

As secções seguintes detalham cada uma destas frentes: imagens, CSS e JavaScript, cache e fontes.

#Como otimizar imagens no WordPress

As imagens são a maior parcela do peso de uma página: o Web Almanac 2025 coloca-as em cerca de 37% da página mediana em dispositivos móveis. Otimizá-las é a maior melhoria isolada no tempo de carregamento.

#WebP ou AVIF para imagens WordPress

O WebP produz ficheiros 25 a 35% mais pequenos do que o JPEG com qualidade visual equivalente. O AVIF vai mais longe: 30 a 50% mais pequeno do que o WebP em conteúdo fotográfico. O suporte dos navegadores para WebP é hoje universal (mais de 98% de cobertura global). O suporte para AVIF ronda os 92% e continua a subir.

Comparação real de tamanhos de ficheiro num projeto da wppoland.com:

Formato	Tamanho do ficheiro	Qualidade
JPEG (original)	285 KB	Referência
WebP	192 KB	Visualmente idêntica
AVIF	128 KB	Visualmente idêntica

Uma redução de 55% só com a mudança de formato. Multiplique isto por 40 imagens numa página e poupa megabytes.

#Imagens responsivas e lazy loading

O WordPress gera vários tamanhos de cada imagem no carregamento. Use os atributos srcset e sizes para que o navegador descarregue a imagem com o tamanho adequado. Desde o WordPress 5.5, o atributo loading="lazy" é acrescentado automaticamente às imagens. Nas imagens de destaque acima da dobra, remova o lazy loading para não atrasar o LCP:

add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
    if ( str_contains( $image, 'hero-image' ) ) {
        return false; // Desativa o lazy loading na imagem de destaque
    }
    return $value;
}, 10, 3 );

#CDN de imagens para WordPress

Serviços como Cloudflare Images, imgix e Bunny Optimizer transformam as imagens em tempo real: redimensionam, convertem para WebP/AVIF e removem metadados na extremidade da rede. Deixa de ser preciso gerar dezenas de miniaturas no seu servidor. Acrescente fetchpriority="high" ao elemento de imagem do LCP para que o navegador dê prioridade ao seu descarregamento:

<img src="hero.webp" fetchpriority="high" width="1200" height="630"
     alt="WordPress performance optimization dashboard">

#Como remover CSS e JavaScript que bloqueiam a renderização

Os recursos que bloqueiam a renderização são a causa mais comum de maus resultados no LCP. O navegador não consegue pintar píxeis enquanto não analisar todo o CSS e JavaScript síncrono no <head>.

#Como carregar CSS não crítico de forma assíncrona

Tire o CSS não crítico do <head> e carregue-o de forma assíncrona:

<link rel="preload" href="/css/below-fold.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/below-fold.css"></noscript>

No JavaScript, use defer para scripts que precisam de acesso ao DOM e async para scripts independentes, como os de análise:

add_filter( 'script_loader_tag', function( $tag, $handle ) {
    $defer_scripts = [ 'comment-reply', 'contact-form', 'analytics' ];
    if ( in_array( $handle, $defer_scripts, true ) ) {
        return str_replace( ' src=', ' defer src=', $tag );
    }
    return $tag;
}, 10, 2 );

#Como colocar o CSS crítico inline

Extraia o CSS necessário para apresentar o conteúdo acima da dobra e coloque-o diretamente no <head>. Ferramentas como o Critical (de Addy Osmani) ou o gerador de CSS crítico do WP Rocket automatizam o processo. O CSS inline deve ficar abaixo de 14 KB (o tamanho da primeira janela de congestionamento TCP), para que o navegador apresente conteúdo útil logo na primeira resposta do servidor.

#Como remover CSS não utilizado com PurgeCSS

Use o PurgeCSS ou o UnCSS para analisar as páginas renderizadas e retirar as regras CSS que não são usadas. Um site WordPress típico com um construtor de páginas carrega 300 a 500 KB de CSS, dos quais 70 a 80% não são usados numa dada página. Depois da limpeza:

# Exemplo de configuração do PurgeCSS
purgecss --css ./style.css \
         --content ./**/*.php ./**/*.html \
         --output ./style.purged.css

Vemos regularmente ficheiros CSS descerem de 400 KB para menos de 60 KB depois de um tree shaking bem feito. Combine isto com minificação (cssnano) e compressão Brotli para obter a máxima poupança.

#Como retirar scripts e estilos de plugins

Muitos plugins carregam os seus recursos em todas as páginas, mesmo onde não são necessários. Retire-os da fila de forma condicional:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7-css' );
        wp_dequeue_script( 'contact-form-7-js' );
    }
}, 100 );

#Camadas de cache do WordPress, da CDN ao navegador

A cache é a técnica de desempenho mais eficaz, porque elimina trabalho por completo. Uma boa estratégia de cache funciona por camadas.

#Cache de página

Guarde o HTML completamente renderizado para que o WordPress e o PHP não sejam executados a cada pedido. A cache FastCGI do NGINX, a cache do LiteSpeed ou soluções em plugin como o WP Super Cache e o WP Rocket servem HTML estático aos visitantes sem sessão iniciada. Uma página que demora 800 ms a gerar de forma dinâmica pode ser servida em 10 ms a partir da cache.

#Cache de objetos

O Redis ou o Memcached guardam em memória os resultados de consultas à base de dados, chamadas a APIs e valores calculados. A cache de objetos persistente é a camada com mais impacto para utilizadores com sessão iniciada e para páginas dinâmicas que não podem ir inteiras para a cache de página.

#Cabeçalhos Cache-Control para recursos estáticos

Defina cabeçalhos Cache-Control adequados para os recursos estáticos. Os recursos imutáveis (ficheiros CSS/JS com versão) devem ficar em cache de forma agressiva:

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Nas páginas HTML, use tempos de cache mais curtos ou stale-while-revalidate para equilibrar atualidade e velocidade:

Cache-Control: public, max-age=300, stale-while-revalidate=86400

#Cache na CDN

A sua CDN deve guardar os recursos estáticos em cache nos pontos de presença de todo o mundo. Configure a limpeza da cache para disparar quando o conteúdo é atualizado. O APO (Automatic Platform Optimization) da Cloudflare para WordPress guarda páginas HTML completas na extremidade da rede e limpa-as automaticamente quando publica ou atualiza conteúdo.

As camadas funcionam por esta ordem: cache de extremidade da CDN, depois cache de página no servidor, depois cache de objetos e, por fim, cache do navegador. Cada camada apanha o que a anterior deixa passar.

#Como otimizar o carregamento de fontes web no WordPress

As fontes web prejudicam o desempenho sem darem nas vistas. Um único pedido ao Google Fonts pode acrescentar 200 a 500 ms ao caminho crítico de renderização, por causa da consulta DNS, da ligação e do descarregamento a partir de uma origem de terceiros.

#Como alojar as fontes localmente no WordPress

Descarregue os ficheiros das fontes e sirva-os a partir do seu próprio domínio. Elimina assim o custo da ligação a terceiros e permite que a CDN os guarde em cache. Use exclusivamente o formato woff2: tem mais de 99% de suporte nos navegadores e oferece a melhor compressão.

@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var.woff2') format('woff2');
    font-weight: 100 900;
    font-display: swap;
    unicode-range: U+0000-024F; /* Subconjunto latino */
}

#Como usar font-display swap e pré-carregar fontes

A declaração font-display: swap evita o texto invisível (FOIT) e melhora o LCP.

Pré-carregue a fonte principal para dar prioridade ao seu descarregamento:

<link rel="preload" href="/fonts/inter-var.woff2" as="font"
      type="font/woff2" crossorigin>

#Fontes variáveis e subconjuntos

As fontes variáveis reúnem vários pesos e estilos num único ficheiro. Em vez de carregar ficheiros separados para regular (400), medium (500), semibold (600) e bold (700), um único ficheiro de fonte variável cobre toda a gama. A fonte variável Inter ocupa 97 KB em woff2, contra 4 ficheiros estáticos separados que somam 180 KB.

Crie subconjuntos das fontes com apenas os intervalos de caracteres de que precisa. Um subconjunto só latino pode reduzir o tamanho do ficheiro em 40 a 60% face à cobertura Unicode completa. Ferramentas como o glyphhanger ou o parâmetro &text= da API do Google Fonts tornam isto simples.

#Como corrigir LCP, CLS e INP no WordPress

As Core Web Vitals da Google são as três métricas com impacto direto na classificação nas pesquisas. Perceber o que faz cada uma falhar permite otimizar com precisão.

#Como melhorar o LCP

O LCP mede a rapidez com que o maior elemento visível (normalmente uma imagem de destaque ou um título) é apresentado. O objetivo é ficar abaixo de 2,5 segundos.

Causas comuns de um mau LCP:

Resposta lenta do servidor (TTFB elevado)
CSS e JavaScript que bloqueiam a renderização
Imagens de destaque não otimizadas e sem fetchpriority="high"
Imagens do LCP com lazy loading (retire loading="lazy" das imagens acima da dobra)
Fontes web que bloqueiam a apresentação do texto

Corrija o LCP reduzindo o TTFB com cache, colocando o CSS crítico inline, pré-carregando a imagem do LCP e usando fetchpriority="high" no elemento de destaque.

#Como reduzir o CLS

O CLS mede a estabilidade visual, ou seja, quanto o layout da página se desloca de forma inesperada durante o carregamento. O objetivo é ficar abaixo de 0,1.

Causas comuns de um mau CLS:

Imagens e iframes sem atributos width e height explícitos
Conteúdo injetado dinamicamente (anúncios, incorporações, banners de cookies)
Fontes web que provocam o reajuste do texto (FOUT)
CSS carregado tarde que altera as dimensões dos elementos

Defina sempre as dimensões dos elementos multimédia. Use aspect-ratio no CSS para contentores responsivos. Reserve espaço para anúncios e conteúdo dinâmico com marcadores de posição com min-height.

#Como melhorar o INP

O INP substituiu o FID em março de 2024 e mede a capacidade de resposta ao longo de todo o ciclo de vida da página, e não apenas na primeira interação. O objetivo é ficar abaixo de 200 ms.

Causas comuns de um mau INP:

Tarefas JavaScript longas que bloqueiam a thread principal
Event handlers pesados em eventos de clique, scroll ou input
DOM demasiado grande (mais de 1500 nós)
Scripts de terceiros a disputar tempo da thread principal

Divida as tarefas longas em partes mais pequenas com requestIdleCallback ou scheduler.yield(). Use delegação de eventos em vez de ligar listeners a centenas de elementos individuais. Audite os scripts de terceiros sem contemplações: cada um que remove devolve tempo à thread principal.

// Divide tarefas longas com pontos de cedência
async function processItems(items) {
    for (const item of items) {
        processItem(item);
        // Cede o controlo ao navegador entre itens
        await scheduler.yield();
    }
}

#Por onde começar a otimizar a velocidade do WordPress

Os três níveis deste mapa não pesam o mesmo em todos os sites, por isso a primeira decisão é descobrir onde está o atraso.

Meça o TTFB antes de tudo. Se passa dos 600ms, o trabalho começa no Nível 1 (alojamento e servidor): confirme a versão do PHP, a versão do MySQL ou do MariaDB e se o servidor já usa HTTP/2 ou HTTP/3. Minificar CSS nesse cenário não resolve nada.

Se o TTFB está bem e a lentidão se sente sobretudo no painel de administração, o problema costuma estar no Nível 3 (backend e base de dados). Verifique quantas revisões guarda por post, limpe os transients antigos e limite a Heartbeat API.

Se o servidor responde depressa, o painel é ágil e o PageSpeed Insights continua no vermelho, está no Nível 2 (frontend): JavaScript que bloqueia a renderização, fontes que não usam font-display: swap, CSS e JS por minificar.

Mude uma coisa de cada vez e volte a medir depois de cada alteração. Assim sabe o que resultou e evita acumular plugins de otimização que fazem o mesmo trabalho em duplicado, o contrário do conselho de arrumar o que já tem.

#Lista de verificação para otimizar a velocidade do WordPress

Use esta lista passo a passo em todos os projetos WordPress. A ordem conta: comece pelo servidor e avance para o navegador.

#Camada do servidor

Atualizar para PHP 8.3+ com OPcache e JIT ativos
Configurar o MySQL/MariaDB com um buffer pool de tamanho adequado
Ativar HTTP/2 (ou HTTP/3, se suportado)
Configurar Redis ou Memcached para a cache de objetos
Sair do alojamento partilhado para alojamento gerido ou VPS

#Camada da base de dados

Limitar as revisões de posts a 5
Apagar transients expirados e metadados órfãos
Auditar as opções autoload (manter abaixo de 800 KB)
Acrescentar índices para consultas meta personalizadas

#Camada dos recursos

Converter imagens para WebP/AVIF com alternativas adequadas
Acrescentar width, height e fetchpriority="high" às imagens do LCP
Retirar loading="lazy" das imagens acima da dobra
Alojar as fontes localmente em woff2 com font-display: swap
Pré-carregar as fontes críticas e as imagens do LCP

#Camada do código

Colocar o CSS crítico inline (abaixo de 14 KB)
Aplicar defer ou async a todo o JavaScript não crítico
Retirar o CSS/JS de plugins nas páginas onde não é necessário
Remover CSS não utilizado com PurgeCSS
Minificar e comprimir todos os recursos com Brotli

#Camada da cache

Ativar a cache de página completa para visitantes sem sessão iniciada
Configurar a CDN com cabeçalhos de cache adequados
Definir Cache-Control: immutable para recursos estáticos com versão
Aplicar stale-while-revalidate às respostas HTML

#Monitorização

Acompanhar a evolução dos dados de campo de 28 dias no CrUX Vis
Monitorizar as Core Web Vitals na Search Console
Executar o Lighthouse CI no pipeline de implementação
Definir orçamentos de desempenho (peso da página, número de pedidos, objetivo de LCP)

#Como manter o WordPress rápido depois da otimização WPO

Um site otimizado volta a ficar lento se ninguém vigiar o que muda nele, porque cada plugin novo, cada atualização de tema e cada mês de conteúdo acrescentam peso.

Crie uma rotina curta. Depois de instalar ou atualizar um plugin, meça outra vez o TTFB e compare com o valor anterior. Se subiu, sabe exatamente qual foi a alteração responsável.

Na base de dados, a limpeza de transients não é uma tarefa única. Os plugins continuam a deixar lixo, por isso volte a ela com regularidade. Confirme também que o limite de WP_POST_REVISIONS continua no wp-config.php depois de migrações ou mudanças de alojamento.

No frontend, uma atualização do plugin de minificação, como o Autoptimize ou o WP Rocket, pode alterar a ordem dos scripts ou desligar o defer. Reveja o PageSpeed Insights depois de cada atualização desse tipo.

Por fim, acompanhe a versão de PHP oferecida pelo seu alojamento. Quando o servidor disponibilizar uma versão mais recente, teste-a primeiro num ambiente de staging e mude quando os plugins estiverem compatíveis.

A otimização do desempenho é uma prática contínua. Cada plugin novo, cada atualização de tema e cada script de terceiros é uma possível regressão. Meça de forma contínua, otimize de forma sistemática e trate a velocidade como uma funcionalidade central do produto desde o início.

A WPO não termina no relatório do PageSpeed: termina quando o TTFB se mantém depois de um mês de conteúdo novo e de plugins atualizados. Esse acompanhamento faz parte do nosso desenvolvimento e manutenção de WordPress.