Tips para Mejorar el Desempeño de tus Aplicaciones Web

Vivimos en tiempos donde todo el mundo parece tener prisa, queremos todo “ya” y no deseamos perder ni un segundo. Lo mismo sucede cuando usamos aplicaciones web o móviles, queremos información precisa y presentada rápidamente. En este artículo presento dos buenas prácticas en el desarrollo de aplicaciones: Diseñar patrones de interacción enfocados en la percepción del tiempo, y la verificación de tiempos de respuestas, ejecutando pruebas de performance usando herramientas para tal propósito.

Rápido es mejor que lento

Una de las empresas que hace mayor énfasis en la velocidad es Google, que desde sus primeros días persigue con obsesión el mantra “rápido es mejor que lento”. Y es que el tiempo verdaderamente es dinero, como se aprecia en las siguientes estadísticas [1]:

• Una demora de 400 milisegundos en los resultados de búsqueda en Google provoca una disminución del tráfico en 0.44%.

• El 80% de los usuarios de YouTube deja de ver un video si este se detiene durante su reproducción.

• Edmunds.com redujo el tiempo de carga promedio de una sección de su sitio web de 9 segundos a 1.4 y con ello la cantidad de páginas vistas por sesión aumentó 17% y las ventas de publicidad aumentaron 3%.

• Cuando Shopzilla disminuyó la latencia de su sitio web de 7 segundos a 2, los ingresos por ventas en línea aumentaron cerca de 12%.

En resumen, al disminuir el tiempo de carga en un sitio web, la gente usa y compra más en este.

Percepción del tiempo de respuesta

Un sitio bien diseñado no es solamente lo fácil que es de usar o lo elegante que se ve. Un sitio no está bien diseñado a menos que el usuario final esté satisfecho con su experiencia. Un aspecto pasado por alto en muchas ocasiones es la percepción del performance de una aplicación.

El tiempo puede analizarse desde dos puntos diferentes: objetivo y psicológico. Cuando hablamos del “tiempo medible”, estamos hablando de la hora objetiva o la hora del reloj. El tiempo objetivo, sin embargo, suele ser diferente de cómo los usuarios perciben el tiempo mientras esperan o interactúan con una aplicación. Cuando hablamos de la percepción del tiempo de respuesta del usuario final, nos referimos al tiempo psicológico o mental.

Esta percepción de “rapidez” no solo depende del tiempo de respuesta, sino también por el tipo de respuesta visual que el usuario final percibe. Si alguna funcionalidad demora más de lo normal, notamos "cada segundo" en este intervalo de tiempo. Sin embargo, si la funcionalidad presentara alguna ayuda visual que nos indicara lo que está ocurriendo, la percepción del tiempo de respuesta sería mucho menor.

Una forma efectiva de hacer que un website se perciba más rápido es usar una “skeleton screen”. Una skeleton screen se llena gradualmente del contenido de la página web; esto muestra al usuario que algo está sucediendo y lo mantiene interesado. La figura 1 muestra a la izquierda un esqueleto inicial y a la derecha la versión final de una pantalla.

Figura 1. Skeleton screen

 

La representación progresiva de imágenes se basa en la idea de que cuanto más rápido pueda obtener una imagen completa en el navegador, independientemente de la resolución, mejor será la experiencia del usuario final, a diferencia de las imágenes de referencia (baseline), que se cargan línea por línea y tardan mucho más tiempo en desplegar la imagen completa (ver figuras 2a y 2b).

Figura 2. Como se carga imagen baseline vs progressive

Otra técnica útil es utilizar indicadores de progreso. Cuando las personas no tienen una idea de cuánto queda de un proceso en particular, sentirán que lleva más tiempo. Los indicadores de progreso muestran cuánto tiempo el usuario tendrá que esperar. Las personas amamos los movimientos, sobre todo porque la animación apoya la esencia de la interacción real, crea el nivel de sentimientos y percepción cercanos a lo que la gente tiene cuando interactúa con un objeto físico en la vida real. Los estudios demuestran que las animaciones bien implementadas tienen un efecto directo sobre la carga cognitiva. "Sin embargo, es importante tener en cuenta que las animaciones mal diseñadas o demasiado complejas pueden tener un impacto negativo en las aplicaciones. Esto indirectamente puede afectar la percepción del tiempo necesario para completar determinada acción.

