Como medir la performance en el frontend de un sitio web

Cuando hablamos de pruebas de performance solemos escuchar hablar de herramientas como jMeter, LoadRunner o Blazemeter, que nos permiten ejecutar múltiples requests a los servicios con la cantidad de carga que nosotros queramos. Esto sin embargo nos permite saber la performance del backend pero no la de la performance de la capa de frontend, por ejemplo los servicios pueden performar muy bien bajo mucha carga pero el frontend puede tener que ejecutar código javascript complejo que haga lento el sitio web en cuestión.

Que son las pruebas de carga y performance

Las pruebas de performance pretenden medir la velocidad, los tiempos de respuesta, el uso de recursos y la escalabilidad de un sistema bajo determinada cantidad de carga, a modo de detectar cuellos de botella en el sistema bajo prueba.

Cuales son los tipos de testing de carga y performance

Dentro de las pruebas de performance existen ciertos subtipos de ejecuciones, que nos permiten medir el comportamiento del sistema bajo diferentes circunstancias, por ejemplo:

  • Pruebas de carga: Son pruebas que buscan medir el comportamiento del sistema bajo cargas poco usuales (pero esperadas) de usuarios, como por ejemplo cuando se abren inscripciones para un curso en línea con cupos limitados en una universidad o cuando se vence el plazo para pagar un servicio. En esos momentos se espera que mucha mas gente de lo habitual ingrese al sistema y esto puede provocar enlentecimiento o caídas del mismo.
  • Pruebas de estrés: A diferencia de las pruebas de carga, las pruebas de estrés buscan sumar carga al sistema de manera paulatina para identificar el punto de ruptura del mismo, es decir, hasta cuanta carga puede soportar un sistema sin romperse, o cuanto tiempo puede funcionar al limite de carga soportada de manera confiable.
  • Pruebas de endurance: Estas pruebas se realizar para validar que el sistema bajo prueba pueda soportar una carga normal por un periodo de tiempo prolongado.
  • Pruebas de picos: Estas pruebas buscan ver el comportamiento del sistema cuando este recibe una cantidad de usuarios repentina, mayor a la normal.
  • Pruebas de volumen: Estas pruebas buscan ver el comportamiento de un sistema bajo diferentes volúmenes de datos en el mismo, por ejemplo, buscan popular la base de datos con mucha información para medir como se comporta el sistema.
  • Pruebas de escalabilidad: Estas pruebas buscan ver como el sistema escala al tener que trabajar con mas carga, por ejemplo, en un sistema que utilice AWS busca medir como se crean nuevos contenedores al aumentar la carga.

Cuales son los problemas de performance mas comunes de un sistema

En base a estos tipos de pruebas podemos identificar los problemas mas comunes tanto en el backend como en el frontend a la hora de poner un sitio bajo determinadas cargas, que no son fáciles de detectar en un ambiente de desarrollo, por ejemplo para un backend tenemos:

Problemas típicos de performance en backend

  • Aumento en el consumo de memoria que puede indicar una fuga que vaya a romper el ambiente.
  • SWAPs de memoria
  • Picos excesivos de consumo de CPU
  • Aumento de trafico en la red
  • Aumento de uso de disco
  • Aumento de tiempo de respuesta de la base de datos

Todos los puntos mencionados pueden generar un cuello de botella que haga que el sistema se vuelva demasiado lento o incluso que se caiga.

Como podemos ver, todos los puntos de arriba son muy importantes, pero no contemplan el frontend, lo que el usuario ve y que se ejecuta en su propio navegador, es decir, podemos tener un sistema que performe muy bien con cualquier tipo de carga pero que a su vez sea lento o no responda en el navegador por código de frontend, que se ejecuta sin importar la carga del sistema, como por ejemplo:

Problemas típicos de performance en frontend

  • Tiempo de carga total del sistema
  • Tiempo para que el sistema sea interactuable
  • Tiempo para que se muestre el contenido
  • Tamaño total de transferencia de datos
  • Tiempo de procesamiento de javascript
  • Códigos de respuesta del sistema

Estos últimos no suelen ser detectados en las pruebas de carga convencionales, ya que normalmente tendemos a medir solamente en el backend, pero otros factores que no se pueden probar en el backend afectan el tiempo de carga del frontend, por ejemplo:

  • Cantidad de javascript a ejecutar
  • Complejidad del javascript a ejecutar
  • Cantidad de requests totales
  • Código que bloquee la ejecución
  • Tamaño y cantidad de imágenes
  • Las capacidades del sistema de los usuarios

Lectura recomendada: Validar llamadas a APIs desde un test automatizado

El blog de Santi

La importancia de la velocidad y el impacto en las ventas y visitas

Todos estos tiempo pueden ser la diferencia entre realizar una venta, ganar un cliente o perderlo por completo, por ejemplo se estima que si un dato esperado demora mas de 2 o 3 segundos en serle brindado al usuario el sistema ya se califica como lento desde el punto de vista de estos Y nos hace perder aproximadamente el 50% de las visitas. Además de ese porcentaje de visitas que obtenemos resulta que el ratio de conversión cambia notoriamente de acuerdo a los tiempos de respuesta estudiados por cloudfare:

  • Sitios que cargan en 2.4 segundos tienen un ratio de conversión de 1.9%
  • Sitios que cargan en 3.3 segundos tienen un ratio de conversión de 1.5%
  • Sitios que cargan en 4.2 segundos tienen un ratio de conversión menor a 1%
  • Sitios que cargan en 5.7 segundos tienen un ratio de conversión de 0.6%

Herramientas para testing de performance frontend

Para poder hacer estas mediciones contamos con muchas herramientas de acceso libre que podemos utilizar, muchas de ellas online por lo que nos facilitan el trabajo cuando queremos tener un resultado rápido, y otras más configurable que nos permiten tener las pruebas integradas en un sistema de integración continua. Las herramientas que mas utilizo son:

Con todas estar herramientas podemos medir los valores que mencione mas arriba y podemos ver el impacto de cualquier cambio que hagamos en el sitio y determinar si este devuelve un delta negativo o positivo en los tiempos de carga.

En otro post me gustaría comentar como logre que este sitio pasara de cargar completo en 9 segundos a tan solo 3, con un tiempo de apenas 1.6s en ser interactivo para el usuario según Lighthouse, y como eso ayudo a posicionar mejor en Google y a obtener mas visitas en comparación en la versión anterior.

Lectura recomendada: Como automatizar pruebas de software

El blog de Santi