Un desarrollador descubrió que conectar un depurador de Chrome DevTools a través de Playwright o Puppeteer ralentiza las cargas basadas en fetch en más de 20 veces, convirtiendo los benchmarks de rendimiento cotidianos en datos engañosos.

El enigma que desencadenó la investigación

Coffer, un almacén de archivos basado en el navegador que cifra los datos antes de enviarlos al servidor, realiza habitualmente cargas de clase gigabit a través de una red local. Cuando el equipo midió las velocidades de carga, detectó una brecha: las descargas saturaban el enlace, pero las cargas avanzaban a paso de tortuga, a aproximadamente una octava parte del ancho de banda disponible. La discrepancia motivó tres rondas de cambios de código que no lograron surtir efecto, hasta que un cuarto "arreglo" pareció ofrecer un salto masivo, solo para desaparecer cuando se eliminó el depurador.

Lo que el equipo intentó primero

Los ingenieros buscaron a los sospechosos habituales:

  • Tamaño del fragmento (Chunk size) – Duplicar el bloque de 16 MiB a 32 MiB no cambió el rendimiento (throughput).
  • Pipelining – Superponer el cifrado del siguiente bloque con la carga actual produjo una modesta ganancia del 13 %, indistinguible del ruido de medición.
  • Concurrencia – Ejecutar varias cargas en paralelo se topó con la misma velocidad total, lo que sugería un límite global.

Ninguna de estas variaciones explicaba la ralentización de 8×.

Una sorprendente comparación directa

Para aislar el problema, el equipo cambió la implementación del cliente. Usando .NET HttpClient registraron 700 Mbps en la misma red; la misma solicitud emitida desde la API fetch() de Chromium se estancó en 140 Mbps. El marcado contraste señaló a la pila de red del navegador como el culpable, hasta que el siguiente experimento demostró lo contrario.

El coste oculto del depurador

Playwright y Puppeteer controlan Chrome a través del Chrome DevTools Protocol (CDP). Ese protocolo conecta un depurador al proceso del navegador, exponiendo eventos de red, instantáneas del DOM y registros de la consola. El equipo realizó una prueba enfocada: una llamada a fetch() que enviaba una carga útil de tipo Uint8Array, una vez con el depurador CDP conectado y otra sin él.

  • Depurador conectado: 113 Mbps

La presencia del depurador redujo la velocidad de carga en más de 20×. Una prueba manual en una ventana normal de Edge —sin depurador conectado— alcanzó los 600+ Mbps, confirmando que el propio navegador puede manejar el tráfico cuando no tiene obstáculos.

Una mejora modesta y real

Aunque el depurador era el principal responsable de la ralentización, el equipo descubrió una optimización real: cambiar el cuerpo de la solicitud de un Uint8Array a un Blob aumentó la velocidad de Chromium en aproximadamente un 30 %. Es un ajuste útil, pero ni de lejos el impulso "milagroso" que se esperaba originalmente.

Por qué esto es importante para los ingenieros

  • Los instrumentos pueden mentir. Las herramientas de rendimiento que automatizan los navegadores son, en sí mismas, parte de la cadena de medición.
  • Los benchmarks que parecen imposibles merecen una comprobación de coherencia. Si los números divergen drásticamente de la capacidad de la red, el entorno de medición debería ser el primer sospechoso.
  • Un resultado nulo es valioso. Confirmar que un cambio no hace nada evita perder esfuerzos persiguiendo errores fantasma.
  • Los controles manuales son un seguro económico. Ejecutar la misma operación en una ventana de navegador convencional puede revelar la sobrecarga oculta de la instrumentación.

Contrapunto: cuando los depuradores son indispensables

Los depuradores proporcionan visibilidad sobre el comportamiento de la página, los rastros de errores y las líneas de tiempo de red que, de otro modo, serían inaccesibles. Para pruebas de regresión, auditorías de seguridad o interacciones de UI complejas, conectar un depurador CDP suele ser innegociable. La clave es separar las pruebas funcionales de la medición de rendimiento puro, y desactivar el depurador cuando este último sea el objetivo.

Conclusión: Las herramientas que hacen posible las pruebas automatizadas también pueden convertirse en la mayor fuente de distorsión del rendimiento. Antes de culpar al navegador, a la red o al código, verifique que ningún depurador esté ralentizando silenciosamente el flujo de datos.