Checklist de velocidade do WordPress (com Core Web Vitals)

Este checklist de velocidade do WordPress é a lista que percorro nas auditorias, na ordem em que percorro. Ele tem seis partes: medição, servidor, cache, banco de dados, front-end e terceiros, mais uma seção curta sobre manter o site rápido. Cada item é uma pergunta de sim ou não que você confere no seu próprio site. Comece pelo topo, porque os itens de servidor e cache definem o piso de tudo o que vem abaixo. Ele também funciona como checklist de Core Web Vitals: cada item se liga ao TTFB, ao LCP, ao INP ou ao CLS, e o objetivo é passar nas três Core Web Vitals nos dados de campo, e não bater uma nota de laboratório.

Um checklist diz o que conferir. Não explica por que a ordem importa nem como corrigir cada item a fundo. Para isso, leia o guia de engenharia para acelerar o WordPress. Se você ainda não sabe o que está lento no seu site, comece por como descobrir por que o seu WordPress está lento e depois volte aqui.

Antes de mudar qualquer coisa: medição

1. Você tem dados de campo? Confira o relatório de Core Web Vitals no Search Console e o bloco de dados de campo no PageSpeed Insights.
2. Você sabe qual métrica reprova? LCP bom é até 2,5 s, INP até 200 ms e CLS até 0,1, todos no percentil 75.
3. Você testou uma URL por template (home, post, página, arquivo, produto, categoria, carrinho, checkout), e não só a home?
4. Anotou uma linha de base para cada template, incluindo o TTFB?
5. Existe uma cópia de homologação para testar as mudanças arriscadas?

As ferramentas para cada um desses itens, e para que cada uma serve, estão comparadas em ferramentas de Core Web Vitals. Lembre que o CrUX usa uma janela móvel de 28 dias, então os dados de campo vão mostrar as suas mudanças com umas quatro semanas de atraso.

Servidor e hospedagem

1. O site roda numa versão de PHP que ainda tem suporte?
2. O OPcache está ligado, com memória suficiente para não ficar descartando scripts o tempo todo?
3. O plano tem PHP workers suficientes para o seu tráfego sem cache (usuários logados, carrinho, busca)?
4. O servidor, ou uma CDN, fica perto da maioria dos seus visitantes?
5. HTTP/2 ou HTTP/3 estão ativos, junto com compressão Brotli ou gzip?
6. Você tem acesso aos logs de erro e ao slow log do PHP?
7. O TTFB sem cache em páginas simples é razoável, de preferência bem abaixo dos 0,8 s que o web.dev considera bom para o TTFB em geral?

Os itens de servidor estão detalhados em ajuste de PHP-FPM e OPcache para WordPress e no guia de TTFB.

Cache

1. Existe cache de página, e requisições anônimas repetidas mostram HIT nos cabeçalhos da resposta?
2. As landing pages principais continuam pegando o cache com parâmetros de campanha como utm_source?
3. Há cookies gravados para todo visitante que fazem o cache ser pulado?
4. Só uma camada de cache de página está no comando, ou um plugin e o cache da hospedagem estão brigando?
5. A limpeza apaga só o que mudou, em vez do cache inteiro a cada edição?
6. Existe object cache persistente (Redis ou Memcached) para requisições logadas, de carrinho e do admin?
7. Os arquivos estáticos saem de uma CDN com tempo de cache longo?
8. O Site Health do WordPress (Ferramentas, Saúde do site) parou de reclamar do cache de página?

Quais camadas você precisa de verdade depende do site: page cache, object cache, edge cache explica como decidir. Para a parte dos plugins, veja melhores plugins de cache para WordPress.

Banco de dados

1. O tamanho total das opções com autoload é pequeno? Desde o WordPress 6.6, o Site Health avisa quando não é.
2. Você sabe qual plugin é dono de cada uma das maiores opções com autoload?
3. Removeu opções e tabelas que sobraram de plugins que não estão mais instalados?
4. Os transients expirados estão sendo limpos?
5. As revisões de posts estão limitadas com WP_POST_REVISIONS?
6. O Query Monitor mostra queries lentas ou duplicadas nos templates principais?
7. Num site movimentado, o WP-Cron está desligado nas visitas (DISABLE_WP_CRON) e rodando por um cron do sistema?
8. No WooCommerce, a loja usa o High-Performance Order Storage?

