Checklist de performance antes de publicar uma alteração no WordPress

Diagnostique as causas de saltos visuais durante o carregamento de tipografias e implemente estratégias de pré-carregamento com a propriedade font-display.

OTIMIZAÇÃO DE CÓDIGO

10/10/20266 min read

Não publique uma otimização só porque uma pontuação melhorou. Antes, valide a segurança, as funções do site, as condições da medição e a possibilidade de voltar ao estado anterior. Uma alteração que reduz alguns milissegundos pode, ao mesmo tempo, quebrar um formulário, servir conteúdo antigo ou criar um problema que só aparece em determinados dispositivos.

Este checklist organiza uma verificação de pré-publicação em quatro momentos: antes, durante, depois e na publicação. Ele é independente de plugin, hospedagem ou ferramenta paga. Não é uma auditoria completa e não substitui backups, políticas internas, testes de segurança, revisão de código ou avaliação profissional quando o risco for alto. Seguir todos os itens reduz incertezas, mas não elimina toda possibilidade de falha.

Antes: defina o que será alterado

Comece registrando o objetivo e a hipótese. “Melhorar a velocidade” é amplo demais. Prefira algo verificável, como “reduzir o bloqueio causado por este script na página de produto sem alterar o checkout”. Registre a página, o fluxo e o público afetados.

A linha de base deve incluir data e hora, URL, versão do WordPress, tema e componentes envolvidos, estado do cache, localização do teste, dispositivo, navegador, tipo de rede e ferramenta. Não compare uma página em cache quente, testada em desktop, com outra em cache frio, testada em um celular. A diferença pode vir das condições e não da alteração.

O guia oficial de backups do WordPress lembra que uma recuperação completa normalmente precisa dos arquivos e do banco de dados. Confirme que o backup é recente, identificável e armazenado em local seguro. Sempre que o risco justificar, faça um teste de restauração em ambiente separado; um arquivo criado sem teste não prova que a recuperação funcionará.

Checklist — preparação

Verificação

Resultado

Evidência/registro

Ação se falhar

[ ] Objetivo, hipótese, página e fluxo afetados estão descritos

☐ aprovado ☐ pendente

Link ou ID da alteração

Especificar o escopo antes de continuar

[ ] Linha de base foi registrada com ferramenta, data, cache, dispositivo e rede

☐ aprovado ☐ pendente

Relatório ou captura sem dados sensíveis

Repetir a medição em condições comparáveis

[ ] Backup de arquivos e banco foi concluído

☐ aprovado ☐ pendente

ID, data e localização protegida

Não publicar; criar o backup

[ ] Backup ou restauração foi verificado conforme a política do site

☐ aprovado ☐ pendente

Registro do teste, sem credenciais

Pausar e corrigir o procedimento de recuperação

[ ] Staging ou ambiente de desenvolvimento está disponível

☐ aprovado ☐ pendente

URL interna e versão do ambiente

Criar uma cópia segura ou reduzir o escopo da mudança

[ ] Plano de reversão tem responsável, passos e condição de acionamento

☐ aprovado ☐ pendente

Link do runbook ou ticket

Escrever e revisar o plano

Staging não é produção

Staging é uma cópia controlada para testar a alteração sem interromper a versão pública. A documentação do WordPress sobre cópias de desenvolvimento descreve esse tipo de instalação como uma forma de atualizar e modificar o site sem interromper a versão ao vivo.

O resultado no staging, porém, não representa automaticamente a produção. A cópia pode não reproduzir a CDN, regras de cache, compressão, tráfego, integrações de pagamento, filas, permissões, região do servidor ou volume de dados reais. Dados de clientes também não devem ser copiados sem necessidade e proteção adequada.

Identifique o ambiente de forma explícita para não testar ou publicar no lugar errado. O WordPress aceita os tipos local, development, staging e production por meio de WP_ENVIRONMENT_TYPE; a referência oficial de wp_get_environment_type() explica os valores e o comportamento padrão. Proteja o staging contra indexação e acesso indevido, mas não desative controles de segurança essenciais apenas para facilitar o teste.

Durante: uma alteração, um registro

Altere uma variável por vez quando isso for razoável. Se você trocar o formato das imagens, adiar scripts e modificar o cache na mesma janela, uma melhora ou regressão ficará difícil de atribuir. Registre a configuração anterior, a nova configuração, a versão do componente e o horário da mudança.

Teste os caminhos que a alteração pode afetar, não apenas a página usada na medição. Uma mudança em JavaScript pode atingir menus, busca, login ou checkout. Uma regra de cache pode misturar conteúdo de usuários diferentes. Uma mudança no tema pode afetar modelos de post, páginas e dispositivos móveis.

Checklist — execução e compatibilidade

Verificação

Resultado

Evidência/registro

Ação se falhar

[ ] A alteração está identificada por ticket, commit ou versão

☐ aprovado ☐ pendente

ID e diff/configuração

Parar e registrar o estado

[ ] Configuração anterior foi guardada para reversão

☐ aprovado ☐ pendente

Export ou anotação protegida

Não prosseguir sem rollback conhecido

