1. Defina o resultado e o limite
Nomeie um proprietário e escreva o resultado antes de abrir uma ferramenta de auditoria. Declare o público, a jornada, páginas ou rotas, janela de tempo e a decisão que o trabalho deve suportar. Um objetivo útil descreve uma tarefa, como completar um fluxo móvel de produto-para-carrinho, não um desejo vago de tornar o site mais rápido.
Liste itens não negociáveis: funcionamento do fluxo de compra ou contato, acesso à conta, comportamento de consentimento, acessibilidade, visibilidade nos mecanismos de busca e conteúdo aprovado. Um ganho sintético de pontuação não é uma vitória se um formulário falhar, o conteúdo ficar oculto dos mecanismos de busca ou o uso do teclado se tornar mais difícil.
Escreva a página de início, ação do usuário e estado final de sucesso em uma frase.
Escolha um resultado que não pode piorar, como envio bem-sucedido ou ausência de novo bloqueador de acessibilidade.
2. Capture uma linha de base comparável
Antes de alterar código, conteúdo, configuração ou tags, salve a lista de URLs, data, condições de teste, versão de release, relatórios ou traces e o resultado manual da tarefa. web.dev recomenda gravar o estado do site antes das mudanças e testar múltiplos tipos de página; para aplicações de página única (single-page applications), inclua rotas, componentes e fluxos em vez de apenas o primeiro carregamento.
Use mais de uma lente. Lighthouse fornece auditorias automatizadas de performance, acessibilidade, SEO e outras. Teste o primeiro carregamento com armazenamento limpo ou um perfil limpo, então complete a tarefa alvo. Onde houver dados reais suficientes, compare grupos importantes de páginas e classes de dispositivo. Core Web Vitals são medidas de campo: LCP cobre carregamento, INP interatividade e CLS estabilidade visual.
Dados de campo refletem visitas reais; teste de laboratório torna um problema mais fácil de reproduzir. Use ambos quando disponíveis.
Um carregamento simulado não pode medir INP porque não há entrada do usuário; Total Blocking Time em laboratório é apenas um proxy.
3. Audite a jornada de ponta a ponta
Agrupe achados por jornada e mecanismo. Revise o tamanho, o tempo e as dependências das requisições de ativos da página e de terceiros. Verifique a viewport móvel, a navegação por teclado, o foco visível, os rótulos, os erros, os cabeçalhos, a finalidade dos links, o zoom e o que acontece se uma imagem, um script ou um serviço dependente de consentimento ficar lento ou indisponível.
Trate a saída automatizada de acessibilidade como triagem. O W3C afirma que nenhuma ferramenta sozinha pode determinar se um site atende aos padrões de acessibilidade; é necessária avaliação humana qualificada. Para busca, garanta que recursos renderizados importantes permaneçam disponíveis para crawlers assim como para usuários. Inclua redirecionamentos, canonicals, links internos, diretivas robots, sitemaps e dados estruturados quando a mudança os afetar.
Liste tag managers, analytics, chat, pagamento, fontes, CDNs, APIs e ferramentas de consentimento das quais a tarefa depende.
Para pagamento, autenticação, dados de usuário, headers ou controles de segurança, obtenha revisão qualificada de segurança e pagamento.
4. Construa um backlog ranqueado
Escreva uma pequena hipótese para cada item: nesta página ou fluxo, mude este mecanismo porque evidências sugerem que ele causa este problema; meça o resultado esperado e proteja as travas de proteção nomeadas. Mantenha observação distinta de diagnóstico. Um trace salvo pode mostrar uma imagem grande atrasando o conteúdo, mas a solução ainda precisa de revisão de design e conteúdo.
Ordene os itens por Impacto, Confiança, Esforço e Risco. Impacto é a jornada prioritária afetada. Confiança é se laboratório, campo e evidência manual concordam. Esforço inclui coordenação, não apenas código. Risco inclui dependências, segurança, complexidade de release e reversibilidade. Exposição funcional crítica ou de segurança pode superar este modelo e requer triagem especializada.
Mantenha proprietário, link de evidência, hipótese, páginas, métrica, travas de proteção, dependências, método de release e gatilho de rollback.
Não junte refatores não relacionados em uma mudança mensurada a menos que a segurança o exija.
5. Libere com segurança e mantenha um caminho de volta
Antes do deploy, registre o que muda, aprovador, janela de release, verificador, condição de sucesso, gatilho de rollback e método de restauração. Teste em um ambiente não produtivo representativo quando possível, incluindo conteúdo, permissões, integrações, redirecionamentos, escolhas de consentimento e caminhos comuns de falha. Produção ainda pode diferir por causa de dados, cache, configuração e terceiros.
Use um rollout pequeno, feature flag, asset versionado ou configuração reversível onde a plataforma permitir. Confirme o comportamento de cache e CDN antes de comparar resultados. OWASP trata gestão de configuração e deploy como área de teste de segurança; headers, permissões, exposição de arquivos e configurações de domínio ou nuvem não devem ser mudanças casuais de otimização.
Defina um gatilho observável, como checkout falho, navegação quebrada, erro cliente inesperado ou regressão de acessibilidade.
Um plano de rollback pode reduzir o tempo de recuperação mas não remove todo risco; teste a restauração antes de dependê-lo.
6. Verifique, decida e repita
Após a liberação, repita as verificações funcionais da linha de base e testes de laboratório comparáveis. Refaça em dispositivos, navegadores, estados e integrações relevantes. Compare igual com igual: URL, estado de cache, classe de dispositivo, região quando viável e janela de medição. Confirme travas de proteção assim como a métrica alvo.
Dê tempo para as evidências amadurecerem. O Google observa que mudanças de busca podem levar de horas a meses para aparecer e sugere esperar semanas para avaliar se ajudaram. Dados de desempenho de usuários reais são evidência agregada, não um veredito instantâneo sobre o release. Registre se a decisão é manter, modificar, investigar ou reverter e, então, redefina a linha de base após mudanças significativas de template, plataforma, tag, conteúdo ou dependência.
O resultado esperado da jornada melhora e as travas de proteção acordadas permanecem intactas.
Aja quando evidência de campo ou tarefa conflitar com o resultado do laboratório, ou uma trava de proteção crítica regredir.