Em 2026, “velocidade” não é apenas sobre o tempo de carregamento da página. É sobre Largest Contentful Paint (LCP), 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. É um mapa do stack inteiro: os limiares com que a Google mede a página, as fontes de dados, a camada de servidor, a base de dados, o frontend, a cache e aquilo que o WordPress já faz sozinho no núcleo. As instruções detalhadas de cada tema têm artigos próprios, para os quais apontamos nos sítios certos.
Quais são os limiares dos Core Web Vitals em 2026
Os limiares são publicados pela equipa do Chrome no web.dev e não mudaram desde que o INP substituiu o FID. Segundo a página Web Vitals, o INP tornou-se uma métrica estável dos Core Web Vitals em 2024. Os limites de “bom” e “fraco” estão descritos no artigo Defining the Core Web Vitals metrics thresholds:
| Métrica | O que mede | Bom | Precisa de melhorar | Fraco |
|---|---|---|---|---|
| LCP | renderização do maior elemento de conteúdo | até 2,5 s | 2,5 s a 4 s | acima de 4 s |
| INP | atraso na resposta a uma interação | até 200 ms | 200 ms a 500 ms | acima de 500 ms |
| CLS | deslocamentos de layout | até 0,1 | 0,1 a 0,25 | acima de 0,25 |
Dois detalhes mudam a forma de ler estes números. Primeiro: a avaliação é calculada no percentil 75 das visualizações, separadamente para dispositivos móveis e desktop. Uma página só passa o limiar quando pelo menos três em cada quatro visitas ficam dentro do limite. Segundo o web.dev, o percentil 75 “é menos afetado por valores atípicos” (tradução própria, fonte: web.dev, Defining the Core Web Vitals metrics thresholds). Segundo: telemóvel e desktop são dois resultados separados. Uma loja pode ter o desktop verde e o mobile vermelho, e a Google indexa a versão móvel. Este tema é desenvolvido no artigo sobre desempenho mobile-first.
O web.dev ressalva ainda que as métricas estáveis “não são necessariamente permanentes” e podem ser substituídas. Foi o que aconteceu ao FID. Por isso compensa otimizar as causas (servidor lento, JavaScript pesado, imagens sem dimensões) e não um número concreto.
Os Core Web Vitals afetam o ranking na Google
Sim, mas menos do que sugerem as ofertas de “100/100 no PageSpeed”. A documentação da Google Search Central sobre page experience diz claramente:
“Os Core Web Vitals são usados pelos nossos sistemas de ranking.”
Google Search Central, Understanding page experience in Google Search results (tradução própria)
No mesmo documento, a Google acrescenta que bons resultados no relatório “não garantem que as páginas fiquem no topo dos resultados de pesquisa” e que o motor de pesquisa “procura sempre mostrar o conteúdo mais relevante, mesmo que a experiência da página seja inferior” (tradução própria). Também não existe um único sinal de “page experience”.
A conclusão prática: a performance não empurra conteúdo fraco para cima, mas entre vários resultados igualmente relevantes pode decidir a ordem. O maior ganho da velocidade costuma ver-se no comportamento do utilizador: no carrinho, nos filtros, no formulário de contacto.
De onde vêm os dados: laboratório ou campo
O Lighthouse e a secção de diagnóstico do PageSpeed Insights são dados de laboratório. A documentação do PageSpeed Insights descreve a diferença assim: os dados de laboratório servem para depurar problemas, porque são recolhidos num ambiente controlado, e os dados de campo captam a experiência real dos utilizadores (tradução própria).
Os dados de campo no PSI vêm do Chrome User Experience Report (CrUX) e cobrem os 28 dias anteriores. Daqui resultam três consequências para o WordPress:
- Uma correção publicada hoje só aparece por completo nos dados de campo ao fim de cerca de quatro semanas.
- Uma página nova ou pouco visitada muitas vezes não tem dados próprios. O PSI mostra então os dados do domínio inteiro (origin) e, se também esses faltarem, não mostra dados de utilizadores.
- Uma pontuação Lighthouse de um portátil numa ligação rápida não diz nada sobre o percentil 75 dos utilizadores em telemóvel.
É por isso que a checklist final inclui a medição de Real User Metrics (RUM). O CrUX dá uma imagem com atraso, e um RUM próprio (a biblioteca web-vitals ou uma ferramenta de análise) mostra o efeito de uma alteração mais depressa e por template.
Como montar o stack de servidor para WordPress rápido
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á. O TTFB não é uma das três métricas Core Web Vitals, mas entra no LCP: o navegador não desenha nada antes de receber o HTML.
1. PHP 8.3 ou mais recente
Certifique-se de que está a correr PHP 8.3 ou 8.4. A página de requisitos do WordPress recomenda PHP na versão 8.3 ou superior e MySQL 8.0+ ou MariaDB 10.11+.
- Ação: Verifique
php -v. Se vir 7.4, atualize imediatamente.
O compilador JIT (Just-In-Time) introduzido no PHP 8.0 compila partes do código PHP diretamente em código de máquina, contornando a VM Zend para tarefas intensivas de CPU. Para um WordPress típico, porém, não é o ganho principal. O RFC do JIT indica que o JIT tornou o bench.php mais de duas vezes mais rápido (0,140 s contra 0,320 s), mas que “não parece melhorar significativamente aplicações reais como o WordPress” (tradução própria): 326 pedidos por segundo com JIT contra 315 sem ele. O WordPress passa a maior parte do tempo em consultas à base de dados e em I/O, por isso importam mais uma versão de PHP atual e o OPcache ativo.
2. Nginx em vez de Apache
O Apache é ótimo para compatibilidade (.htaccess), mas o Nginx lida melhor com concorrência. O Nginx usa uma arquitetura orientada a eventos. Segundo o nginx.org, 10.000 conexões keep-alive inativas ocupam cerca de 2,5 MB de memória, enquanto o Apache nos modos clássicos (prefork) trata cada conexão com um processo ou thread próprio.
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: os objetos guardados em cache durante um pedido desaparecem quando ele termina, por isso cada visualização volta a pedir à base de dados as mesmas opções e metadados.
- Com Redis: a cache de objetos sobrevive entre pedidos. À base de dados chegam apenas as consultas cujo resultado ainda não está em cache e as que o WordPress não guarda em cache.
- Configuração: O drop-in mais usado é o plugin Redis Object Cache de Till Krüss (mais de 500.000 instalações ativas), que funciona com os clientes PhpRedis, Predis e Relay. O estado da ligação verifica-se com
wp redis status.
Como melhorar Core Web Vitals no frontend
Os Core Web Vitals da Google são a referência para todo o frontend. Em 2026, a métrica com que mais sites WordPress têm dificuldades é o INP (Interaction to Next Paint).
Como melhorar o INP no WordPress
O INP mede a rapidez com que o navegador responde depois de um utilizador clicar, tocar ou premir uma tecla. O web.dev, no artigo Optimize INP, divide cada interação em três fases: atraso de entrada (da ação do utilizador ao início do tratamento do evento), duração do processamento (execução dos callbacks) e atraso de apresentação (tempo até desenhar o frame seguinte). Cada fase tem uma causa e uma correção diferentes. Se a thread principal estiver 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:
- Ceder à thread principal (yield to main thread): Adiar (defer) JS não essencial e dividir tarefas longas em tarefas menores.
- Web Workers: Mover lógica pesada (ex: cálculos complexos) para fora da thread principal.
- Debouncing: Não dispare um pedido de pesquisa PHP a cada tecla premida; espere que o utilizador pare de escrever por 300ms.
O web.dev nota também que, com um DOM pequeno, a renderização costuma terminar depressa, e que uma árvore DOM grande exige mais trabalho. Os page builders pesados atingem assim o INP duas vezes: com scripts e com o número de nós. Os detalhes, do scheduler.yield() à medição no Chrome DevTools, estão no guia de otimização do INP. Os scripts de terceiros são um tema à parte, tratado no artigo sobre como reduzir o impacto de scripts de terceiros.
Novos formatos de imagem (AVIF vs WEBP)
O AVIF é em 2026 o formato com melhor compressão que o WordPress suporta no núcleo, e o WebP continua a ser uma alternativa razoável de recurso. Segundo o anúncio da equipa do WordPress, as imagens AVIF podem ser até 50% mais pequenas do que JPEG com a mesma qualidade.
- WordPress 6.5+ suporta AVIF nativamente, desde que a biblioteca de imagens do servidor (Imagick ou GD) tenha suporte AVIF. Pode confirmar em Ferramentas, Saúde do site, Informação, secção “Gestão de multimédia”.
- Ação: Garanta que a sua pipeline de otimização de imagens (ou CDN) cria versões AVIF automaticamente. No próprio WordPress serve para isso o filtro
image_editor_output_format, que permite gravar as miniaturas de ficheiros JPEG carregados como AVIF.
O que o WordPress já otimiza sozinho no núcleo
Parte do trabalho que há alguns anos era feito por plugins é hoje feito pelo núcleo. Vale a pena saber o que já funciona antes de instalar mais um plugin que faz o mesmo uma segunda vez.
Prioridade da imagem LCP (WordPress 6.3). Segundo a nota da equipa do WordPress, o núcleo adiciona fetchpriority="high" à imagem que considera o elemento LCP mais provável. A imagem tem de estar na área visível e ter pelo menos 50.000 píxeis de área (largura vezes altura). A mesma imagem nunca recebe ao mesmo tempo loading="lazy". O valor predefinido do filtro wp_omit_loading_attr_threshold passou de 1 para 3, por isso as primeiras imagens da página não são carregadas em lazy loading. Um tema ou plugin que força lazy loading em tudo estraga este mecanismo e atrasa o LCP.
AVIF (WordPress 6.5). Descrito acima: carregamento de ficheiros AVIF e conversão através de image_editor_output_format.
Autoload de opções (WordPress 6.6). Descrito abaixo na parte da base de dados: opções grandes sem flag de autoload explícita deixaram de ser carregadas em cada pedido.
Speculative loading (WordPress 6.8). Segundo a nota para programadores, o núcleo ativa por predefinição o carregamento especulativo no frontend de todos os sites, exceto para utilizadores com sessão iniciada e sites sem ligações permanentes amigáveis. Usa prefetch (não prerender) com intensidade conservative, ou seja, o carregamento começa quando o utilizador começa a clicar num link. Os endereços com parâmetros de consulta são excluídos automaticamente. A Speculation Rules API é suportada pelo Chrome, Edge e Opera, e os outros navegadores ignoram-na. A configuração altera-se com o filtro wp_speculation_rules_configuration (devolver null desativa a funcionalidade para esse pedido), e os caminhos excluem-se com wp_speculation_rules_href_exclude_paths. Um bloco individual pode ser excluído com a classe CSS no-prefetch ou no-prerender. Uma loja em que os links executam ações (adicionar ao carrinho, terminar sessão) deve excluir esses caminhos.
Performance Lab. As próximas funcionalidades do núcleo são testadas no plugin Performance Lab, mantido pela WordPress Performance Team. Gere plugins de funcionalidade separados, entre eles Modern Image Formats, Image Prioritizer, Embed Optimizer, Enhanced Responsive Images, Image Placeholders, Instant Back/Forward, Performant Translations, Speculation Rules e o experimental View Transitions. Acrescenta também testes na Saúde do site, incluindo o cabeçalho Cache-Control: no-store que bloqueia a bfcache, os cabeçalhos de expiração de recursos estáticos e o suporte AVIF. Num staging, é uma forma barata de verificar se o servidor e o tema estão prontos para as próximas versões do WordPress.
Como afinar a base de dados WordPress
Uma tabela wp_options inchada pode colocar um servidor de joelhos.
1. Opções autoload na wp_options
O WordPress carrega cada opção marcada para autoload em cada carregamento de página. Se um plugin guarda um blob JSON de 1MB nas opções e o define para autoload, está a carregar 1MB de dados desperdiçados da BD para a RAM em cada visualização.
O WordPress 6.6 mudou as regras. Segundo a nota da equipa do WordPress, a coluna autoload aceita agora cinco valores: on, off, auto, auto-on e auto-off. Uma opção sem true explícito e maior do que 150.000 bytes deixa de ser carregada automaticamente (o limite altera-se com o filtro wp_max_autoloaded_option_size, que não convém aumentar). A partir da versão 6.6, a Saúde do site avisa quando o tamanho total das opções carregadas automaticamente ultrapassa 800 KB.
- Ação: Consulte o seu uso:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Se for > 800KB, tem um problema. Opções mais antigas podem ainda ter o valoryes, por isso a consulta cobre os dois conjuntos de valores.
2. Limpeza de transients expirados
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.
Com uma cache de objetos persistente ativa (Redis), os transients vão para o Redis e não para a wp_options, por isso este problema afeta sobretudo sites sem cache de objetos.
3. InnoDB em vez de MyISAM
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).
Como estruturar a estratégia de cache WordPress
- Cache do navegador: A cache mais rápida é aquela que nunca se cria. Defina longos cabeçalhos
Cache-Control(1 ano) para ativos estáticos. - CDN / Edge Cache: Cloudflare ou Fastly a servir o seu HTML a partir de um servidor perto do utilizador. Use estratégias Stale-While-Revalidate.
- Page Cache (Servidor): Nginx FastCGI Cache ou Varnish. Serve HTML da RAM.
- Object Cache: Redis. Detalhado acima.
- OpCache: Código PHP compilado para bytecode na RAM.
Evite o cabeçalho Cache-Control: no-store em páginas HTML normais: o Performance Lab assinala-o na Saúde do site porque desativa a cache de retroceder/avançar (bfcache), ou seja, o regresso instantâneo à página anterior. A configuração de cada camada passo a passo está no guia de otimização completa do WordPress (WPO).
Em que ordem otimizar a performance do WordPress
As partes deste guia funcionam melhor aplicadas por ordem e uma de cada vez, com uma medição antes e depois de cada alteração.
Comece pelo servidor. Registe o TTFB das páginas principais e a versão devolvida por php -v. Enquanto o TTFB estiver acima dos 500ms, nenhuma otimização de frontend compensa o atraso.
Na base de dados, corra a consulta ao tamanho das opções autoload e guarde o resultado. Depois de limpar opções e correr wp transient delete --expired, repita a consulta para confirmar que o valor desceu.
No frontend, a métrica a vigiar é o INP. Anote que scripts de terceiros carregam em cada página, como widgets de chat e pixels de rastreio, e adie os não essenciais um a um, para saber qual deles pesava de facto.
Na cache, ative uma camada de cada vez e confirme que o HTML servido fica atualizado depois de publicar conteúdo novo.
Em todas as camadas vale a mesma regra da checklist: as pontuações Lighthouse servem de orientação, e a decisão final deve vir de dados RUM de utilizadores reais. Lembre-se da janela de 28 dias do CrUX: o veredicto na Search Console chega ao fim de algumas semanas.
Qual checklist de performance WordPress usar em 2026
- Servidor corre PHP 8.3+ com OPcache ativo.
- Base de dados usa InnoDB e as opções autoload ficam abaixo de 800 KB.
- Object Cache (Redis) está ativo.
- Imagens são servidas como AVIF, e a imagem LCP não tem
loading="lazy". - JavaScript é adiado (deferred) para corrigir o INP.
- O carregamento especulativo do WordPress 6.8 não abrange links que executam ações.
- Está a medir Real User Metrics (RUM), não apenas pontuações Lighthouse, separadamente para mobile e desktop.
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.
