Configuração do ambiente de medição e consistência de testes

Por que a configuração do ambiente de medição importa

Medir performance front-end não é apenas “rodar uma ferramenta e anotar um número”. O resultado depende fortemente do ambiente: hardware, rede, cache, extensões do navegador, variações do servidor, dados de usuário (cookies), rotas de navegação, versão do código e até do horário do dia. Se o ambiente muda a cada teste, você não consegue responder perguntas básicas como: “essa alteração melhorou ou piorou?” ou “o ganho foi real ou ruído?”.

Este capítulo foca em como configurar um ambiente de medição e um processo de testes consistentes para que as métricas sejam comparáveis ao longo do tempo. A ideia é reduzir variáveis não controladas, padronizar o modo de coletar dados e registrar contexto suficiente para reproduzir resultados.

Conceitos essenciais: repetibilidade, reprodutibilidade e variáveis de teste

Repetibilidade vs. reprodutibilidade

Repetibilidade é obter resultados semelhantes repetindo o teste nas mesmas condições (mesma máquina, mesma rede, mesma versão do app, mesmo fluxo). Reprodutibilidade é obter resultados semelhantes quando outra pessoa (ou outra máquina) executa o mesmo procedimento seguindo o mesmo protocolo.

Em performance, você raramente terá números idênticos; o objetivo é reduzir a variância e conseguir detectar mudanças reais. Um bom protocolo define: o que medir, como medir, onde medir, quantas vezes medir e como interpretar.

Variáveis que mais distorcem medições

• Cache e estado do navegador: primeira visita vs. visitas subsequentes; service worker; cache HTTP; cache de imagens; armazenamento local.
• Condições de rede: Wi‑Fi vs. cabo; latência; perda de pacotes; congestionamento; DNS.
• CPU/GPU e energia: modo economia de energia; thermal throttling; processos em background; aceleração de hardware.
• Extensões e plugins: ad blockers, antivírus, extensões de devtools, tradutores.
• Variabilidade do backend/CDN: cache hit/miss; cold start; balanceamento; região; deploys em andamento.
• Dados do usuário: login, feature flags, A/B tests, personalização, conteúdo dinâmico.
• Mudanças de versão: dependências, bundling, flags de build, minificação, sourcemaps.

Definindo um “contrato de medição” (o que precisa estar fixo)

Antes de automatizar qualquer coisa, defina um contrato simples e documentado. Ele deve responder:

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Ambiente-alvo: local, staging ou produção? Qual URL base? Qual região?
• Perfil de dispositivo: desktop/laptop específico? emulador? dispositivo real? Qual SO e versão?
• Perfil de rede: sem limitação, 4G, 3G? Qual latência e throughput?
• Modo de navegação: janela normal ou anônima? cache limpo ou aquecido?
• Fluxo: quais páginas/rotas? qual sequência de cliques? quais interações?
• Critério de amostragem: quantas execuções por URL? como calcular (mediana, p75)?
• Critério de comparação: baseline (commit/tag) vs. branch atual? janela temporal?
• Registro: o que salvar junto com o resultado (commit hash, data, máquina, config)?

Esse contrato evita que cada pessoa “meça do seu jeito” e cria um padrão para comparar PRs, releases e regressões.

Ambientes típicos de medição e quando usar cada um

Local (máquina do dev)

Útil para iteração rápida e diagnóstico, mas é o ambiente mais sujeito a ruído: processos rodando, variação de rede, extensões, etc. Use local para encontrar causas e validar hipóteses, mas evite usar como única fonte para aprovar mudanças.

CI (integração contínua)

Ótimo para consistência: mesma imagem de container, mesmos recursos alocados, mesmo script. Ainda assim, pode haver variação por carga do runner. O ideal é reservar runners dedicados ou usar máquinas com recursos previsíveis.

Staging

Bom para testar com infraestrutura próxima da produção, mas cuidado com diferenças: dados menores, cache diferente, autenticação simplificada, flags distintas. Se staging não espelha produção, as medições podem enganar.

Produção

É onde o usuário real está, mas testes sintéticos em produção precisam ser controlados para não gerar carga indevida e para evitar medir em momentos de instabilidade (deploy, incidentes). Em geral, use produção para validação final e para monitoramento contínuo, com janelas e limites bem definidos.

Padronizando o navegador e o sistema

Crie um perfil limpo de navegador

Para testes manuais ou automatizados, use um perfil dedicado (sem extensões, sem histórico). Em automação, prefira iniciar o navegador com um diretório de perfil temporário.

• Desative extensões e sincronização.
• Garanta que o navegador esteja na mesma versão entre execuções (fixe a versão no CI).
• Evite rodar com devtools aberto durante medições, pois pode alterar comportamento e consumo.