Como fazer cada um desses com segurança, usando WP-CLI, está em otimização do banco de dados do WordPress.

Front-end: LCP

1. Você sabe qual é o elemento LCP de cada template?
2. Esse elemento está sem lazy load?
3. A imagem do LCP tem fetchpriority="high"? A partir do WordPress 6.3 o core adiciona isso sozinho à imagem que considera a provável LCP; confira se o seu tema não removeu.
4. A imagem é entregue no tamanho do espaço que ocupa, usando srcset?
5. As imagens estão em WebP (aceito no upload desde o WordPress 5.8) ou AVIF (desde a 6.5)?
6. O banner principal está livre de sliders e animações de entrada que atrasam a exibição?
7. O CSS que bloqueia a renderização se limita ao que a primeira tela precisa?

Detalhes em LCP no WordPress.

Front-end: INP e JavaScript

1. Os scripts não essenciais carregam com defer ou async? O WordPress 6.3 adicionou estratégias de carregamento ao registro de scripts.
2. Os plugins carregam o JavaScript só nas páginas que usam?
3. Você tirou scripts que fazem o que o CSS faz (toggles simples, animações, cabeçalho fixo)?
4. O tamanho do DOM é razoável, principalmente nas páginas feitas com builder?
5. Se você usa uma opção de “atrasar JavaScript”, conferiu se menu, busca e botão de comprar ainda respondem rápido no primeiro toque?

Detalhes em INP no WordPress. Se o site é feito em Elementor, como acelerar o Elementor tem itens específicos do builder.

Front-end: CLS e fontes

1. Todas as imagens, vídeos e iframes têm largura e altura, ou uma proporção reservada?
2. Espaços de anúncio, banners e embeds têm o lugar reservado antes de carregar?
3. A barra de cookies ou de consentimento fica por cima da página em vez de empurrá-la para baixo?
4. As fontes estão hospedadas localmente, limitadas aos pesos que você usa e com font-display definido?
5. A fonte do texto do LCP, se houver, tem preload?

Detalhes em CLS no WordPress.

Scripts de terceiros

1. Você tem uma lista de todas as tags de terceiros que o site carrega?
2. Cada uma tem um responsável que usa aqueles dados?
3. Removeu as que ninguém consegue justificar?
4. Chat, vídeo e embeds de redes sociais carregam só depois da interação ou quando entram na tela?
5. Adicionar uma tag nova passa por revisão, ou qualquer pessoa adiciona pelo gerenciador de tags?

Extras para WooCommerce

1. As páginas de produto e de categoria passam no LCP nos dados de campo?
2. A requisição de cart fragments roda só onde é necessária?
3. Existe object cache persistente?
4. As telas de pedidos e os relatórios do wp-admin estão rápidos o bastante para a equipe?

O trabalho específico de loja está em otimização de velocidade do WooCommerce.

Como manter o site rápido

1. Você confere os dados de campo um mês depois de cada rodada de mudanças?
2. Existe monitoramento de usuários reais, ou pelo menos uma olhada regular no Search Console?
3. Plugin novo passa por teste de performance antes de ir para o ar?
4. Core do WordPress, PHP e plugins estão atualizados?
5. Você revisa os dados com autoload e as queries lentas algumas vezes por ano?

Quais itens do checklist de velocidade do WordPress importam mais?

Se o tempo só der para alguns, faça estes: confirme que o cache de página está sendo usado de fato, coloque object cache persistente em sites com tráfego logado, enxugue as opções com autoload, corrija a imagem do LCP nos templates principais e tire as tags de terceiros que ninguém usa. Nas minhas auditorias, esses cinco resolvem boa parte dos problemas. O resto da lista é o caminho entre “quase tudo bem” e passar em todos os templates.

Quer que alguém faça isso por você?

Se você prefere que alguém percorra o checklist com dados de campo, ordene o que importa no seu site e documente as correções, essa é a minha auditoria de performance WordPress. Para trabalho contínuo de performance, veja como atuo como especialista em performance WordPress.