Um site “aguentar” a Black Friday significa manter a compra possível quando tráfego, pagamentos e integrações estão sob pressão. Uma nota alta em ferramenta de velocidade não mede sozinha capacidade de estoque, checkout, ERP ou emissor fiscal.
Este checklist prioriza falhas que impedem um pedido de chegar ao fim. Use histórico real de acesso e de vendas para definir a carga de teste, registrando o que ficou fora do ensaio.
Em resumo
- Teste páginas de produto, busca, carrinho e checkout, não apenas a home.
- Meça experiência no celular e tempo de resposta das integrações.
- Simule pagamento aprovado, recusado, atrasado e repetido.
- Defina alertas, responsáveis e procedimento de retorno após falha.
O que medir antes de aumentar o tráfego?
Colete volume por minuto nas horas mais fortes, tempo de carregamento das páginas principais e taxa de erros em cada etapa. Separe gargalos do navegador dos do servidor. As métricas Core Web Vitals avaliam carregamento e experiência de interação; dados de campo no percentil 75 são mais representativos que uma única execução local.
Confira imagens e scripts de terceiros na página de produto. Uma capa grande ou widget pode atrasar o conteúdo mais importante. Reserve espaço para imagens e componentes que carregam depois para evitar deslocamentos. Faça testes em celular intermediário, com rede limitada e cache frio.
Como desenhar um ensaio de carga útil?
Reproduza uma mistura plausível de visitantes que navegam, pesquisam, adicionam ao carrinho e pagam. Aumente a carga em etapas e meça erro, latência e fila. Use ambiente controlado e combine limites com provedores externos para não disparar cobranças ou documentos fictícios. O objetivo é encontrar o primeiro componente que degrada e a capacidade observada, não declarar um número mágico de acessos.
Depois de corrigir um gargalo, repita o mesmo cenário. Registre versão do site, configuração, dados usados e resultado. Mudança de cache, estoque ou provedor pode invalidar a conclusão anterior.
Que falhas precisam de procedimento escrito?
Pagamento confirmado sem pedido, pedido sem documento fiscal, estoque vendido duas vezes, cupom aplicado errado e página fora do ar. Cada caso precisa de um estado visível, responsável e comunicação possível ao cliente. Teste o caminho de recuperação antes do evento. O roteiro de emissão em lote cobre a parte fiscal; o guia central liga oferta e atendimento.
Se o Lighthouse mostra 100, o site está pronto?
Não. A nota representa um teste específico de uma página. Faça também jornadas completas e carga, além de observar dados reais de usuários quando disponíveis.
Qual número de usuários simultâneos devo testar?
Derive cenários do histórico, da mídia planejada e da capacidade de atendimento. Documente hipóteses e teste progressivamente. Um número copiado de outra loja não prova prontidão.
Próximo passo
Percorra a compra completa em celular e rode um ensaio progressivo que inclua checkout, pagamento e ERP. Registre a primeira falha e quem a resolverá. Se precisar melhorar arquitetura ou observabilidade, descreva seu projeto.