Cómo partir con Performance en Web

Fernando Larrañaga
Oct 24 · 13 min read

Performance en nuestras aplicaciones y sitios Web es un tema que en general sabemos que deberíamos prestarle atención (y trabajar) de manera constante, pero por distintas razones, tendemos a dejarlo en segundo plano. Y la verdad es que en muchos casos termina siendo un tema tan agobiante que cuando tenemos que pensar en ello, es difícil saber por donde siquiera empezar.

Y si bien hoy en día contamos con muchas herramientas y servicios que nos ayudan a auditar y probar las apps que construimos, entender exactamente lo que pasa presenta un mayor grado de dificultad, y si a eso le sumamos la cantidad limitada de tiempo para trabajar en proyectos, es común dejar esto de lado y priorizar temas de mayor visibilidad, como lanzar un nuevo feature, o arreglar un bug.

En este artículo, cubriremos algunos conceptos sobre porque deberíamos preocuparnos de temas de performance, como partir y como incorporar esto a nuestras tareas diarias.

¿Por qué preocuparme de la performance de mis apps?

Aunque en muchos casos no se nota a primera vista, la performance de nuestras apps o sitios Web puede tener efectos importantes (y por lo general negativos) en nuestros usuarios. En muchos casos, una mala experiencia en términos de carga, rendimiento o interacciones, puede terminar alejándolos y que terminen optando por otro sitio. Esto puede ser aún más grave si la app que estamos construyendo pertenece a algún tipo de negocio, ya que cada usuario que se vaya por algo así implica una interacción perdida y potencialmente perder una venta hacia un competidor que es capaz de ofrecerles una mejor experiencia.

Actualmente es posible encontrar bastantes estadísticas, que han sido compartidas por grandes compañías, en las cuales se demuestra como demoras de incluso 1 segundo o menos al cargar el contenido de sus sitios puede impactar las ventas y alejar a potenciales clientes. Y esto da para pensar que si marcas tan reconocidas se ven afectadas de esta manera, ¿qué podemos esperar para nuestro caso?

Las malas noticias primero: No existe una solución mágica

Como todo lo bueno en la vida, tener una app de buen rendimiento no es fácil e implica bastante trabajo. Entender eso desde un comienzo es importante, ya que lamentablemente hasta el día de hoy no existe una librería o paquete milagroso que podamos correr y solucione los problemas de nuestras apps (por ahora, pero quizás en algún futuro, cuando lleguen los 🤖🤖🤖), y el trabajo relacionado a performance requiere de bastante tiempo, dedicación y bueno… trabajo.

La buena noticia es que esto no significa que es imposible, sino todo lo contrario, ya que el proceso de resolver problemas de performance y mejorar nuestras apps, por lo general cuenta siempre con los mismos pasos:

  • Recolectar datos.
  • Experimentar con algún cambio en nuestra app.
  • Recolectar nuevos datos después de aplicar el experimento.
  • Comparar los datos.
  • Sacar conclusiones (mantener lo que funcionó, deshacer los cambios que no funcionaron).

Si bien algunas de estas partes pueden tener diferencias dependiendo del tipo de proyecto en el que estamos trabajando, este proceso en general es el mismo, pero es importante tener en mente un par de cosas que aplican para todos los casos:

  • Lo que funciona en una app, puede no ser la solución correcta para la tuya: Ojo, esto no significa que hay que ignorar buenas prácticas y consejos generales, ya que por lo general es bastante útil ya sea para aplicarlo directamente, o para poder obtener otras conclusiones a partir de eso. Sin embargo, hay que entender que puede no ser la prioridad correcta para tu caso de uso. (más sobre esto en la próxima sección).
  • En la mayoría de los casos, la clave para obtener buenos resultados con performance es priorizar y compensar.

Nadie: …

Nosotros: Deberíamos rearmar la app desde cero.

Uno de los grandes males que tenemos como devs es que muchas veces la primera reacción cuando nos enfrentamos a un proyecto con una gran cantidad de problemas, es pensar en reescribirla y rearmarla de nuevo. Y si bien puede parecer un escenario ideal, la verdad es que la gran mayoría de las veces esto no es posible, debido a restricciones de tiempo, presupuesto o cualquier otra prioridad que pueda existir.

Por esto, es mejor pensar en cómo mejorar el código actual sobre el que vamos a trabajar en vez de desecharlo y armar uno nuevo. Adicionalmente, con esto vamos a tener una base contra la cual podremos ir comparando las mejoras y nos entregará una visualización mucho más clara, en términos de datos, sobre los efectos de todos y cada uno de los cambios que vayamos haciendo.

Y como bonus, si algún día llegamos a tener la opción de rearmar la app desde cero, ya vamos a tener algunas ideas de cómo hacerlo mejor desde el principio.

