Use este checklist na ordem que as evidências indicarem
Este checklist com 47 itens é uma auditoria de trabalho para sites WordPress. Ele não promete um tempo de carregamento nem uma pontuação específicos: hospedagem, conteúdo, dispositivos dos visitantes e requisitos do negócio variam. Comece pela experiência do usuário que está falhando, escolha as verificações relevantes e valide um tipo de mudança por vez.
Priorize os gargalos medidos antes do ajuste avançado do servidor. Uma mudança que economiza uma requisição pequena, mas quebra o checkout, é uma regressão, mesmo que a pontuação de laboratório melhore.
Estabeleça a linha de base
- Escolha URLs representativas de página inicial, artigo, arquivo, produto e checkout; inclua sessões logadas e anônimas.
- Registre a região da hospedagem, o dispositivo, as condições de rede, o navegador e a versão do release para que os testes seguintes sejam comparáveis.
- Execute testes de laboratório repetíveis mais de uma vez e guarde a faixa de resultados, não apenas o mais rápido.
- Confira o LCP, o INP e o CLS de usuários reais quando houver dados de campo; diferencie os dados da URL dos dados da origem.
- Analise a requisição do documento e separe o atraso de DNS, de conexão e de resposta do servidor.
- Capture um trace da thread principal enquanto reproduz a interação lenta, não apenas durante o carregamento inicial.
- Identifique o elemento LCP real e a cadeia de requisições necessária para exibi-lo.
- Faça um backup restaurável e defina os fluxos de usuário principais que precisam continuar funcionando depois das mudanças.
Reduza o trabalho na origem
- Use uma versão do PHP com suporte e compatível com o site; valide as atualizações em homologação antes da produção.
- Verifique a saúde e a capacidade do OPcache. Não desative a verificação de timestamps, a menos que o deploy invalide o cache explicitamente.
- Faça o profiling dos caminhos lentos do PHP e das consultas repetidas ao banco antes de alterar as configurações do servidor.
- Revise as requisições a APIs remotas durante a renderização da página; use cache adequado e timeouts limitados.
- Verifique o cache de objetos persistente com o provedor de hospedagem e confira a invalidação quando o conteúdo muda.
- Coloque em cache o HTML público apenas onde for seguro; ignore respostas autenticadas, de carrinho, de checkout e personalizadas.
- Confirme que dois usuários diferentes não podem receber os dados em cache um do outro.
- Analise a saturação de CPU, memória e workers sob uma carga representativa antes de aumentar a concorrência.
- Valide a execução das tarefas agendadas. Se mover o WP-Cron para um agendador do sistema, monitore as tarefas perdidas e com falha.
- Analise os planos de consulta antes de adicionar índices; avalie o custo nas gravações e teste em uma cópia representativa dos dados.
- Revise as opções autocarregadas muito grandes junto com o plugin responsável por elas. Faça backup antes de uma limpeza pontual.
- Pagine as consultas grandes e evite carregar na memória uma coleção sem limite.
Melhore a renderização e a interação
- Remova scripts e estilos não usados somente depois de verificar menus, formulários, checkout e os requisitos do editor.
- Adie os scripts compatíveis mantendo a ordem das dependências; async não substitui a execução ordenada.
- Analise os estilos que bloqueiam a renderização. Teste qualquer abordagem de CSS crítico em todos os templates e tamanhos de tela.
- Mantenha a imagem LCP detectável no HTML inicial em vez de inseri-la tarde com JavaScript.
- Não use carregamento lento na imagem LCP. Use a prioridade de busca alta de forma seletiva e depois analise a cascata.
- Divida o JavaScript pesado em partes medidas e ceda o controle entre elas quando for adequado.
- Agrupe as leituras e escritas de layout para evitar recálculos forçados repetidos.
- Remova widgets de terceiros desnecessários; adie os opcionais apenas quando o comportamento deles e as regras de consentimento permitirem.
- Reserve as dimensões de imagens, conteúdos incorporados e anúncios antes que os recursos cheguem.
- Confira as métricas da fonte alternativa e as mudanças de layout; use font-display de forma intencional.
- Mantenha os controles interativos utilizáveis com navegação por teclado e movimento reduzido.
- Teste páginas longas e dispositivos de baixo desempenho; uma página inicial rápida não prova que todos os templates são rápidos.
Entregue recursos do tamanho adequado
- Escolha a largura de cada imagem de acordo com o espaço em que ela é exibida e a densidade de pixels esperada.
- Compare AVIF, WebP e os formatos existentes no arquivo real em vez de supor uma economia fixa.
- Forneça candidatas srcset responsivas e um valor sizes que reflita o layout.
- Use carregamento lento nas imagens fora da tela e decodificação assíncrona quando for adequado.
- Mantenha em HTML os rótulos e explicações essenciais; texto pequeno dentro de imagens é difícil de ler.
- Hospede as fontes você mesmo ou reduza de outra forma as requisições de fontes; carregue apenas os pesos e conjuntos de caracteres de que o site precisa.
- Pré-carregue apenas os recursos realmente críticos, depois de verificar a cascata de requisições.
- Verifique a entrega com gzip ou Brotli dos recursos de texto e evite recomprimir imagens já comprimidas.
- Use cache de longa duração para recursos estáticos versionados e mude a URL deles quando o conteúdo mudar.
- Carregue vídeos de forma intencional. Esconder um vídeo apenas com CSS não garante que o download pare.
Verifique o release
- Teste login, busca, formulários de contato, carrinho e checkout depois de ativar qualquer otimização.
- Analise os cabeçalhos de cache e a invalidação do conteúdo nas páginas editadas.
- Repita os testes de laboratório da linha de base nas mesmas condições e registre tanto os ganhos quanto as regressões.
- Acompanhe as métricas de campo ao longo do tempo; um release não aparece imediatamente em uma janela de dados móvel.
- Defina orçamentos de desempenho e mantenha um registro de mudanças para que uma regressão futura possa ser associada a um release.
Perguntas frequentes
O que corrigir primeiro?
Se o documento inicial é lento, faça o profiling da origem e do comportamento do cache. Se o documento chega rápido, mas o conteúdo principal aparece tarde, analise o recurso LCP e o caminho de renderização. Se os cliques parecem lentos depois do carregamento, investigue o trabalho de JavaScript e de layout durante a interação. Deixe essa distinção clara nas suas anotações de auditoria.
Uma pontuação baixa no Lighthouse gera uma penalidade fixa de ranqueamento?
Nenhuma regra publicada atribui uma penalidade fixa no Google a uma pontuação do Lighthouse abaixo de um número específico. Use a pontuação para investigar oportunidades técnicas e os dados de campo para entender os visitantes reais.
Preciso aplicar as 47 verificações em todo site WordPress?
Não. Use o checklist para identificar as investigações relevantes e depois priorize o gargalo que afeta uma jornada importante do cliente. Um site institucional e uma loja WooCommerce movimentada têm requisitos diferentes. Registre por que uma verificação é aplicável, adiada ou desnecessária.
O que devo testar depois de alterar as configurações de cache ou de scripts?
Confira menus, busca, formulários, login e checkout quando se aplicar. Teste sessões separadas, edite e despublique conteúdo para verificar a invalidação e compare o desempenho com a linha de base original. Mantenha um rollback disponível caso uma otimização quebre uma interação necessária.
Fontes e leituras recomendadas
Continue explorando
Aprofunde-se no diagnóstico de TTFB e Core Web Vitals e na entrega de imagens responsivas.
Leave a Reply