Existe uma indústria inteira de conteúdo em torno da otimização de WordPress. “10 plugins para acelerar o seu site”, “5 truques secretos para fazer o seu site voar”, “o plugin de cache definitivo”. A maior parte é ruído.
Depois de otimizar dezenas de sites WordPress, o que aprendi é que a maioria dos problemas de performance vem de 3 fontes. E que a maioria dos “truques” que se lê online ou não faz diferença mensurável, ou é ativamente contraproducente.
Os Core Web Vitals que importam em 2026
O Google alterou os Core Web Vitals em 2024. Hoje, os três que contam são:
- LCP (Largest Contentful Paint): tempo até ao aparecimento do maior elemento visível. Objetivo: abaixo de 2,5 segundos
- INP (Interaction to Next Paint): tempo de resposta às interações do utilizador. Objetivo: abaixo de 200ms
- CLS (Cumulative Layout Shift): estabilidade visual durante o carregamento. Objetivo: abaixo de 0,1
O INP substituiu o FID em março de 2024 e é significativamente mais exigente. Muitos sites que tinham FID verde passaram a ter INP vermelho.
Importante: o Google mede os Core Web Vitals com dados reais de utilizadores (CrUX), não com testes sintéticos. O seu PageSpeed Insights pode mostrar 95 nos testes, mas se os utilizadores reais tiverem dispositivos lentos e ligações 4G, é a experiência deles que conta.
Os 3 problemas que resolvem a maioria dos casos
1. Alojamento inadequado
Este é, de longe, o problema mais subestimado. Um site WordPress num alojamento partilhado barato de 3€/mês nunca terá boa performance, independentemente do que faça no código.
Para um site profissional, o mínimo aceitável é alojamento gerido com PHP 8.2+, MySQL 8 ou MariaDB 10.6+, Redis ou Memcached para cache de objetos, HTTP/3, e suporte nativo a cache ao nível do servidor. Isto custa tipicamente entre 15€ a 40€ por mês e faz uma diferença drástica.
Para projetos mais exigentes, VPS ou servidor dedicado com LiteSpeed, Nginx com cache FastCGI, ou stacks especializadas (Cloudways, Kinsta, WP Engine).
2. Imagens não otimizadas
Em quase todos os sites que audito, as imagens representam 60 a 80% do peso total da página. E tipicamente, muitas imagens são servidas no formato errado, tamanho errado, ou sem lazy loading adequado.
Em 2026, o padrão mínimo é:
- Formato WebP ou AVIF (nunca JPEG ou PNG para fotografia web)
- Imagens responsivas com
srcsetesizescorretos - Lazy loading nativo com
loading="lazy"(exceto o LCP, que deve sereager) - Compressão agressiva: qualidade 75-85 é visualmente indistinguível em fotografia
- Dimensões corretas no código para evitar CLS
3. Plugins em excesso
Regra geral: cada plugin ativo acrescenta entre 50ms e 300ms ao tempo de carregamento, dependendo do que faz e de quão bem está escrito. Um site com 40 ou mais plugins é fisicamente incapaz de ter boa performance.
A minha regra pessoal em projetos à medida: máximo de 15 plugins, cada um com uma função clara e justificação. Funcionalidades simples (sliders, acordeões, formulários básicos, partilha em redes sociais) devem ser implementadas no tema, não via plugins.
Por que razão os plugins de cache não chegam
Muitas pessoas instalam o WP Rocket ou o W3 Total Cache e pensam que o problema de performance está resolvido. Não está.
Os plugins de cache resolvem um problema específico: impedir que o WordPress gere a página dinamicamente em cada pedido. Isto é útil, mas não resolve o LCP causado por imagens mal otimizadas, o INP causado por JavaScript pesado, ou o CLS causado pela ausência de dimensões nos elementos multimédia.
O cache é parte da solução. Não é a solução.
Performance e acessibilidade: duas faces da mesma moeda
Um ponto raramente discutido: a otimização de performance e a acessibilidade andam de mãos dadas. Um site rápido com estrutura semântica limpa, lazy loading adequado e JavaScript não bloqueante é também um site mais acessível para utilizadores com tecnologias de apoio.
Para projetos que requerem conformidade com WCAG 2.1 AA (cada vez mais obrigatória nos setores público e regulado), a otimização de performance deve ser pensada em conjunto com a acessibilidade desde o início. É possível obter pontuações elevadas em ambas, mas exige disciplina desde a arquitetura inicial do tema.
A checklist que uso antes de entregar qualquer projeto
- Alojamento com PHP 8.2+, MySQL 8+, HTTP/3
- Cache de objetos ativa (Redis ou Memcached)
- Cache de páginas ao nível do servidor (LiteSpeed, Nginx FastCGI) ou plugin dedicado
- Imagens em WebP/AVIF, com srcset e dimensões explícitas
- Fontes com
font-display: swape preload da fonte principal - CSS crítico inline, restante com
media="print" onload - JavaScript não crítico com
deferou carregamento condicional - Sem plugins redundantes ou duplicados
- HTTPS com HSTS ativo
- Compressão Brotli ou Gzip
- CDN para assets estáticos (Cloudflare no mínimo)
- Core Web Vitals verdes no PageSpeed Insights e CrUX
- Pontuação de acessibilidade adequada aos requisitos do projeto
Ferramentas que uso para medir
- PageSpeed Insights: dados de laboratório + dados reais de utilizadores (CrUX)
- WebPageTest: análise detalhada por pedido, filmstrip visual
- Chrome DevTools Lighthouse: auditoria local
- Google Search Console: Core Web Vitals em utilizadores reais, por URL
- GTmetrix: dashboard histórico e comparação
- Query Monitor (plugin): identificar queries lentas, hooks pesados
Conclusão: performance não é magia, é disciplina
Sites rápidos não se constroem com plugins mágicos nem com truques secretos. Constroem-se com atenção ao detalhe em cada decisão: escolha do alojamento, arquitetura do tema, disciplina no uso de plugins, otimização de media e testes contínuos.
Se o seu site é lento e pretende um diagnóstico técnico, posso realizar uma auditoria de performance. Receberá um relatório com os problemas identificados, prioridades e impacto estimado para cada otimização.
