Uno de los aspectos que siempre me han gustado más sobre el desarrollo de software ha sido optimizar y mejorar el rendimiento, sobre todo de aquellas partes de un proyecto que pertenecen más al core y de las que depende todo lo demás.
Con el desarrollo masivo de aplicaciones web y teniendo en cuenta que la economía se está moviendo a lo digital, trabajar en el buen rendimiento de un sistema puede suponer una gran ventaja competitiva y generar mejores resultados económicos.
Por alguna razón, siempre he visto cómo todo lo relacionado con el rendimiento sólo nos ha preocupado como desarrolladores cuando suponía un error en el sistema, de modo que si algo funcionaba (aun con una latencia de algunos segundillos), a casi nadie le importaba. Ahora no: ahora hay que arañar hasta el último milisegundo y, por supuesto, ganamos la batalla si la percepción del usuario final es la de que algo va a golpe de clic. También he visto cómo se ha intentado solucionar problemas graves de rendimiento con más hardware…
El rendimiento de un sistema no consiste sólo en que funcione con la velocidad adecuada, sino también en que el usuario que lo usa perciba que responde ágilmente y de manera instantánea.
Lo que defiendo en este post, sobre todo en desarrollo web, es que trabajar con el rendimiento en mente se debe hacer desde el principio hasta el final del proyecto.
No hace mucho leí que un usuario percibe algo como instantáneo si obtiene una respuesta en menos de 100 ms; entre 100 y 300 ms percibe un ligero retraso; entre los 300 ms y el segundo ya nota un retraso apreciable; después de un segundo se produce lo que se llama un cambio mental de contexto (mental context switch, o sea, que empieza a pensar en otra cosa), y a partir de los diez segundos (!!#***xxxx) ha abandonado lo que intentaba hacer… En estos dos últimos casos, las posibilidades de que abandone la web son muy altas. Una web lenta echa a los visitantes como moscas en una fábrica de insecticida.
Esto tiene un impacto brutal en webs en donde una tasa de rebote alta significa menos usuarios y, por tanto, menos posibilidades de materializar algún tipo de resultado en el sitio (en forma de nuevas inscripciones, ventas, descargas, etc.). Por tanto, trabajar para mejorar el rendimiento no es algo secundario, sino que sin él todo lo demás que hagamos seguramente no tenga tan buen resultado como esperábamos.
Tradicionalmente, los equipos de desarrollo se han preocupado del rendimiento de lo que hacen al final del proyecto, cuando ya se da casi por cerrado y cuando posiblemente apenas se tenga tiempo para mejorarlo, pues todo el esfuerzo pendiente se debe dedicar a detectar y corregir errores de validación. Esto es un error en el que yo he caído mil y una veces… No obstante, como se suele decir, nada mejor que señalar los errores ajenos cuando uno mismo ya los ha cometido previamente, de modo que más que considerarme presuntuosamente experto, tendría que decir que la experiencia me ha dado muchas (y dolorosas) lecciones.
Desde el primer momento en que se comienzan a generar assets en el proyecto, del tipo que sea, hay que empezar a trabajar desde el punto de vista de su rendimiento. En otras palabras, tenemos que integrar en el día a día la mejora de esos assets como una parte más del trabajo, sobre todo si el éxito o fracaso del proyecto dependen de la buena o mala percepción de los usuarios en cuanto a usabilidad y tiempos de respuesta del sistema. Me pregunto: ¿pero es que existe algún sistema de software que se pueda permitir que un usuario esté varios segundos esperando para hacer cualquier cosa trivial? Claro, los hay, y muchos, me temo, y seguramente esos productos estén en la línea roja con posibilidad de ser sustituidos por la competencia.
El trabajar desde el principio en mejorar el rendimiento no es inocuo, ya que de alguna manera, escribir con la optimización en mente implica:
- Crear estructuras de código optimizadas en donde ahorrar tan sólo unos cuantos ciclos de CPU es importante. A veces es difícil encontrar el equilibrio para seguir manteniendo código legible sin ofuscarlo al optimizarlo.
- Trabajar con el rendimiento en mente también impacta en el diseño del sistema: no sirve de nada plantear una arquitectura de la información fantástica si detrás no está respaldada con saltos ágiles y rápidos cuando un usuario navega por una web.
Mejorar el rendimiento implica a todos los que trabajan en el proyecto: desarrolladores, diseñadores, arquitectos de información, etc.
El rendimiento no es sólo que un trozo de código funcione lo más rápido posible; es un concepto poliédrico, con muchas caras, sobre todo en una aplicación web donde hay muchísimos elementos involucrados:
- Conseguir un buen rendimiento depende de la infraestructura de software que usemos (servidores HTTP intermedios, SSL, etc.).
- Hay que establecer una buena estrategia de caché para los distintos elementos de la web.
- Hay que analizar si es conveniente o no usar CDN.
- Hay que validar y optimizar (minificando y concatenando) los ficheros CSS y JavaScript. Sí, los estilos se pueden optimizar para que el navegador tarde menos en procesarlos y renderizar los resultados.
- Si se hace un uso intensivo de imágenes, éstas deberían estar optimizadas y habría que ver en qué casos se podría emplear la técnica de uso de sprites.
- Si planteamos una web con estrategias de RWD o RESS, se complican un poco más las optimizaciones según el dispositivo del usuario.
- Hay que tener mucho cuidado con las librerías externas o de terceros que usemos y detectar cuáles de ellas pueden constituir un SPOF y dejar KO el sitio.
- Lo que entendamos por buen o mal rendimiento depende del tipo de proyecto.
No podemos dejar todo ese trabajo de auditoría y análisis del rendimiento (de calidad, en definitiva) para el final, sino que hay que integrar esas tareas en el flujo de trabajo habitual o en los procesos de entregas o integración continuas, si se tienen establecidos.
Lo más importante de todo (y quizá lo más difícil): el trabajo sobre el rendimiento de algún aspecto concreto se debe poder medir de manera automática para poder ver el progreso o retroceso a medida que avanza el proyecto.
Estamos comenzando un nuevo proyecto para el mercado eléctrico, en esta ocasión 100 % web (con un backend que extrae información de un enorme repositorio de información alojada en la nube); estamos integrando en el primer prototipo todas las métricas de rendimiento que nos permitan analizarlas a medida que el proyecto avance en los próximos meses, además de integrar en el flujo de trabajo habitual la generación automática de todos los assets optimizados. Espero que así este trabajo, que al principio parece extra, consiga que los usuarios finales del sitio perciban un sistema ágil y, por tanto, que consigamos generar una percepción positiva del mismo.
Me gusta Etsy, no sólo porque implementa en la realidad una economía colaborativa hacia la que, en mi opinión, todo debería converger, sino también porque cuenta con un equipo de desarrollo supermotivado que además publica sus insights. En su blog hablan mucho de rendimiento web.