Pruebas de performance

Para mejorar, tenemos que medir, y para medir el desempeño necesitamos realizar pruebas de performance. Con este tipo de pruebas es posible simular un comportamiento similar al que podría tener una aplicación aún sin ser desplegada en producción. Una de las características que podrían simularse con este tipo de pruebas es la “concurrencia de usuarios”, esta característica tiene un enorme impacto en los tiempos de respuesta, y en el comportamiento de los recursos de los servidores (memoria, disco, cpu, red). Para la ejecución de estas pruebas se utiliza herramientas generadoras de carga, como es el ejemplo de JMeter [2].

Técnicamente, el rendimiento se clasifica en el modelo de calidad del producto ISO 25010 [ISO25000] como una característica de calidad no funcional con las siguientes tres subcaracterísticas: comportamiento del tiempo, utilización de recursos, capacidad [3]:

La mayoría de los problemas de rendimiento giran en torno a la velocidad, el tiempo de respuesta, el tiempo de carga y la escalabilidad deficiente. La velocidad es a menudo uno de los atributos más importantes de una aplicación.

Seguir una metodología adecuada garantiza un exitoso proceso de prueba de performance. A continuación listo las actividades que pueden formar parte de este proceso:

1. Identificar criterios de aceptación del performance.

2. Identificar el entorno de prueba

3. Plan de pruebas de performance.

4. Diseño de pruebas de performance.

5. Scripting.

6. Configuración del entorno de prueba.

7. Ejecutar pruebas de performance.

8. Analizar, afinar y volver a probar.

Existe una amplia variedad de herramientas de prueba de performance disponibles en el mercado. Este artículo se centra en Apache JMeter, una de las herramientas más usadas para est pr. Apache JMeter puede usarse para probar el rendimiento tanto en recursos estáticos como dinámicos. Se puede usar para simular una carga en un servidor, grupo de servidores, red u objeto para probar su resistencia o para analizar el rendimiento general bajo diferentes tipos de carga. JMeter simula un grupo de usuarios que envían solicitudes a un servidor de destino y devuelve información estadística del servidor de destino.

A continuación listo algunas ventajas de JMeter:

• Código abierto, es totalmente gratuito, permite al desarrollador usar el código fuente para el desarrollo y cuenta con el apoyo de la gran comunidad en línea.

• Fácil de usar y aprender.

• Puede realizar tareas sencillas o avanzadas.

• Se pueden probar diferentes servidores y servicios como HTTP, HTTPS, FTP Database, LDAP, SMTP, POP3, IMAP, TCP, SOAP, REST.

• Disponible para distintas plataformas (basado en Java).

Conclusión

El rendimiento en las aplicaciones es muy importante. Puede significar la diferencia entre realizar una venta o perder un cliente.

Según Jacob Nielsen [4], hay 3 límites importantes a considerar en el tiempo de respuesta.

• 0.1 segundos es el límite para que el usuario sienta que el sistema reacciona instantáneamente a su manipulación directa.

• 1.0 segundo es el límite para que los pensamientos del usuario permanezcan sin interrupciones, aunque notarán algún retraso.

• 10 segundos es el límite para mantener la atención del usuario; en otras palabras, el punto donde se produce el abandono.

La investigación de “3 límites de tiempo de respuesta” se escribió en 1993 (basada en una investigación de 40 años realizada por pioneros de factores humanos), entonces, ¿cómo es posible que una investigación realizada hace más de 20 años sea útil en los tiempos actuales? ¡Sencillo! Los principios que rigen la interacción de los usuarios con las aplicaciones dependen en parte de la sociología y la psicología. Aunque la tecnología cambia, nuestros deseos, motivaciones, emociones y dinámicas sociales no varían tanto.

Referencias

[1] Urs Holzle. “The Google Gospel of Speed”. https://sg1.run/xv

[2] Apache JMeter. https://jmeter.apache.org

[3] ISTQB, Performance Testing Foundation Level. https://sg1.run/xw

[4] J. Nielsen. “Response Times: The 3 Important Limits”. https://sg1.run/xx

[5] I. Rocca. “Mejorando la Experiencia de Usuario”. Hablemos de TI. https://sg1.run/xy