Throttling: simular una red lenta y saber qué simula
Los tres parámetros de un perfil de red, qué modela el throttling y qué no, los perfiles personalizados, y el throttling de CPU como complemento imprescindible.
Todo el desarrollo web ocurre en una red que no se parece a la de nadie: baja latencia, ancho de banda amplio, sin pérdida de paquetes y con el servidor a pocos milisegundos. Simular condiciones peores no es una comprobación opcional, es la única forma de que los problemas que sufren los usuarios aparezcan en tu pantalla. Y como toda simulación, modela unas cosas y otras no, así que conviene saber exactamente qué se está probando.
- Explicar los tres parámetros que definen un perfil de red y cuál domina en cada caso.
- Crear perfiles personalizados que correspondan a las condiciones de tus usuarios.
- Enumerar lo que el throttling no simula y qué consecuencias tiene.
- Combinar throttling de red y de CPU para reproducir un dispositivo de gama media.
Los tres parámetros
Un perfil de red se define con tres números y su efecto es muy distinto.
El ancho de banda de bajada, en bits por segundo. Determina cuánto tarda en llegar un fichero grande. Es el parámetro que la gente asume que domina y el que menos manda en la mayoría de los casos.
El ancho de banda de subida. Solo importa en peticiones con cuerpo grande: subidas de fichero, envíos de datos voluminosos.
La latencia de ida y vuelta, en milisegundos. Es el tiempo que tarda un paquete en llegar y volver, y es el parámetro que domina la experiencia en la inmensa mayoría de las páginas.
La razón de que la latencia mande es la de siempre: cada conexión nueva cuesta entre uno y tres viajes de ida y vuelta antes de transferir nada, y cada eslabón de una cadena de dependencias cuesta otro. Una página con una cadena crítica de cinco eslabones y una latencia de doscientos milisegundos paga un segundo entero solo en ir y venir, independientemente de lo que pesen los recursos. Duplicar el ancho de banda no cambia ese segundo; reducir la cadena a dos eslabones, sí.
Los nombres de los perfiles predefinidos han cambiado varias veces conforme las redes reales han mejorado, y seguirán cambiando. Lo que no cambia son los tres números, así que la costumbre útil es mirar los valores del perfil que elijas en lugar de fiarte del nombre, y crear perfiles propios con los números de tu público real.
Perfiles personalizados
La pestaña de condiciones de red del cajón inferior, o el desplegable del panel, permiten añadir perfiles con nombre y con los tres valores a mano.
Merece la pena crear dos o tres que correspondan a tus usuarios reales. Los datos para ponerlos salen de tu propia analítica de rendimiento de campo, no de una tabla genérica: si tienes métricas reales de usuarios, sabes qué latencias y qué anchos de banda tiene el percentil setenta y cinco de tu público, y ese es el perfil contra el que hay que probar.
Si no tienes esos datos, dos perfiles cubren la mayoría de las situaciones: uno de móvil en condiciones mediocres, con latencia de unos ciento cincuenta milisegundos y unos pocos megabits de bajada; y uno de conexión mala de verdad, con latencia de varios cientos de milisegundos y menos de un megabit.
Y hay un perfil que conviene probar aunque parezca extremo: desconectado. Es la única forma de comprobar que tu aplicación no se rompe cuando la red desaparece a mitad de una sesión, cosa que en móvil ocurre continuamente.
Lo que el throttling no simula
Cuatro cosas, y las cuatro importan.
La pérdida de paquetes. Una red móvil real pierde paquetes y los retransmite, lo que produce retrasos irregulares y comportamientos mucho peores que una red lenta pero limpia. El throttling simula una tubería estrecha y perfecta.
La variabilidad. Una conexión real fluctúa: va bien durante cinco segundos y se atasca durante dos. El throttling aplica valores constantes.
El coste de la radio. En móvil, la radio tarda en activarse tras un periodo de inactividad, y eso añade latencia a la primera petición después de una pausa. Es una de las razones por las que el sondeo periódico es tan caro en batería y en tiempo.
El estado del dispositivo. Un móvil con la CPU caliente reduce su frecuencia, y eso afecta a todo. El throttling de CPU se acerca, pero no modela la reducción térmica.
La consecuencia práctica: el throttling es una cota inferior de lo malo que puede ser. Si algo falla con throttling, falla seguro en la realidad. Si funciona con throttling, todavía puede fallar en la realidad.
El throttling de CPU
Vive en el panel de rendimiento y en la pestaña de condiciones, y aplica un factor de ralentización a la ejecución de JavaScript y al trabajo del hilo principal.
Es imprescindible como complemento del de red, porque el dispositivo de tus usuarios no solo tiene peor conexión: tiene un procesador varias veces más lento que el tuyo. Probar con red lenta y CPU rápida produce un escenario que no existe: la aplicación espera mucho por la red y luego procesa todo instantáneamente.
Los factores habituales van de dos a veinte veces. Elegir el correcto depende del dispositivo objetivo, y una referencia práctica es que un móvil de gama media reciente corresponde aproximadamente a una ralentización de cuatro veces respecto a un portátil de desarrollo, y uno de gama baja o con algunos años, a diez o veinte.
La combinación que reproduce el escenario de la mayoría de los usuarios de una web de consumo es red móvil mediocre más CPU ralentizada cuatro veces. Muchas aplicaciones que se sienten instantáneas en el escritorio pasan a ser incómodas en esas condiciones, y ese es exactamente el punto del ejercicio.
Amplificar para diagnosticar
Hay un uso del throttling que no es medir sino diagnosticar, y es de los más rentables de toda la guía.
Cuando un bug es intermitente y sospechas de una carrera entre dos operaciones asíncronas, el throttling agresivo convierte la intermitencia en determinismo. Una ventana de veinte milisegundos entre dos eventos pasa a ser de dos segundos, y lo que fallaba una vez de cada treinta falla siempre.
Funciona en los dos sentidos, y ahí está la parte inteligente: si el fallo aparece con red lenta, la carrera la gana lo local; si aparece con CPU lenta y red rápida, la gana la respuesta. Esa asimetría te dice cuál de las dos ramas es la que llega antes en cada caso, que es exactamente la información que necesitas para arreglarlo.
Hay una distinción entre dos formas de fallar que conviene tener muy presente al diseñar estas pruebas, porque la intuición lleva a probar la equivocada. Una red desconectada produce un fallo rápido y explícito: la petición falla en milisegundos, el código entra en su rama de error, y si hay algún manejo razonable el usuario ve un mensaje. Es incómodo y es manejable. Una red muy lenta produce algo peor: nada. La petición no falla, sigue en vuelo durante treinta segundos, ningún camino de error se activa porque no hay error, y la interfaz se queda con un cargador girando indefinidamente. El usuario no sabe si esperar o recargar, y si recarga, la nueva petición compite por el mismo ancho de banda con la anterior que sigue viva. Es la peor experiencia posible y es la que casi nadie prueba, porque probar el modo desconectado es fácil y probar el modo lento requiere paciencia. Las tres cosas que esta prueba revela y que hay que implementar si no están: un tiempo límite explícito en las peticiones, porque el navegador no lo pone y una petición puede quedarse colgada indefinidamente; una señal al usuario cuando la espera se alarga, aunque sea un texto de que está tardando más de lo normal, porque el silencio es lo que hace que la gente recargue; y cancelación de las peticiones que ya no importan cuando el usuario navega a otra cosa, con un controlador de aborto, para que no sigan compitiendo por la conexión. Ninguna de las tres se echa de menos en desarrollo, y las tres deciden si la aplicación es usable en el metro. La forma de descubrir cuáles faltan es exactamente esta: poner el perfil más lento que tengas, usar la aplicación, y tener la paciencia de esperar en lugar de recargar.