Y bien, con todo esto entonces, ¿cómo partimos mejorando la performance de nuestras apps?: con un plan.

Armando un plan de performance

Empezar a hacer cambios de una vez sin saber que queremos lograr probablemente va a terminar causando más problemas de los que solucione. Por esto, es importante entender cuál debería ser el enfoque del trabajo que vamos a ejecutar e identificar cual es el propósito de nuestras apps, ya que con esto podremos armar un plan efectivo y relevante con respecto a ello.

Pero, ¿a qué nos referimos con propósito?

Identificando el objetivo principal de nuestras apps

Al momento de construir una app, o un sitio Web, probablemente una de las primeras cosas que deberíamos preguntarnos es: ¿Cuál es el propósito principal de este proyecto?. En la mayoría de los casos, identificar este propósito puede ser sencillo: quizás queremos vender algo, o mostrar algún tipo de contenido o proveer un servicio, etc. Y si bien identificar este propósito puede ser sencillo, puede que entender cuál es el enfoque que debería tener nuestra app para lograr esto no lo sea.

El enfoque tiende a ser diferente dependiendo del propósito, especialmente si caen en distintas categorías, y tienen directa relación hacia dónde deberíamos enfocar nuestro trabajo y nuestros esfuerzos en términos de performance.

Por ejemplo, digamos que queremos construir un sitio Web para vender galletas. El propósito principal debería ser claro: vender todas esas maravillosas 🍪🍪🍪. Durante la planificación de este proyecto, probablemente pensemos en incluir las siguientes secciones al sitio:

  • Una cabecera con un logo, un menú y unas animaciones.
  • Un listado con todas las galletas disponibles para la venta.
  • Una barra lateral con la información de contacto, links a redes sociales, un formulario para inscribirse a nuestro newsletter para promociones y algo de publicidad.
  • Un pie de página con toda la información legal.

Si volvemos a lo mencionado más arriba sobre el propósito principal (vender galletas), y pensamos en la importancia de cada sección y como se relaciona a este propósito, podemos asumir que a nuestros usuarios realmente no le importan algunas de las secciones de más arriba y que están visitando el sitio principalmente para comprar galletas (que coincidentemente es lo que queremos que hagan).

Con eso en mente, tiene lógica asumir que deberíamos enfocar los esfuerzos en mostrar el listado de galletas primero y lo más rápido posible en vez de gastar recursos y tiempo mostrando el menú, las animaciones (por muy cool que sean) o la barra lateral con los links de social media, y por eso nuestro plan debería reflejar esas prioridades.

Trabajar hacia mejoras graduales (iteraciones de 5%–10%)

Algo importante a tener en cuenta al momento de hablar de performance es que es un trabajo constante y probablemente no vamos a poder arreglar todos los problemas de una vez. Una gran parte del proceso es hacer mediciones y experimentar con cambios, así que es probable que estaremos yendo y viniendo probando cambios, analizando resultados y tomando decisiones en base a eso. De la misma forma, hay una gran probabilidad de que muchos de los cambios que hagamos no tengan efectos significativos en términos de porcentajes. No obstante, eso no significa que no sean victorias, sino todo lo contrario, cada mejora que hagamos va a tener un impacto importante en los usuarios y va a mejorar su experiencia y casos de uso.

Veámoslo de esta manera: Si tenemos una app que construimos con JavaScript, y el código completo está en un archivo de 500kb, cada usuario que visita esta app va a descargar 500kb de código que necesita ser analizado, interpretado y compilado por su navegador. Ahora, digamos que encontramos una forma de hacer algunas mejoras en el código y logramos bajar el peso de ese archivo en un 10%. Si bien 10 no pareciera ser tanto, terminan siendo 50kb menos que estamos mandando (y que serán analizados, interpretados — una de las partes más “costosas” del proceso — y compilados), así que no solo lograremos que la app “cargue más rápido”, pero además le estaremos haciendo un tremendo favor a nuestros usuarios haciendo que descarguen mucho menos código (algo que aquellos usando plan de datos en sus dispositivos móviles agradecerán).

Teniendo eso en cuenta, un buen principio a apuntar para nuestro plan es lograr mejoras graduales de entre un 5% a un 10% en cada ciclo de trabajo. Genial si logramos obtener más, pero cualquier resultado entre esos valores debería estar bien y va a ser más realista, especialmente considerando que si bien a un inicio los cambios serán más perceptibles, a medida que vayamos progresando va a ser más difícil encontrar lugares para potenciales mejoras.

Después de cada uno de estos ciclos de mejoras, lo ideal es medir nuevamente, obtener nuevos datos a partir de esto y armar una nueva iteración para experimentar con cambios.

Obteniendo los datos

El último paso antes de empezar a trabajar es obtener los datos de la performance actual de nuestra app, para así poder identificar los puntos con problemas y priorizar el trabajo que haremos.

