Optimizar el rendimiento no es un proyecto puntual. El rendimiento es una práctica continua.
Un flujo de trabajo significa: el equipo revisa los datos de rendimiento cada semana. El equipo habla de rendimiento en las reuniones diarias. El equipo tiene en cuenta el rendimiento al escribir código. El equipo celebra las mejoras de rendimiento.
Sin flujo de trabajo: el rendimiento empeora con el tiempo. El equipo no piensa en el rendimiento hasta que la web se rompe.
Con flujo de trabajo: el rendimiento mejora con el tiempo. El equipo crea una cultura de rendimiento. El rendimiento se valora.
Rutina semanal de rendimiento
Cada lunes por la mañana: el equipo revisa el informe de rendimiento.
El informe muestra: qué mejoró la semana pasada, qué empeoró la semana pasada, qué necesita atención esta semana.
Conversación del equipo: por qué empeoró el LCP de la página de pago. Lo causa código nuevo. Hace falta investigar.
Resultado: se identifican tareas. Las mejoras de rendimiento entran en el sprint.
Ejemplo real de rutina semanal:
- Lunes a las 10: reunión de revisión de rendimiento
- Revisión de métricas: el LCP de la página de inicio mejoró cero coma dos segundos (bien), el INP de la página de producto empeoró cincuenta milisegundos (investigar)
- Análisis de la causa: la página de producto cargó una función nueva (motor de recomendaciones). La función añadió JavaScript y eso subió el INP.
- Tareas: aplazar el JavaScript del motor de recomendaciones, optimizar el código de la función
- Responsable: el ingeniero asignado a la corrección
- Fecha límite: despliegue del miércoles
Cómo integrar el rendimiento en el flujo de desarrollo
Antes de lanzar una función: el ingeniero mide el impacto en el rendimiento.
La función añade funcionalidad. También añade código. El código aumenta el tamaño del paquete. Un paquete más grande puede empeorar el rendimiento.
Marco de trabajo: el presupuesto de rendimiento. La función no debe superar el presupuesto.
Ejemplo: una función nueva en la página de pago. Presupuesto: no añadir más de veinte kilobytes al paquete de JavaScript. El ingeniero implementa la función. La función añade veinticinco kilobytes. La función supera el presupuesto. El ingeniero debe optimizar: quitar código sin usar, dividir el paquete, aplazar código. El ingeniero reduce la función a veinte kilobytes. La función se aprueba.
Ejemplo real: implementar un motor de recomendaciones de producto
Función: mostrar recomendaciones personalizadas de producto en la página de producto.
Presupuesto de rendimiento: no añadir más de cincuenta kilobytes al paquete.
Implementación inicial: cincuenta kilobytes. Justo en el presupuesto.
Pruebas: medir LCP e INP.
- El LCP sube de dos a dos coma tres segundos (inaceptable, supera el presupuesto)
- El INP sube de ciento cincuenta a trescientos milisegundos (inaceptable, supera el presupuesto)
Optimización del ingeniero: cargar de forma diferida las recomendaciones fuera de la primera pantalla y aplazar la carga de sus datos hasta que la página sea interactiva.
Nueva implementación: cincuenta kilobytes, el mismo tamaño, pero:
- El LCP vuelve a dos segundos (dentro del presupuesto)
- El INP vuelve a ciento setenta milisegundos (dentro del presupuesto)
Función aprobada: se cumplen los requisitos de rendimiento.
Informes a la dirección
Informe mensual a la dirección: tendencias de rendimiento e impacto en el negocio.
Estructura del informe:
- Objetivos de rendimiento y avance
- Comparativa con la competencia (cómo estamos frente a otros)
- Impacto en el negocio (ingresos generados por las mejoras de rendimiento)
- Próximo foco (qué optimizaremos después)
Ejemplo real de informe mensual al equipo directivo:
- Objetivo: lograr que el noventa por ciento de los usuarios tenga un LCP por debajo de dos coma cinco segundos
- Avance: ahora el ochenta y siete por ciento (frente al ochenta y cinco por ciento del mes pasado)
- Plazo: va según lo previsto para alcanzar el objetivo en dos meses
- Posición frente a la competencia: el LCP mediano de la competencia es de dos segundos, nuestro LCP es de dos segundos (en la mediana, competitivos)
- Impacto en el negocio: las mejoras de rendimiento del mes pasado aumentaron la finalización del pago un cero coma cinco por ciento. Con cien mil visitantes al mes, son quinientas conversiones más. Con un valor de pedido de cien dólares, son cincuenta mil dólares más de ingresos al mes. Seiscientos mil dólares al año.
- Próximo foco: optimización móvil (el LCP en móvil es un segundo más lento que en escritorio, una oportunidad para mejorar la conversión en móvil)
Contratar para una cultura de rendimiento
Contrata ingenieros a los que les importe el rendimiento. Pregunta de entrevista: cuéntame una optimización de rendimiento que hayas implementado.
Contrata responsables de producto que valoren el rendimiento. El rendimiento mejora la experiencia del usuario y la tasa de conversión. Los responsables de producto deben conocer el impacto en el negocio.
Crea una cultura de equipo donde se valore el rendimiento. Celebra los logros de rendimiento. Reconoce al ingeniero que mejoró el LCP en cero coma cinco segundos.
Ejemplo real: contratar para una cultura de rendimiento.
Pregunta de entrevista a un candidato: describe una ocasión en que optimizaste código para mejorar el rendimiento. Cuál era el problema. Cómo mediste la mejora. Cuál fue el impacto en el negocio.
Buena respuesta: teníamos un endpoint de API lento que tardaba dos segundos. Los usuarios se quejaban de que el registro era lento. Analicé el código y encontré una consulta costosa a la base de datos. Añadí caché. El tiempo de respuesta bajó a doscientos milisegundos. La finalización del registro subió un dos por ciento. Cincuenta clientes más al mes. Doscientos cincuenta mil dólares más de ingresos al año.
La respuesta muestra: comprensión técnica (análisis, caché), medición (antes y después), mentalidad de negocio (impacto en el registro y en los ingresos).
Contrata a este ingeniero. Piensa en el rendimiento y en el negocio.
Preguntas frecuentes
¿Cómo motivamos al equipo para que priorice el rendimiento?
Conecta el rendimiento con las métricas de negocio. Muestra que una mejora del uno por ciento en el rendimiento equivale a un aumento del uno por ciento en la conversión. Calcula el impacto en los ingresos. Muestra el coste de optimizar frente a los ingresos que se ganan. A los ingenieros les importa el impacto. El rendimiento tiene un impacto medible. Los ingenieros lo priorizarán. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿La optimización del rendimiento debe ser un equipo aparte o parte de todos los equipos?
Parte de todos los equipos. Cada ingeniero debe pensar en el rendimiento. Un equipo de rendimiento aparte es un cuello de botella. Es mejor repartir la responsabilidad. Cada ingeniero responde del rendimiento de su código. El responsable de ingeniería exige cuentas al equipo.
¿Cómo equilibramos las funciones nuevas con la optimización del rendimiento?
El rendimiento es una función más. Una función nueva más su impacto en el rendimiento es el coste total. Presupuesta ambas cosas. Ejemplo: una función nueva cuesta un sprint. También cuesta cero coma cinco sprints optimizarla para el rendimiento. El coste total es de uno coma cinco sprints. Asigna ambos. La función y el rendimiento se lanzan juntos.
¿Y si a la dirección no le importa el rendimiento?
Muestra el impacto en el negocio. Una mejora del uno por ciento en la conversión equivale a cincuenta mil dólares al mes (en una tienda online típica). La dirección entiende los ingresos. Mejorar el rendimiento es mejorar los ingresos. A la dirección le importará.
¿Cuánto tarda en crearse una cultura de rendimiento?
De tres a seis meses. Primer mes: establece las métricas y el panel. Segundo mes: empiezan las revisiones semanales y crece la conciencia del equipo. Tercer mes: el equipo empieza a tener en cuenta el rendimiento en el código. Seis meses: el rendimiento forma parte del ADN del equipo. Los nuevos ingenieros aprenden la cultura de rendimiento desde el primer día.
¿Cómo mantenemos la cultura de rendimiento a medida que crece la empresa?
Documenta las prácticas. Integra a los nuevos ingenieros en la cultura de rendimiento. Primer día: enséñales el panel de rendimiento. Primera semana: asígnales una tarea de mejora de rendimiento. Primer mes: fíjales un objetivo de rendimiento. Los nuevos ingenieros aprenden la cultura. La cultura se mantiene.