Un equipo que distribuía un runtime de Python de 5,5 MB a los navegadores descubrió que el 69 % de los errores registrados durante un sprint reciente caían bajo un único título engañoso, y el 89 % de ellos eran en realidad tiempos de espera de red (timeouts). El error en el reporte envió a los desarrolladores por el camino de depuración equivocado y dejó a una parte considerable de los usuarios con fallos de descarga silenciosos, un problema que cualquier aplicación web que incluya activos pesados puede replicar pronto.

El panel de control engañó

El sistema de seguimiento de errores agrupa automáticamente los incidentes según la ubicación del código donde aparecen por primera vez. El título resultante parecía un simple error en el cargador del runtime, por lo que el sprint se dedicó a buscar rutas de código que nunca habían experimentado un timeout. Cuando el equipo analizó los metadatos subyacentes, surgió la imagen real: la mayoría de los fallos no eran errores en absoluto, sino conexiones de red estancadas que provocaron un tiempo de espera agotado.

Conclusión: Un título de error es una conveniencia, no un diagnóstico. Analice periódicamente los datos brutos para verificar qué representa realmente el encabezado.

La API de conexión del navegador proporcionó un valor provisional

Para evitar que los usuarios con conexiones lentas tuvieran que arrastrar una descarga de 5,5 MB, los desarrolladores consultaron la Network Information API del navegador (navigator.connection). La API informaba de un ancho de banda constante de 1,7 Mbps para cada visitante por primera vez.

Los navegadores emiten un valor predeterminado cuando no tienen datos históricos de un nuevo usuario. Ese valor predeterminado es una indicación, no una velocidad definitiva. Cuando el mismo valor provisional aparece en cada sesión nueva, indica que la API aún no está calibrada para ese público.

Conclusión: Trate cualquier señal de red que nunca varíe como un valor de respaldo (fallback), no como una métrica definitiva.

Las instantáneas únicas no son fiables

Tras descartar la indicación de ancho de banda poco fiable, el equipo cambió a una señal diferente que parecía funcionar en su conjunto de pruebas. Una ejecución de la prueba pasó, pero al repetirla tres veces, se produjeron fallos en cada ocasión. La velocidad de la red fluctúa continuamente. El código había tomado una única instantánea, tomado una decisión permanente y luego procedido incluso si la conexión cambiaba un momento después.

Conclusión: No base una acción permanente en una única lectura de un objetivo móvil. Suscríbase a los eventos de cambio en lugar de realizar una única consulta (polling).

Soluciones prácticas implementadas por el equipo

  • Suscribirse a los cambios de conexión. En lugar de leer navigator.connection una sola vez, el código ahora escucha el evento change y reacciona si el ancho de banda baja o sube durante la descarga.
  • Añadir un "watchdog" de falta de progreso. Un temporizador aborta cualquier solicitud que no avance tras un breve intervalo, liberando al navegador para que reintente o utilice un método de respaldo.
  • Dejar de cambiar de CDN a mitad de la descarga. Cambiar la fuente de un archivo grande en un enlace lento reinicia la transferencia desde cero, desperdiciando los bytes ya recibidos. La descarga ahora se mantiene en el CDN elegido inicialmente durante toda su duración.
  • Posponer el trabajo pesado de caché. Las tareas que escriben grandes cantidades de datos en la caché se posponen hasta que el runtime termine de cargarse, manteniendo corto el camino crítico.

Si sus paneles de control muestran una imagen inquietantemente ordenada, profundice más. Si una medición de red nunca cambia, trátela como un valor provisional. Y si una única instantánea decide el destino de una descarga de varios megabytes, está apostando por un espejismo. Esas apuestas se manifiestan como fallos silenciosos que erosionan la confianza del usuario, algo que ninguna cantidad de código ingenioso puede reparar por completo una vez ocurrido el problema.