¿Por qué medir?

Cada vez que pienso en porque deberíamos medir, me gusta volver a estos 3 principios:

  • Algunas veces las cosas parecen rápidas, pero no lo son.
  • Algunas veces las cosas se ven bien, pero podrían verse mejor.
  • Algunas veces las cosas parecen lentas, pero no es su culpa.

Los navegadores hoy en día son bastante rápidos, y son capaces de hacer muchas cosas sin que podamos darnos cuenta. Sin embargo, eso no significa que las cosas sean, en efecto, rápidas. Hay un gran número de procesos y tareas que pasan por debajo sin que nos demos cuenta y que no podremos apreciar realmente hasta que nos tomemos el tiempo de mirar en detalle como se están cargando cada una de las partes de nuestra app, cuanto tiempo se gasta en ellas y si hay alguna que esté causando problemas.

Usando herramientas para medir cada parte de la app, es posible obtener una visión más clara de lo que está pasando, y de esa manera será más fácil identificar problemas y planificar el trabajo que vamos a hacer.

¿Cómo medir?

Hay bastantes herramientas y servicios actualmente que nos permiten realizar mediciones sobre nuestras apps y obtener una idea de cómo andan en términos de rendimiento. Muchas de ellas incluso, ofrecen consejos para mejorar los problemas que encuentran, lo cual termina siendo sumamente útil, especialmente si estamos empezando y no sabemos cómo atacar los problemas de manera efectiva, o que priorizar.

De las muchas, y muchas, y muchas alternativas hoy disponibles, algunas de las que personalmente me gusta usar y recomendar son:

Lighthouse (Web, CLI, CI)

Google Lighthouse es probablemente la mejor herramienta para analizar la performance de una app. Al ejecutar un análisis, se encarga de revisar distintos escenarios de carga (dispositivos móviles, de escritorio, conexiones, resoluciones, etc.), como manejamos y cargamos recursos, accesibilidad, SEO e incluso da consejos de mejora para cada problema encontrado.

Una de las grandes ventajas de Lighthouse es que podemos usarla de distintas maneras:

Google Lighthouse en el sitio de web.dev
Google Lighthouse en Chrome Dev Tools

PageSpeed Insights

Hasta hace un tiempo, si medías un sitio en PageSpeed Insights y luego en Lighthouse, era probable que los resultados fueran un poco diferentes en términos de puntaje, e incluso en problemas encontrados y consejos, por lo que era útil estar revisando ambos al momento de medir y obtener datos. Actualmente los resultados son casi iguales, por lo que en la mayoría de los casos usando Lighthouse deberíamos tener cubiertos todos los casos, pero nunca está demás tener este caso considerado para ciertas situaciones.

PageSpeed Insights

Pingdom Website Speed Test

Usar una herramienta externa (que no es de Google) como Pingdom también es útil para obtener datos extras y comparar entre distintas fuentes. Una de las ventajas de usar Pingdom es que permite probar como cargan nuestros sitios desde diferentes ubicaciones geográficas, así que si estamos apuntando a una audiencia global, con esto podremos tener una mejor idea de como están recibiendo y cargando el contenido que proveemos.

Pingdom Website Speed Test

Chrome Dev Tools

Y finalmente, una de las herramientas más útiles sin duda que es la pestaña de Performance en Chrome Dev Tools, la cual además será una de nuestras aliadas más importantes cuando estamos desarrollando en local.

Con esta pestaña, podemos grabar todo lo que pasa cada vez que una de las páginas de nuestros sitios o apps carga, incluyendo cuánto código está siendo incluido, analizado, interpretado y compilado, en que orden se están cargando e incluyendo los recursos, como anda el trabajo de CPU durante la carga y cuanto demora cada una de las partes desde que un usuario ingresa la URL hasta que el sitio ha cargado completamente y está listo para recibir interacciones. Este tipo de visualizaciones son esenciales para poder detectar posibles cuellos de botella y problemas que a primera vista son difíciles de notar.

Pestaña de performance en Chrome Dev Tools

Priorizando problemas y definiendo donde podemos crear más impacto

Recuerdan hace algunas secciones más arriba donde hablábamos de “identificar el propósito de nuestra app”? Ahora que sabemos cómo medir, podemos intentar encontrar una relación entre los problemas encontrados y cuales afectan directamente ese propósito. Con esto, armar una lista de prioridades y definir en lo que vamos a trabajar, y en que orden, nos permitirá definir donde está el impacto más grande que podremos crear con nuevos cambios, y que modificaciones van a beneficiar de mejora manera a los usuarios.

Algunos tips adicionales

Incluyendo el trabajo de performance en nuestra planificación regular (la regla del 20%)

