escalabilidad

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 lo 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 perfomance sólo nos ha preocupado como desarrolladores cuando esto suponía un error en el sistema, de modo que si algo funcionaba (aun con una latencia de algunos segundillos) pues 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 100ms, entre 100 y 300ms percibe un ligero retraso, entre los 300ms 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 site (en forma de nuevas inscripciones, ventas, descargas, etc.). Por tanto, trabajar en mejorar el rendimiento no es que sea 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 hace al final del proyecto, cuando ya se da casi por cerrado y cuando posiblemente apenas se tenga ya tiempo parar mejorarlo y todo el esfuerzo pendiente se deba 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 comenzar a trabajar desde el punto de vista de su rendimiento; en otras palabras, tenemos que integrar en el día a día el mejorar 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 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. Es difícil a veces encontrar el equilibro para seguir manteniendo código legible sin ofuscarlo al optimizarlo.
• Trabajar con el rendimiento en mente impacta también 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.

El mejorar el rendimiento implica a todos lo 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 performance depende de la infraestructura 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 CDNs.
• Hay que validar y optimizar (minificando y contatenando) los ficheros CSS y js. 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, estas deberían estar optimizadas y habría que ver en qué casos se podría emplear la técnica de uso de sprites.
• No hablemos ya si plateamos una web con estrategias de RWD o RESS, ahí se complica un poco más las optimizaciones según el dispositivo del usuario.
• Hay que tener mucho cuidado de las librerías externas o de terceros a usar y detectar cuales de ellas pueden constituir un SPOF y dejar K.O. el site.
• 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 de rendimiento (de calidad, en definitiva) para el final, sino que hay integrar esas tareas en el workflow habitual de trabajo o en los procesos de entregas o integración continuas si se tienen establecidas.

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 cloud); estamos integrando en el primer prototipo todas las métricas de rendimiento que nos permita 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 así que este trabajo, que al principio parece extra, consiga que los usuarios finales del site perciban un sistema ágil y por tanto 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, también porque cuenta con un equipo de desarrollo supermotivado que además publican sus insights. En su blog hablan mucho de rendimiento web.