Um desenvolvedor descobriu que anexar um debugger do Chrome DevTools através do Playwright ou Puppeteer reduz a velocidade de uploads baseados em fetch em mais de 20 vezes, transformando benchmarks de desempenho cotidianos em dados enganosos.

O enigma que desencadeou a investigação

Coffer, um armazenamento de arquivos baseado em navegador que criptografa dados antes de enviá-los ao servidor, realiza rotineiramente uploads de classe gigabit em uma rede local. Quando a equipe mediu as velocidades de upload, percebeu uma lacuna: os downloads saturavam o link, mas os uploads avançavam lentamente a cerca de um oitavo da largura de banda disponível. A discrepância motivou três rodadas de alterações de código que não surtiram efeito, até que uma quarta "correção" pareceu entregar um salto massivo — apenas para desaparecer quando o debugger foi removido.

O que a equipe tentou primeiro

Os engenheiros buscaram os suspeitos usuais:

  • Tamanho do chunk – Dobrar o bloco de 16 MiB para 32 MiB não alterou o throughput.
  • Pipelining – Sobrepor a criptografia do próximo bloco ao upload atual resultou em um ganho modesto de 13%, indistinguível do ruído de medição.
  • Concorrência – Executar vários uploads em paralelo limitou-se à mesma velocidade total, sugerindo um teto global.

Nenhuma dessas variações explicou a lentidão de 8×.

Uma comparação direta surpreendente

Para isolar o problema, a equipe trocou a implementação do cliente. Usando o .NET HttpClient, eles registraram 700 Mbps na mesma rede; a mesma requisição feita a partir da API fetch() do Chromium travou em 140 Mbps. O contraste gritante apontou a stack de rede do navegador como a culpada — até que o próximo experimento provou o contrário.

O custo oculto do debugger

Playwright e Puppeteer controlam o Chrome via Chrome DevTools Protocol (CDP). Esse protocolo anexa um debugger ao processo do navegador, expondo eventos de rede, snapshots do DOM e logs do console. A equipe realizou um teste focado: uma chamada fetch() enviando um payload Uint8Array, uma vez com o debugger do CDP anexado e outra sem.

  • Debugger anexado: 113 Mbps

A presença do debugger reduziu a velocidade de upload em mais de 20×. Um teste manual em uma janela comum do Edge — sem debugger anexado — atingiu mais de 600 Mbps, confirmando que o próprio navegador consegue lidar com o tráfego quando não está sobrecarregado.

Uma melhoria real e modesta

Embora o debugger tenha sido responsável pela maior parte da lentidão, a equipe ainda descobriu uma otimização genuína: mudar o corpo da requisição de um Uint8Array para um Blob aumentou a velocidade do Chromium em cerca de 30%. É um ajuste útil, mas longe do aumento "milagroso" esperado originalmente.

Por que isso é importante para engenheiros

  • Instrumentos podem mentir. Ferramentas de performance que automatizam navegadores fazem parte da própria cadeia de medição.
  • Benchmarks que parecem impossíveis merecem um teste de sanidade. Se os números divergirem drasticamente da capacidade da rede, o ambiente de medição deve ser o primeiro suspeito.
  • Um resultado nulo é valioso. Confirmar que uma alteração não faz nada evita o desperdício de esforço perseguindo bugs fantasmas.
  • Controles manuais são um seguro barato. Executar a mesma operação em uma janela de navegador comum pode revelar o overhead oculto da instrumentação.

Contraponto: quando debuggers são indispensáveis

Debuggers fornecem visibilidade sobre o comportamento da página, rastros de erro e cronogramas de rede que, de outra forma, seriam inacessíveis. Para testes de regressão, auditorias de segurança ou interações de UI complexas, anexar um debugger do CDP é frequentemente inegociável. A chave é separar o teste funcional da medição de performance bruta, e desativar o debugger quando o objetivo for esta última.

Conclusão: As ferramentas que tornam o teste automatizado possível também podem se tornar a maior fonte de distorção de performance. Antes de culpar o navegador, a rede ou o código, verifique se nenhum debugger está reduzindo silenciosamente o fluxo de dados.