Quase todo WordPress lento é lento por causa da estrutura, e plugin raramente resolve isso. O tempo se perde em quatro camadas: servidor e hospedagem, banco de dados, CSS e JavaScript que bloqueiam a renderização, e scripts de terceiros. Só que a conversa sobre performance costuma começar pela nota. Alguém roda o PageSpeed Insights, vê um número vermelho e pede um plugin que deixe tudo verde. A nota é sintoma. A causa está quase sempre numa dessas quatro camadas, e nenhum plugin alcança todas. Por isso eu corrijo a estrutura primeiro, na ordem certa, e depois comprovo o resultado com dados de campo.
Onde o tempo se perde num WordPress lento?
Abra a aba Network numa página lenta do WordPress e leia de cima para baixo. A primeira linha, o documento HTML, já conta metade da história. Se o tempo até o primeiro byte passa de 600 ms, o servidor está trabalhando demais em cada requisição. Em geral falta cache de página, o banco cresceu sem índices ou algum plugin roda consultas pesadas a cada carregamento. Explico isso em detalhe no guia de TTFB no WordPress.
Depois vêm as linhas de CSS e JavaScript. Temas e page builders carregam tudo em todas as páginas, e o navegador não pinta nada enquanto os arquivos que bloqueiam a renderização não chegam. Em seguida aparecem imagens, fontes e scripts de terceiros: analytics, widget de chat, tags de anúncio. Cada um é pequeno sozinho. Juntos, empurram o Largest Contentful Paint para além do limite de 2,5 s e mantêm a thread principal ocupada muito depois de a página parecer pronta.
Um WordPress rápido não é um site com menos recursos. É um site em que cada byte tem motivo para estar naquela página.
Por que diagnosticar com dados de campo primeiro?
Uma ferramenta de laboratório roda um teste, em um dispositivo, de um lugar. Seus usuários não navegam assim. Comece pelo Chrome UX Report (CrUX) da sua origem e das URLs principais. Ele mostra o percentil 75 de LCP, INP e CLS de visitantes reais ao longo de 28 dias. Se o campo está bom e a nota de laboratório está ruim, o problema é de relatório, não de performance. Se os dois estão ruins, o campo diz qual métrica e quais páginas atacar primeiro (a diferença entre os dois está em dados de campo vs laboratório no Core Web Vitals). Mais ou menos assim eu leio:
- Tempo até o primeiro byte acima de 600 ms: servidor, cache e banco de dados.
- LCP acima de 2,5 s com TTFB rápido: CSS/JS que bloqueia a renderização, imagem principal ou fontes.
- INP acima de 200 ms: JavaScript na thread principal, quase sempre de terceiros e de builders.
- CLS acima de 0,1: imagens sem dimensões, fontes que chegam tarde, banners injetados.
Em que ordem corrigir?
A ordem importa porque cada camada esconde a de baixo. Primeiro faça o cache de página e o cache de objetos funcionarem, para o servidor deixar de ser o gargalo (a diferença entre eles está em page cache, object cache e edge cache). Depois cuide dos arquivos que bloqueiam a renderização: CSS carregado por template, JavaScript não crítico com defer, e preload da imagem principal e dos dois arquivos de fonte que você realmente usa. Só então olhe os scripts de terceiros, e esteja pronto para remover os que ninguém consegue justificar.
Suba cada mudança em staging, compare o laboratório antes e depois, e espere. Dados de campo levam de duas a quatro semanas para refletir uma mudança, então não julgue uma correção por um único teste de laboratório no dia do deploy. O passo a passo completo está no guia de como acelerar o WordPress.
Como é um resultado bom?
Para um site de conteúdo numa hospedagem decente, eu miro em TTFB abaixo de 200 ms vindo do cache, LCP perto de 1,5 s no mobile, INP abaixo de 150 ms e CLS zerado. WooCommerce ganha mais folga no carrinho e no checkout, mas as páginas de catálogo devem bater os mesmos números. Chegando lá, a nota do PageSpeed se resolve sozinha.
Se quiser saber em qual das quatro camadas o seu site perde tempo, a auditoria de performance WordPress começa exatamente por esse diagnóstico, com dados de campo.