Performance WordPress: Core Web Vitals, cache e imagens

Em 2026, “Velocidade” não é apenas sobre o tempo de carregamento da página. É sobre Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), e manter os custos do servidor baixos durante picos de tráfego.

Muitos “guias de velocidade” dizem para instalar um plugin e rezar. Este guia é diferente. Vamos mergulhar na arquitetura de um stack WordPress de alta performance. Vamos corrigir a performance na raiz: O Servidor, A Base de Dados é o Caminho de Renderização.

#Parte 1: O stack do servidor (a fundação)

Não pode corrigir um servidor lento com um plugin. Se o seu Time To First Byte (TTFB) for > 500ms, nenhuma quantidade de minificação de CSS o salvará.

#1. PHP 8.x e jit

Certifique-se de que está a correr PHP 8.3 ou 8.4. O Compilador JIT (Just-In-Time) introduzido no PHP 8.0 está agora maduro. Compila partes do código PHP diretamente em código de máquina, contornando a VM Zend para tarefas intensivas de CPU.

• Ação: Verifique php -v. Se vir 7.4, atualize imediatamente.

#2. Nginx sobre Apache

O Apache é ótimo para compatibilidade (.htaccess), mas o Nginx é rei na concorrência. O Nginx usa uma Arquitetura Orientada a Eventos que lhe permite lidar com 10.000 conexões com baixo uso de memória, enquanto o Apache gera um novo processo/thread para cada pedido.

#3. Object cache (Redis/Valkey)

Este é o maior “desbloqueio” único para sites dinâmicos (WooCommerce). O WordPress naturalmente consulta a base de dados para tudo (opções, utilizadores, post meta). O Redis armazena os resultados destas consultas na RAM.

• Sem Redis: Uma página de login pode executar 50 consultas SQL.
• Com Redis: Executa 0 consultas SQL (busca tudo da RAM).
• Configuração: Use rphan/redis-object-cache ou drop-ins semelhantes.

#Parte 2: O frontend & core web vitals

Os Core Web Vitals da Google são a lei. Em 2026, a métrica que mata a maioria dos sites é o INP (Interaction to Next Paint).

#Resolver o INP (a sensação de “lag”)

O INP mede a rapidez com que o navegador responde após um utilizador clicar. Se tiver uma thread principal massiva bloqueada pela execução de JavaScript, o seu INP sofre.

• O Culpado: Page builders pesados, Scripts de Terceiros não otimizados (widgets de chat, pixels de rastreio).
• A Correção:
  1. Ceder à Thread Principal (Yield to Main Thread): Adiar (defer) JS não essencial.
  2. Web Workers: Mover lógica pesada (ex: cálculos complexos) para fora da thread principal.
  3. Debouncing: Não disparé um pedido de pesquisa PHP a cada tecla premida; espere que o utilizador pare de escrever por 300ms.

#Novos formatos de imagem (AVIF vs WEBP)

O WebP é notícia velha. AVIF é o padrão em 2026. O AVIF oferece 20-30% melhor compressão que o WebP com maior qualidade visual (suporta HDR).

• WordPress 6.5+ suporta AVIF nativamente.
• Ação: Garanta que a sua pipeline de otimização de imagens (ou CDN) cria versões AVIF automaticamente.

#Parte 3: Tuning de base de dados (o assassino silencioso)

Uma tabela wp_options inchada pode colocar um servidor de joelhos.

#1. Opções autoloaded

O WordPress carrega cada opção com autoload='yes' em cada carregamento de página. Se um plugin guarda um blob JSON de 1MB nas opções é o define para autoload, está a carregar 1MB de dados desperdiçados da BD para a RAM em cada visualização.

• Ação: Consulte o seu uso: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; Se for > 800KB, tem um problema.

#2. Garbage collection de transients

Transients são dados de cache temporários (ex: “resultados do Twitter Feed”). Devem expirar e desaparecer. No entanto, se um cron job falhar, acumulam-se para sempre.

• Ação: Use WP-CLI para limpá-los: wp transient delete --expired.

#3. Motores de armazenamento de alta performance

Garanta que as suas tabelas usam InnoDB (ou MyRocks para conjuntos de dados massivos). Nunca use MyISAM (bloqueia a tabela inteira a cada escrita, matando a concorrência).

#Parte 4: A pirâmide da estratégia de cache

1. Cache do Navegador: O cache mais rápido é aquele que nunca faz. Defina longos cabeçalhos Cache-Control (1 ano) para ativos estáticos.
2. CDN / Edge Cache: Cloudflaré ou Fastly a servir o seu HTML de um servidor a 10km do utilizador. Use estratégias Stale-While-Revalidate.
3. Page Cache (Servidor): Nginx FastCGI Cache ou Varnish. Serve HTML da RAM.
4. Object Cache: Redis. Detalhado acima.
5. OpCache: Código PHP compilado para bytecode na RAM.

#Checklist de resumo para 2026

• Servidor corre PHP 8.3+.
• Base de dados usa InnoDB e wp_options está limpa (<1MB autoloaded).
• Object Cache (Redis) está ativo.
• Imagens são servidas como AVIF.
• JavaScript é adiado (deferred) para corrigir o INP.
• Está a medir Real User Metrics (RUM), não apenas pontuações Lighthouse.

Performance é experiência do utilizador. Um site rápido respeita o tempo do seu utilizador.

Veja os nossos serviços de otimização de velocidade WordPress.