[ ] Página principal, páginas relacionadas e fluxo crítico foram testados

☐ aprovado ☐ pendente

URLs e passos reproduzíveis

Corrigir ou reverter no staging

[ ] Desktop e mobile foram verificados

☐ aprovado ☐ pendente

Dispositivo, viewport e capturas

Investigar layout, toque e carregamento

[ ] Navegadores e dispositivos relevantes foram cobertos

☐ aprovado ☐ pendente

Matriz de compatibilidade

Ampliar teste ou limitar a publicação

[ ] Dados de teste, cookies, tokens e credenciais não aparecem nos registros

☐ aprovado ☐ pendente

Revisão das capturas/logs

Redigir, remover e proteger o material

Depois: função antes de pontuação

Faça uma inspeção visual em larguras relevantes: cabeçalho, navegação, imagens, fontes, botões, anúncios e conteúdo carregado depois da interação. Em seguida, percorra o fluxo funcional: busca, formulário, login, carrinho e checkout quando existirem. Teste mensagens de erro e estados vazios, não apenas o caminho de sucesso.

No DevTools, confira o console e a aba Network. Procure erros JavaScript, requisições bloqueadas, respostas 4xx/5xx, loops, recursos que não terminam de carregar, fontes ou imagens ausentes e respostas servidas com cache inadequado. Compare o conteúdo atualizado com a versão publicada e confirme a invalidação dos caches necessários. O guia oficial de atualização do WordPress também recomenda limpar o cache após a atualização para que visitantes não continuem vendo a versão antiga.

Para desempenho, use métricas adequadas ao objetivo. Os Core Web Vitals atuais são LCP, INP e CLS: carregamento, capacidade de resposta e estabilidade visual. A orientação do Web Vitals usa o percentil 75, separado por mobile e desktop, para avaliar a experiência da maioria dos usuários; isso não transforma um valor isolado em garantia para todas as visitas.

Diferencie dados de laboratório de dados de campo. O Lighthouse roda em condições controladas e ajuda a detectar regressões antes da publicação. Dados de campo refletem dispositivos, redes, regiões e comportamentos reais. O guia sobre diferenças entre lab e field data explica por que os resultados podem divergir e por que as condições devem ser registradas. A documentação do Lighthouse descreve sua execução no DevTools, na linha de comando e em outros fluxos.

Checklist — validação pós-alteração

Verificação

Resultado

Evidência/registro

Ação se falhar

[ ] Aparência e conteúdo estão corretos

☐ aprovado ☐ pendente

Capturas e URLs

Corrigir ou reverter

[ ] Console e rede não mostram regressões novas

☐ aprovado ☐ pendente

Relatório filtrado e horário

Investigar a requisição ou o script

[ ] Formulários, login e checkout foram testados quando aplicável

☐ aprovado ☐ pendente

Caso de teste e resultado

Bloquear a publicação

[ ] Cache, CDN e conteúdo atualizado foram confirmados

☐ aprovado ☐ pendente

Cabeçalhos, purge e URL

Invalidar cache conforme o runbook

[ ] Métricas foram repetidas em condições comparáveis

☐ aprovado ☐ pendente

Relatórios antes/depois

Repetir; não concluir por uma única execução

[ ] Dados sensíveis foram removidos ou protegidos

☐ aprovado ☐ pendente

Revisão do anexo

Redigir antes de compartilhar

Publicação e decisão

Defina um responsável pela publicação, uma janela de horário e uma observação pós-publicação. Depois de publicar, repita os testes mínimos em produção e observe erros, conversões, disponibilidade e métricas relevantes pelo período definido na política do site.

Não existe um limiar universal que diga quando toda otimização deve ser aceita ou revertida. O critério deve ser proporcional ao risco e ao objetivo. Uma pequena variação de laboratório pode ser irrelevante se a função crítica está intacta; uma falha de login exige pausa mesmo que a pontuação tenha melhorado.

•Seguir: a alteração é identificável, os testes críticos passaram, não há regressão relevante e a evidência sustenta a hipótese.

•Pausar: faltam evidências, os resultados divergem sem explicação, o ambiente não representa o risco ou apareceu uma regressão ainda não classificada.

•Reverter: houve falha funcional, conteúdo incorreto, erro de segurança, indisponibilidade ou impacto incompatível com o objetivo. Acione o plano, registre a decisão e preserve os dados para investigação.

Mini-ficha para o registro da alteração

•ID e responsável:

•Data e janela:

•Objetivo e hipótese:

•Página/fluxo afetado:

•Alteração e versão anterior:

•Ambiente testado:

•Linha de base e condições de medição:

•Evidências:

•Testes funcionais realizados:

•Resultado pós-publicação:

•Condição de pausa/reversão:

•Responsável e horário da observação:

•Incidentes ou pendências:

Mantenha relatórios e capturas sem senhas, cookies, tokens, chaves, dados pessoais ou informações de clientes. Quando uma ferramenta solicitar acesso a uma página autenticada, use o mecanismo seguro da própria ferramenta; nunca coloque segredos em screenshots, tickets, repositórios ou serviços públicos de compartilhamento.