Controle de energia e recursos

Em laptops, o modo de energia altera CPU e pode mudar resultados. Para medições consistentes:

• Use modo “alto desempenho” quando possível.
• Mantenha o dispositivo conectado na tomada.
• Evite rodar builds pesados, downloads ou múltiplos navegadores em paralelo.

Isolamento de ruído

Feche apps que consomem CPU/rede (Slack, Teams, backups, indexadores). Em CI, prefira runners dedicados ou limites de concorrência para não executar testes de performance junto com tarefas pesadas.

Controle de cache: frio vs. aquecido (e por que medir os dois)

Cache é uma das maiores fontes de inconsistência. Defina explicitamente se o teste é:

• Cold cache: simula primeira visita. Limpe cache, storage e service worker entre execuções.
• Warm cache: simula retorno. Faça uma navegação “de aquecimento” antes de medir.

Ambos são válidos, mas respondem perguntas diferentes. O erro comum é misturar sem perceber: rodar uma vez com cache frio e outra com cache aquecido e concluir que “melhorou”.

Checklist de limpeza (quando aplicável)

• Cache HTTP (disk/memory cache).
• Cookies e storage (localStorage, sessionStorage, IndexedDB).
• Service worker e caches do SW.
• DNS cache (em alguns cenários avançados).

Throttling de rede e CPU: como usar sem criar falsos resultados

Limitar rede/CPU ajuda a simular condições mais restritas e amplificar diferenças. Porém, é fácil criar um cenário artificial que não representa seu público. Para consistência:

• Escolha um perfil fixo e documentado (ex.: “4G lento” com latência X e throughput Y).
• Use o mesmo método de throttling (do navegador, do sistema, ou da ferramenta) em todos os testes.
• Evite misturar “throttling no devtools” em um teste e “throttling via ferramenta” em outro.

Quando possível, mantenha dois perfis: um mais realista (próximo do seu público) e outro mais restritivo para detectar regressões cedo. O importante é que cada perfil seja sempre o mesmo.

Escolhendo URLs e fluxos representativos

Consistência também é medir sempre as mesmas coisas. Defina um conjunto de páginas/rotas e fluxos que representem o produto:

• Páginas críticas: landing, listagem, detalhe, checkout, login.
• Rotas com variação: páginas com muitos itens, filtros, busca.
• Estados: logado vs. deslogado, com/sem feature flag.

Evite medir páginas com conteúdo altamente variável (ex.: feed aleatório) sem fixar o estado. Se necessário, crie URLs de teste com parâmetros estáveis ou dados “congelados” em staging.

Dados determinísticos

Se a página depende de API, tente garantir respostas determinísticas para o teste:

• Em staging, use um dataset fixo.
• Em testes locais, considere mock/stub de API para isolar front-end quando o objetivo for comparar builds.
• Se medir produção, registre o contexto (ex.: usuário de teste, região, parâmetros) para repetir.

Quantas execuções fazer e como resumir resultados

Uma execução isolada é frágil. Rode múltiplas vezes e use estatísticas robustas:

• N: comece com 5 a 9 execuções por URL e perfil (frio/aquecido). Para CI, 3 pode ser o mínimo, mas aumenta risco de ruído.
• Resumo: prefira mediana para comparar builds (menos sensível a outliers). Para acompanhamento de experiência, percentis (p75/p95) são úteis, mas exigem mais amostras.
• Dispersão: registre desvio/intervalo (min–max) para saber se o teste está instável.

Defina um “limite de falha” que considere variância. Exemplo: reprovar PR apenas se a mediana piorar mais que X% e a piora se repetir em duas rodadas, ou se ultrapassar um orçamento definido.

Passo a passo prático: protocolo de teste manual consistente

1) Fixe versão e build

• Garanta que você está medindo um build específico (commit hash/tag).
• Use build de produção (minificado, com as mesmas flags), não o modo dev.

2) Prepare o ambiente

• Feche apps que consomem CPU/rede.
• Desative extensões ou use um perfil limpo.
• Conecte na tomada e fixe modo de energia.

3) Defina o perfil de rede/CPU

• Escolha um perfil documentado e mantenha igual em todas as execuções.
• Não altere durante a sessão de testes.

4) Escolha o modo de cache

• Cold: limpe dados do site antes de cada execução.
• Warm: faça uma navegação de aquecimento (ex.: abrir a página uma vez, aguardar estabilizar, então medir na segunda navegação).

5) Execute N vezes e registre

• Rode o mesmo fluxo N vezes.
• Registre: data/hora, URL, commit, perfil de rede/CPU, modo de cache, navegador/versão, máquina.

6) Compare com baseline

