Comece pela decisão, depois escolha a ferramenta
Nomeie a página, o público e a tarefa em risco antes de rodar qualquer ferramenta: uma página de produto em mobile, um checkout ou um formulário de geração de leads. Em seguida, escolha o tipo de evidência. Dados de laboratório (lab) são um teste controlado para depuração repetível. Dados de campo são experiência agregada de usuários reais para priorizar padrões. Um trace do navegador ajuda a explicar o trabalho local em tempo de execução. São complementares, não intercambiáveis.
Pergunte o que impede um visitante de completar uma tarefa importante, não como alcançar uma pontuação.
Use uma auditoria, dados de campo disponíveis e uma ferramenta de diagnóstico antes de adicionar mais produtos.
Um resultado se aplica à URL, condições ou amostra testada; não é um veredicto sobre todo visitante.
Use Lighthouse e PageSpeed Insights para auditorias repetíveis de carregamento
Lighthouse é uma auditoria automatizada open-source que roda no Chrome DevTools, na linha de comando ou em integração contínua. Audita performance, acessibilidade, SEO e mais. O PageSpeed Insights executa os diagnósticos do Lighthouse para uma URL e apresenta dados de usuário reais quando disponíveis. Use qualquer um para estabelecer uma linha de base de uma página representativa, investigar auditorias reprovadas e comparar um reteste controlado após uma mudança definida.
Como a página auditada se comportou em seu ambiente de teste e quais auditorias merecem investigação.
Uma boa pontuação no Lighthouse não significa necessariamente que a experiência dos usuários reais é boa; a documentação do Google mostra que resultados de laboratório e de campo podem divergir.
Reteste a mesma página e configurações depois de uma mudança; não o use como um portão único.
Use dados de campo para priorizar a experiência que os usuários realmente tiveram
Os dados de campo do PageSpeed Insights vêm do Chrome User Experience Report e cobrem um período de 28 dias retroativos. Relata métricas incluindo Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). O relatório de Core Web Vitals no Search Console ajuda quando você precisa analisar grupos de páginas em vez de uma URL. Use dados de campo para decidir qual template, grupo de dispositivo ou problema merece esforço primeiro.
Verifique se o resultado é em nível de página ou de origem e se a URL teve dados suficientes.
Dados de campo são históricos e agregados por privacidade, então não confirmam imediatamente o efeito de um release.
O Google recomenda LCP dentro de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1.
Use o Chrome DevTools quando uma auditoria precisar de explicação
Quando uma auditoria ou um padrão de campo aponta para carregamento lento, interação atrasada ou movimento visual, grave a jornada no Chrome DevTools > Performance. Ele registra perfis de CPU e pode mostrar LCP, CLS locais e, após interação, INP. Sua timeline ajuda o desenvolvedor a investigar o trabalho do navegador em vez de adivinhar a partir de uma lista de recomendações.
Use viewport, CPU e condição de rede que se aproximem razoavelmente do público afetado.
Um trace reflete o dispositivo, conexão, estado de cache e a jornada registrada. Reproduza jornadas relevantes antes de generalizar.
Registre a causa suspeita, a mudança e o efeito esperado para o visitante.
Combine checagens automatizadas de acessibilidade com avaliação humana qualificada
Use uma ferramenta de avaliação de acessibilidade para detectar problemas testáveis por máquina cedo e de forma repetida. O W3C WAI mantém uma lista de ferramentas e orientações de seleção, mas afirma que nenhuma ferramenta sozinha pode determinar se um site atende aos padrões de acessibilidade. Use as descobertas automatizadas para criar uma fila de revisão e então inspecione páginas representativas, operação por teclado, comportamento de foco, tratamento de erros e conteúdo com revisores qualificados.
Descoberta mais rápida e prevenção de defeitos repetíveis.
Não pode determinar conformidade completa com acessibilidade nem substituir avaliação humana.
Não anuncie um resultado automatizado como conformidade legal; obtenha revisão qualificada de acessibilidade e jurídica quando necessário.
Use ferramentas de segurança focadas com cuidado e dentro da autorização
O HTTP Observatory da Mozilla examina cabeçalhos HTTP e outras configurações de segurança-chave, dando aos administradores um ponto de partida para higiene de cabeçalhos em páginas públicas. Valide as alterações propostas de cabeçalho fora da produção porque políticas podem afetar scripts, serviços embutidos e fluxos do usuário. Ele avalia uma fatia da segurança, não todo o risco da aplicação.
OWASP ZAP pode escanear tráfego passivamente e testar aplicações ativamente, mas só teste sistemas que você está autorizado a testar.
O ZAP avisa que o scanning ativo é um ataque real que pode colocar alvos em risco. Scans passivos podem perder áreas autenticadas ou não visitadas.
Para pagamentos, autenticação, dados sensíveis ou descobertas relevantes, envolva profissionais de segurança qualificados.
Transforme a saída das ferramentas em remediação SIU, não em perseguição de pontuação
Use um loop durável: capture uma linha de base, identifique uma causa plausível, faça a menor mudança segura, reteste o mesmo caminho e observe a tendência de campo após tempo suficiente. Mantenha a tarefa do visitante central. Reduzir um ativo bloqueante só é valioso se melhorar a experiência útil sem quebrar compra, login, acessibilidade, consentimento ou comportamentos de analytics.
Favoreça mudanças respaldadas por impacto em campo, um trace reproduzível ou um defeito claro para o usuário.
Use staging, um dono, critérios de aceitação e um plano de rollback. SIU evita degradações evitáveis da experiência.
Mantenha a métrica, condições de teste e a tarefa do visitante concluída no registro da mudança, não apenas a pontuação.