La verdad es que es una pregunta que cada vez me tengo que hacer más a menudo, y es que no hay duda de que a la hora de realizar el análisis del rendimiento de una aplicación web, o bien, a la hora de definir los requisitos mínimos de rendimiento que ésta debe cumplir, este es uno de los datos,  más importante que tenemos que definir.

El tiempo de carga o tiempo de respuesta de nuestra aplicación web va a depender de numerosos factores, siendo un hecho que el rendimiento de la aplicación va a disminuir a medida  que damos servicio a un mayor número de usuarios concurrentes. En el siguiente gráfico muestro un ejemplo de como puede variar el rendimiento de una página web a medida que más usuarios se conectan a ella:

Para este caso concreto, vemos como el rendimiento de nuestra página web empieza a degradarse a partir de 200 usuarios concurrentes. En ese punto, el tiempo de respuesta empieza a crecer de una manera exponencial y es ya superior a los 10 segundos. La pregunta aquí es, ¿por qué establezco 10 segundos como límite? ¿Podría haber dicho 8 o 4? La verdad es que sí, el hecho de elegir un valor u otro puede ser demasiado arbitrario, depende de los requisitos de nuestra aplicación y carece del respaldo de un criterio ampliamente aceptado sobre este dato.

¿Cómo establecemos este dato? En alguno de los primeros proyectos en los que participé, el tiempo de respuesta máximo que se estableció estaba en torno a los 2 segundos. Este era un tiempo que parece razonable para un administrador de una página o para un usuario "impaciente", pero en la mayor parte de los casos está alejado de la realidad, en cuanto a que un usuario que se encuentra navegando en nuestro sitio, va a poder encontrar igualmente aceptable un tiempo de 4 segundos.

Vemos cómo el tipo de usuario al que va destinado nuestra aplicación es un primer elemento a tener en cuenta a la hora de definir estos tiempos máximos.

En segundo lugar, ¿tiene importancia el tipo de acción que el usuario está realizando en el tiempo de respuesta aceptable? La respuesta es claramente sí. Todos nosotros sabemos que el tiempo máximo que estamos dispuesto a esperar en la página de login no es el mismo que en un página en la que hacemos una consulta muy pesada sobre una base de datos para la obtención de un informe mensual.  La calidad que el usuario percibe sobre nuestra página puede verse afectada si en la página de login de hacemos esperar 20 segundos, provocando incluso que el usuario decida abandonar la página. Sin embargo, si el usuario puede ser mucho más paciente cuándo tiene la certeza de que la operación que realiza conlleva mucho más procesamiento.

A partir de lo anterior, vemos como el tipo de contenido que el usuario está visitando también va a influir en el tiempo de carga aceptable.

Os comentaba antes que en algunos proyectos el tiempo máximo de carga se establece en 2 segundos En otros en cambio, el tiempo de carga se establece en 30 segundos. Para este tipo de páginas lentas, que implican consultas pesadas o descarga de software extra, es fundamental nutrir al usuario con información sobre lo que está ocurriendo. Se hace fundamental proveer de mecanismos cómo las barras de progreso que hacen que el usuario no se impaciente, y espere el tiempo necesario para la carga de la página. El otro día me encontré con el siguiente ejemplo descargando el Windows Live Writer:

De hecho, este fue el segundo mensaje que aparecía, ya que la descarga estaba siendo demasiado lenta, y los mensajes que se daban al usuario eran acordes al tiempo que ya llevaba esperando. En este caso, estuve más de 2 minutos esperando poder realizar la instalación antes de desistir. Un tiempo de 2 minutos puede llegar a ser aceptable para el usuario siempre y cuando le mantengamos informado sobre lo que está ocurriendo. En casos en los que el usuario no tenga porque conocer qué tipo de contenido es más o menos lento (tal y cómo comentaba en el punto anterior), la información que le proporcionemos puede ser fundamental para influir en su concepto de calidad o de tiempo de respuesta aceptable.

Incluyo pues cómo último elemento la información al usuario, que sumado al tipo de usuario y al tipo de contenido, nos va a ayudar a fijar los requisitos de calidad para nuestra aplicación. Así en lugar de fijar un tiempo máximo de respuesta por página, deberíamos fijarlo según el tipo de contenido, el tipo de usuario al que va dirigida y la cantidad de información que proporciona.

Os animo a que completéis este post con comentarios sobre experiencias propias en proyectos, o sobre aquellos otros elementos que podéis considerar interesante incluir en la lista de elementos a tener en cuenta.