Normalmente hacemos pruebas de nuestros desarrollos web sobre nuestro propio equipo, donde la transferencia de datos es prácticamente inmediata, en servidores de prueba ubicados en una red de área local, o incluso sobre un servidor de producción al que accedemos mediante una conexión a Internet de gran capacidad.

Sin embargo, nuestras aplicaciones web son muy diferentes cuando el cliente no dispone de una conexión de alta velocidad. Lo que nosotros percibimos en tiempo de desarrollo como una maravilla de agilidad, espectacularidad y facilidad de uso, puede ser un auténtico desastre para el cliente si no hemos tenido en cuenta que no todo el mundo puede disfrutar de conexiones de alta calidad.

Por esta razón, es interesante realizar de vez en cuando pruebas de nuestros sistemas reduciendo de forma artificial el ancho de banda disponible, de forma que podamos detectar en qué puntos podemos mejorar la experiencia del usuario en estos escenarios.

Una forma muy sencilla para hacerlo es utilizando Fiddler. Probablemente todos lo conoceréis, pues es una de esas herramientas gratuitas que con el tiempo se han hecho indispensables para los desarrolladores, ayudándonos a ver qué es lo que pasa por debajo de aplicaciones que utilizan HTTP para enviar o recibir datos desde el exterior.

Básicamente se trata de un proxy que intercepta todas las conexiones HTTP/HTTPS originadas en nuestro ordenador permitiéndonos guardaras en un registro, inspeccionarlas en detalle, repetirlas, e incluso modificar su contenido sin demasiado esfuerzo. Además, incluye un potente mecanismo que permite extenderlo mediante reglas programadas en lenguaje JScript.NET o plugins en forma de ensamblados .NET.

Rules > Performance > Simulate modem speeds

Fiddler trae de fábrica un conjunto de reglas que permiten personalizar el tratamiento de las peticiones HTTP que entran y salen de nuestra máquina, y una de ellas tiene el expresivo nombre “Simulate modem speeds”. Seguro que podréis intuir su utilidad ;-)

Así, basta con acudir al menú “Rules” de Fiddler, abrir el submenú “Performance” y seleccionar la opción oportuna:



La selección de esta opción hará que la velocidad de transmisión y recepción se reduzca a la habitual en un módem de 56Kbps. En concreto:

• Se introduce en la petición un retardo de 300ms por cada Kbyte enviado desde el navegador u aplicación cliente.
• Por cada Kbyte recibido en la respuesta de la petición, se introduce un retardo de 150ms.

De esta forma ya podemos tener una primera solución para poder probar nuestra web a una velocidad muy inferior a lo habitual, y comenzar a ver qué puntos podríamos mejorar.

Modificar los ajustes

La lógica de cada una de esas opciones que podéis activar o desactivar en el menú “Rules” está implementada mediante scripting, lo que deja abierta la posibilidad de alterarlas para adaptarlas a nuestras necesidades.

Por ejemplo, podríamos definir tiempos de retardo a nuestro antojo, y así probar cómo funcionaría nuestro sistema con distintas configuraciones de red para determinar cuál sería el mínimo razonable para utilizar un servicio.

Accediendo al menú “Rules > Customize Rules” tendremos acceso al código fuente del script de reglas usado por Fiddler, que se abrirá automáticamente en el bloc de notas de Windows para que podamos modificarlo a nuestro antojo. Eso sí, siempre con precaución, aunque si metemos la pata podemos seguir estas instrucciones para dejarlo todo como estaba.


El código que introduce los retardos podemos localizarlo fácilmente buscando el texto “modem” en el script, y es como sigue:

if (m_SimulateModem) {
   // Delay sends by 300ms per KB uploaded.
   oSession["request-trickle-delay"] = "300"; 
   // Delay receives by 150ms per KB downloaded.
   oSession["response-trickle-delay"] = "150"; 
}

La variable m_SimulateModem contiene un valor booleano que indica si la opción del menú está marcada o no, y, en caso afirmativo, los valores de los retardos se introducen en los parámetros request-trickle-delay y response-trickle-delay del objeto oSession, que contiene distintos settings que permiten modificar  el comportamiento de Fiddler. En concreto, estos dos parámetros indican los milisegundos a esperar antes de cada kbyte enviado, y antes de cada kbyte recibido, respectivamente.

Por tanto, si queremos limitar la velocidad de descarga aproximadamente a 100KBytes/s en un entorno local, bastaría con introducir en response-trickle-delay un retardo de 10ms:

// Delay receives by 10ms per KB downloaded.
oSession["response-trickle-delay"] = "10"; 

Al salvar el archivo se aplicarán los cambios en la configuración.

Añadir nuevas configuraciones

Vale, con lo visto anteriormente ya podemos modificar la velocidad de descarga, pero siempre machacando los valores utilizados por la opción del menú “Simulate Modem Speeds”. Sin embargo, podemos mejorar esto bastante creando nuestras propias opciones en el menú que nos permitan activar y desactivar de forma sencilla otras configuraciones, por ejemplo para seleccionar distintas velocidades a simular.

Para ello, primero localizamos el lugar del script donde se añade la opción “Simulate Modem Speeds”, y añadimos una opción similar para nuestro objetivo:

// Cause Fiddler to delay HTTP traffic to simulate typical 56k modem conditions
public static RulesOption("Simulate &Modem Speeds", "Per&formance")
var m_SimulateModem: boolean = false;

// Cause Fiddler to delay HTTP traffic to 100Kbytes/sec
public static RulesOption("Simulate 100Kbytes/sec", "Per&formance")
var m_Simulate100K: boolean = false;

A continuación, introducimos la condición para activar los límites cuando la variable booleana que hemos definido sea true. Para no complicarnos mucho, lo hacemos justo debajo del lugar donde ya hemos visto anteriormente que se establecen estos valores dependiendo de m_SimulateModem:

if (m_Simulate100K) {
   // For example, delay sends by 40ms per KB uploaded
   oSession["request-trickle-delay"] = "40"; 
   // Delay receives by 10ms per KB downloaded.
   oSession["response-trickle-delay"] = "10"; 
}

Salvando el archivo, ya tenemos una nueva opción en el menú para activar nuestro tope de velocidad:



¡Y esto es todo! Así de fácil es usar Fiddler para simular lentitud en las comunicaciones y poder comprobar la usabilidad en ese tipo de escenarios.

Pero antes de que se me olvide, un último comentario importante: todo lo dicho no es válido sólo en aplicaciones web. Estas comprobaciones pueden resultar también bastante clarificadoras en otro tipo de sistemas, como pueden ser aplicaciones Windows Store o de otro tipo que accedan a recursos externos mediante HTTP. Fiddler funcionará con la mayoría de ellas sin problema.

Publicado en Variable not found.