Tal como pasa con los tests durante el desarrollo de software, es necesario cambiar la forma en la que pensamos en performance y comenzar a incluirla como parte del proceso en vez de un adicional (¡igual que los tests!). La mejor forma de hacer esto es comenzar a considerarlo como parte de la cultura de nuestros equipos y encontrar la forma de incluir tareas de manera constante en la planificación semanal del trabajo.

Una forma de lograr esto es que, al inicio de cada sprint, destinemos un 10% a un 20% del tiempo para trabajar en problemas y optimizaciones de performance. Si logramos transformar esto en un esfuerzo continuo, y que todo el equipo se preocupe e involucre en este trabajo, no solo se va a transformar en una prioridad para todos, pero eventualmente el número de problemas en los que hay que trabajar será cada vez menor y los esfuerzos que habrá que destinar no serán tan significativos como al inicio.

Una de las cosas positivas acerca de las mejoras de performance es que normalmente están asociadas a mejoras para el negocio (como las estadísticas que revisábamos al inicio), por lo que justificar dedicar tiempo a este tipo de problemas no es tan difícil como con otras tareas técnicas (como refactorizar código, mejorar o implementar herramientas, etc.)

Teniendo cuidado con la optimización prematura

Optimizar prematuramente es uno de los grandes riesgos al momento de pensar en performance. Es común pensar demasiado hacia el futuro con respecto al desarrollo de algunas partes de nuestra app y tratar de manejar todos los posibles casos de uso, incluso algunos que quizás nunca lleguen. Es por esto que si bien es recomendable tener en cuenta posibles situaciones que eventualmente podrían traer problemas, no es necesario sobre preocuparse, y siempre recordar que ante todo, lo importante es poder medir, obtener datos y trabajar desde ahí.

Probar todos los escenarios

Uno de los grandes errores que solemos cometer como desarrolladores es que probamos nuestras apps bajo las mejores condiciones: localmente, en nuestro computador, con una conexión a Internet rápida y estable. Y si bien todo funciona de maravillas ahí, es importante preguntarse si esa es la realidad de nuestros usuarios. La verdad es que solo al empezar a aplicar algunas restricciones a las condiciones en que ejecutamos nuestras apps, es donde empezamos a ver potenciales fallas 😔.

Afortunadamente, hoy contamos con herramientas que nos permiten emular distintos escenarios (como distintos tipos de CPU, resoluciones y/o conexiones de Internet) en la comodidad de nuestro ambiente normal de trabajo, usando la pestaña de Performance en Chrome Dev Tools:

Emulando distintas velocidades de CPU

Ajustando la velocidad de CPU en la pestaña de Performance de Chrome Dev Tools

Emulando distintas velocidades de conexión a Internet

Ajustando la velocidad de conexión a Internet en la pestaña de Performance de Chrome Dev Tools

Es buena idea jugar un poco con las distintas opciones y recargar la app. Esto nos permite ver cómo se comporta todo bajo estas nuevas condiciones.

Nota: Esas condiciones emuladas se mantienen siempre y cuando mantengamos Chrome Dev Tools abierto. Apenas lo cerremos, todo volverá a la normalidad.

Obtener datos sobre nuestros usuarios para ver que priorizar

Si podemos tener una idea de que lugares vienen nuestros usuarios, que tipos de dispositivos y/o conexiones usan, Sistemas Operativos y que tipo de uso le están dando a nuestra app (podemos usar alguna herramienta como Google Analytics para obtener casi toda esa información), va a ser mucho más fácil para nosotros visualizar los escenarios reales bajo los cuales deberíamos probar el rendimiento de nuestras apps y donde deberíamos enfocar nuestras prioridades al momento de trabajar.

Por ejemplo, si recolectamos datos y nos damos cuenta que el 100% de nuestros usuarios usa la última versión de Google Chrome en Escritorio, y nadie está usando otros navegadores y/o dispositivos móviles, es seguro asumir que podemos priorizar problemas que afecten a ese segmento en particular y no enfocarse tanto (por ahora) en la versión móvil de la app o darle soporte a versiones más antiguas de otros navegadores. Por otro lado, si no tuviésemos esos datos, podríamos eventualmente gastar horas corrigiendo problemas que no van a tener ningún impacto real en nuestra base activa de usuarios.

Bueno, ¿y ahora?

Ahora que tenemos los datos, las ideas y sabemos cómo empezar a planificar, es momento de empezar a trabajar.

La gran pregunta es, ¿por dónde partimos?, bueno eso, para el próximo artículo ✌.

You can find an English version of this article published on my blog at xabadu.dev

Fernando Larrañaga

Written by

The stylin’, profilin’, UI buildin’, Web codin’, community leadin’, son of a gun! Developer Evangelist 🥑 at Twilio ☎️ — Organizer NodeSchool San Francisco.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade