Bueno el día de hoy marca un hito en mi carrera profesional como frontend ya que he decidido dar un paso adelante y especializarme en web performance.
Como parte de eso voy a estar compartiendo una serie de posts que ignoro cuantos sean, solo se que será al menos 1 a la semana con mis aprendizajes en este camino ninja.
Como frontends tenemos que saber muchas cosas acerca de performance:
- Loading performance
- Diferencias entre protocolos HTTP1 y HTTP2
- Prioridad de descarga de los recurso
- Prefetch, Preload y Preconnect
- Rendering performance
- Recursos render blocking
- Recursos parsing blocking
- Critical rendering path
- El costo de JS y el procesamiento de ciertos assets
- Core Web Vitals
- Real User Monitoring
Probablemente manejes muchos de estos temas y aunque sepas esto, si el performance no es un punto clave del producto en tu organización, no podrás aplicar ese conocimiento para generar un impacto significativo. Para que esto pase debe existir la cultura del performance.
Cultura del performance
Una de las cosa mas geniales de trabajar en un producto es el enfoque, todos miran en la misma dirección y es mucho más fácil cumplir metas cuando toda la organización esta alineada.
El tema de performance normalmente es visto como una actividad asociada al equipo de ingeniería/desarrollo. Si bien la implementación de estrategias recae en ese equipo, se debería involucrar a todos los actores que marcan el rumbo del producto como: Enginer Managers, Designers, Project Managers, etc.
Tomar al performance como una pieza clave para cumplir la metas del negocio. Esta es la cultura del performance.
En un equipo la cultura es importante ya que nuestras acciones son guiadas por la antes esta. Como en los sistemas de diseño, la mayor parte no recae en la implementación, sino en la comunicación, adopción y contribución.
¿Cómo comunico que esto es importante?
¿Cómo alinear al equipo?
¿Cómo los miembros del equipo pueden contribuir?
Responder estas preguntas parece simple pero en la práctica te encontrarás con problemas de varias indoles como:
- Excepticismo (no creemos que eso ayude)
- Silos (equipos aislados y no colaboran)
- Falta de apoyo o de "ownership" de tareas asociadas al performance (hay cosas más importantes)
Generar una cultura es complicado, costoso (es una inversión) y mas que nada una tarea de nunca acabar porque aunque tengas ciertas métricas para medir performance, estas pueden ir cambiando de acuerdo a las necesidades del negocio (imagina que tu app es desktop pero te piden dar soporte a resoluciones mobile).
¿Cómo comunico que esto es importante?
DINERO, si, DINERO.
El performance esta relacionado con la UX, la UX tiene relación con: convertion, retention, revenue, etc. Esto lo pueden entender personas de marketing, management y development.
Una comunicación es más efectiva cuando se lleva a cabo en términos que todos entendamos. Creo que todos entendemos que sin dinero una empresa no puede operar y entre más genere puede invertir más en su visión y su misión.
También podemos dar justificaciones mas técnicas de acuerdo a ciertos tipos de perfiles o departamentos. Esto al alcance de una busqueda en Google o en WPO Stats.
Ejemplo:
Nuestro sitio web gastoinnecesario.com tarda 5 segundos en cargar
Esto no me dice mucho, pero si presentas un caso de estudio como AutoAnything reduced page load time by 50% and saw an 12-13% increase in sales o un artículo de la importancia de la velocidad.
Es más fácil de comunicar los beneficios de incluir el performance como parte del producto.
¿Cómo alinear al equipo?
Una vez que entendemos los beneficios nos toca pensar como estamos alineados.
Eso lo logramos a traves de los performance budgets.
Los performance budgets son acuerdos, es un presupuesto que los involucrados en el producto deben respetar. Es algo que hace más fácil entender y tomar en cuenta el impacto de las decisiones que se toman ya que hay un límite definido.
"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good" - Tim Kadlec
No todos los performance budgets son exclusivos de ingeniería, a nivel implementación nosotros podemos representarlos en cierto formato pero al final los budgets son presupuestos entendibles para todos expresados en texto comprensible. Ejemplo:
Nuestra página principal debe cargar en 2.5 segundos o menos, en dispositivos móviles de gama media con una conexión 3G normal
Esto hace que cada perfil piense que puede hacer para respetar ese presupuesto.
Este budget me dice que bajo ciertas condiciones el tamaño de los assets que ocupa la página no puede ser mayor de lo que se puede transmitir en ese periodo de tiempo.
No voy a ahondar mucho en esto, porque ya tengo en mente otro posts donde abordaré esto de manera mas profunda (probablemente sea otra serie). Pero si quieres entrarle al chisme te recomiendo este artículo de Addy Osmani
¿Cómo los miembros del equipo pueden contribuir?
Honestamente no importa que tanto tiempo dediques a esto no es suficiente, debes tener: advocates, embajadores, champions, colaboradores, etc.
Por eso es importante que el primer punto quede muy claro, eso hará que todos nos alineemos y se designe tiempo para dedicarlo a performance.
También hay que generar documentación sobre donde encontrar los performance budgets, las herramientas que se van a utilizar, en que partes del proceso se harán auditorias de estos budgets y en que casos se pueden hacer excepciones.
Como toda iniciativa hay que reducir la fricción, honestamente creo que nadie estaría de acuerdo con tener una aplicación con bajo performance, pero a veces hay ciertas features que pueden ser críticas y probablemente sean más importantes que tener un desempeño optimo. Si dejamos claro cuando podemos modificar el budget o hacer excepciones es más simple que las personas se sumen.
En otros posts veremos como definir performance budgets y los tipos de métricas, espero les haya gustado y puedan compartir.
Top comments (0)