Probar el frontend con 3G lento destapa fallos que el CI nunca ve
Un desarrollador documenta las condiciones de carrera y los recursos que no llegan cuando la red va lenta, y cómo reproducirlos en Cypress y Playwright dentro del pipeline.
Los runners de integración continua van por fibra y responden en microsegundos. Por eso un pipeline en verde no dice nada sobre lo que ocurre cuando la red del usuario tarda cientos de milisegundos en cada ida y vuelta. Un desarrollador ha contado lo que apareció al meter su aplicación en el perfil «Slow 3G» de las herramientas de desarrollo de Chrome: condiciones de carrera y recursos que no llegan, fallos que ninguna prueba contra localhost había detectado.
Por qué el CI no lo ve
El motivo es estructural. Los frameworks de test simulan APIs o sirven los estáticos desde un servidor local, y la pila de red del navegador casi nunca se ejercita con latencia y ancho de banda realistas. El resultado es código que pasa las comprobaciones y se rompe en un móvil con la red congestionada.
Para reproducirlo hay dos vías. Playwright trae el throttling de serie: se declara en test.use() con los parámetros de descarga, subida y latencia, y en su ejemplo van 500 KB/s en cada sentido con 400 ms de retardo. En Cypress hay que inyectar opciones en el arranque del navegador desde on('before:browser:launch', ...), un camino menos directo porque depende de con qué opciones se lance el binario.
Lo que se rompió
- Parpadeo de imágenes y placeholders. Al servirse todo desde localhost, el evento de carga dispara antes de que el navegador haya calculado el hueco del elemento. La salida que propone es una regla CSS que mantenga el elemento oculto hasta que tenga dimensiones reales.
- El ping de analítica que nunca sale. El XHR simulado responde al instante, pero la llamada de
sendBeaconse pierde con la red saturada. Su arreglo: encolar el envío y reintentar con back-off exponencial. - Interfaz obsoleta por carrera. Dos peticiones en paralelo resuelven en orden sobre fibra, y en 3G la más lenta pisa el dato más reciente. Aquí propone validar con un token de versión, del estilo de un ETag, y descartar toda respuesta anterior a la última petición lanzada.
- Retraso en la inyección de CSS-in-JS. El estilo se inyecta después de montar el componente, así que en una red lenta la vista se pinta antes de tener estilos y aparece el clásico destello de contenido sin formatear.
Los cuatro casos se reprodujeron igual en Chrome, Firefox y Safari al aplicar el preset de 3G lento. Según el autor, ningún benchmark sintético los detectó porque todos dependen de suposiciones de temporización que solo se sostienen cuando el enlace es rápido.
La conclusión práctica es añadir un job de red lenta al pipeline y tratar sus fallos como regresiones de verdad, además del manoseo de siempre: gestionar respuestas fuera de orden, timeouts y cargas fallidas. El autor sostiene que una sola pasada nocturna con la red estrangulada le encuentra más errores que la suite completa de tests unitarios. Es su impresión a partir de su propio proyecto, no una medición con cifras, así que conviene tomarla como lo que es: una hipótesis razonable que cada equipo puede comprobar en su repositorio esta misma semana.