• Use a mesma metodologia para o baseline.
• Compare mediana e observe dispersão.

Passo a passo prático: padronizando medições no CI

O CI é onde a consistência costuma trazer mais valor: cada PR pode ser comparado com um baseline de forma automática.

1) Fixe dependências e versões

• Fixe versão do Node, gerenciador de pacotes e navegador.
• Use lockfiles e builds reproduzíveis.

2) Garanta build de produção

• Execute o build com as mesmas flags do deploy.
• Sirva os arquivos estáticos com um servidor simples e consistente.

3) Isole o runner

• Evite rodar testes de performance em runners compartilhados com alta concorrência.
• Se possível, use máquina dedicada ou limite jobs simultâneos.

4) Defina cenários e repetições

• Liste URLs e fluxos.
• Defina N execuções por URL.
• Defina cold/warm conforme objetivo.

5) Salve artefatos para auditoria

• Relatórios brutos (JSON/HTML) e logs.
• Config do teste (perfil de rede/CPU, versão do navegador).
• Commit hash e timestamp.

6) Estabeleça critérios de falha

• Use thresholds com margem para ruído.
• Considere “flaky allowance”: se falhar, reexecutar uma vez para confirmar.

Consistência em testes com autenticação e estados complexos

Aplicações reais exigem login, permissões e dados personalizados. Para manter consistência:

• Usuário de teste fixo: crie contas específicas com dados estáveis.
• Seed de dados: em staging, recrie o estado antes do teste (ex.: carrinho com 3 itens).
• Feature flags: fixe flags para o teste (desativar experimentos ou travar em uma variante).
• A/B tests: desabilite para testes sintéticos ou force uma variante via parâmetro/cookie.

Se o fluxo depende de tokens, automatize a obtenção de credenciais de forma segura (variáveis secretas no CI) e evite medir com sessões expirando no meio do teste.

Como lidar com variabilidade do servidor e da CDN

Mesmo com front-end idêntico, o tempo de resposta pode variar por cache e carga. Para reduzir ruído:

• Teste em janelas com menor instabilidade (evite horários de deploy).
• Registre se houve cache hit/miss quando possível (logs do CDN, headers).
• Separe métricas de rede/servidor das de renderização quando estiver investigando (ex.: medir TTFB separadamente em relatórios).

Em staging, garanta que o CDN e compressão estão configurados de forma semelhante à produção; caso contrário, você pode “otimizar” algo que só existe no staging.

Registro e rastreabilidade: o que salvar para comparar no futuro

Sem rastreabilidade, o número vira um print solto. Padronize um registro mínimo:

• Identificador do build: commit hash, branch, tag, número do pipeline.
• Ambiente: URL base, região, staging/prod.
• Config: perfil de rede/CPU, modo de cache, N execuções, lista de URLs.
• Agente: navegador e versão, SO, tipo de máquina/runner.
• Resultados brutos e agregados: valores por execução + mediana/p75.

Isso permite responder “o que mudou?” quando surgir uma regressão semanas depois.

Exemplo de checklist operacional (para colar no repositório)

Protocolo de medição (sintético) - v1

Ambiente:
- URL: https://staging.exemplo.com
- Região: us-east-1

Agente:
- Chrome 120 (fixo)
- Runner: ubuntu-latest (dedicado)

Perfis:
- Rede: 4G lento (latência 150ms, down 1.6Mbps, up 750Kbps)
- CPU: throttling 4x

Cenários:
- / (home)
- /produtos?categoria=tenis (listagem estável)
- /produto/123 (detalhe estável)

Execução:
- 7 repetições por URL
- Modo: cold cache (limpar storage e cache a cada repetição)

Agregação:
- Comparar mediana por URL
- Falhar se piorar > 5% em 2 ou mais URLs

Artefatos:
- Salvar relatório bruto + logs + commit hash

Armadilhas comuns que quebram consistência (e como evitar)

Comparar resultados de ferramentas/modos diferentes

Evite comparar um teste rodado com throttling do devtools com outro rodado em CI com outro perfil. Se precisar trocar ferramenta ou perfil, crie uma nova linha de base e documente a mudança.

Medir com o app em modo desenvolvimento

Modo dev altera bundling, caching e comportamento. Para comparar releases, meça sempre builds de produção.

Rodar poucos testes e “confiar no melhor número”

Escolher o melhor resultado é viés. Use mediana e registre dispersão.

Ignorar estado do usuário

Um teste logado pode carregar mais dados, mais scripts e mais componentes. Se o objetivo é representar a maioria, defina qual estado é o padrão e mantenha fixo.

Não versionar o protocolo

Seu processo evolui. Versione o protocolo (v1, v2) e mantenha histórico para entender por que números antigos não batem com os atuais.