Gestionar el rendimiento de una sola web es abarcable. Gestionarlo en diez webs, cinco apps móviles y varios microservicios es complejo.
Un solo sitio: el panel muestra LCP, CLS, INP. El equipo se centra en una página cada vez.
Una empresa grande: el panel muestra cientos de páginas, varios productos, varias plataformas. El equipo necesita priorizar.
Escalar la analítica de rendimiento significa: elegir qué medir, elegir qué optimizar, repartir la responsabilidad entre los equipos.
Ejemplo: una empresa tiene cinco productos (plataforma web, app móvil, panel, herramienta de analítica, API). Cada producto tiene un perfil de rendimiento distinto. Cada producto lo mantiene un equipo distinto. Un equipo central de rendimiento no puede optimizarlo todo. Solución: fijar estándares de rendimiento, que cada equipo responda del rendimiento de su producto y que el equipo central vigile el rendimiento agregado.
Elegir qué medir a escala empresarial
Mide solo los recorridos críticos. Plataforma de tienda online: página de inicio, producto, pago (críticos). Blog, página Sobre nosotros (no críticos). Céntrate en los recorridos críticos.
Mide por línea de producto. Plataforma SaaS: página de registro, panel, página de ajustes. Cada equipo se encarga de sus páginas. Cada equipo sigue su rendimiento.
Mide por impacto en el negocio. Las páginas que generan ingresos importan más. Las páginas con poco tráfico importan menos. Céntrate en las páginas que generan ingresos.
Ejemplo real: una empresa con tres líneas de producto:
- Producto A (tienda online): inicio, producto, pago, búsqueda
- Producto B (SaaS): registro, panel, ajustes, integración
- Producto C (contenido): inicio del blog, artículo, comentarios, artículos relacionados
Prioridad de medición:
- Producto A (más tráfico, más ingresos): mide todas las páginas
- Producto B (mucho tráfico, muchos ingresos): mide las páginas críticas (registro, panel)
- Producto C (poco tráfico, pocos ingresos): mide solo la página de inicio
Repartir la responsabilidad del rendimiento
El equipo central fija los estándares. Cada equipo responde del rendimiento de su producto.
Estándares: todas las páginas deben tener un LCP por debajo de dos coma cinco segundos, un CLS por debajo de cero coma uno y un INP por debajo de doscientos milisegundos.
Modelo de responsabilidad:
- Equipo del producto A: responde del rendimiento de inicio, producto, pago, búsqueda
- Equipo del producto B: responde del rendimiento de registro, panel, ajustes
- Equipo del producto C: responde del rendimiento de la página de inicio del blog
- Equipo central de rendimiento: vigila el cumplimiento, avisa de los retrocesos, ofrece herramientas
Ejemplo real: una empresa SaaS con tres equipos de ingeniería.
Estándares (fijados por el equipo central de rendimiento):
- Objetivo de LCP: dos segundos (los objetivos de cada producto pueden variar, pero la base es de dos segundos)
- Objetivo de CLS: cero coma cero cinco
- Objetivo de INP: ciento cincuenta milisegundos
Responsabilidad de cada equipo de producto:
- Equipo de plataforma: el panel debe mantener un LCP por debajo de dos segundos
- Equipo de integraciones: la página de integraciones debe mantener un LCP por debajo de dos coma cinco segundos
- Equipo de analítica: la página de analítica debe mantener un LCP por debajo de dos segundos
Cada equipo mide sus propias páginas. El panel avisa si las páginas de un equipo superan los estándares. El equipo responde de los resultados.
Agregar el rendimiento de varios productos
El panel agregado muestra: todos los productos, todas las páginas, el cumplimiento de los estándares.
El panel muestra el porcentaje de productos que cumplen el estándar: el noventa por ciento de las páginas tiene un LCP por debajo de dos coma cinco segundos. Zona verde.
El panel muestra qué productos no cumplen: el producto B tiene un ochenta por ciento de cumplimiento (dos páginas superan el estándar). Zona amarilla.
Informe a la dirección: el rendimiento agregado es sólido (el noventa por ciento de las páginas cumple). Un producto necesita atención (producto B).
Acción: se avisa al equipo del producto B. El equipo investiga. El equipo optimiza las páginas que no cumplen.
Ejemplo real: rendimiento agregado de una empresa con tres productos.
Producto A (tienda online):
- Inicio: LCP 1.2s (cumple)
- Página de producto: LCP 1.8s (cumple)
- Pago: LCP 2.1s (cumple)
- Búsqueda: LCP 2.4s (cumple)
- Cumplimiento: 100 por ciento
Producto B (SaaS):
- Registro: LCP 1.9s (cumple)
- Panel: LCP 2.6s (no cumple)
- Ajustes: LCP 2.5s (no cumple)
- Cumplimiento: 66 por ciento
Producto C (contenido):
- Inicio del blog: LCP 2.3s (cumple)
- Cumplimiento: 100 por ciento
Agregado: 88 por ciento de cumplimiento entre todos los productos.
Informe a la dirección: dos de los tres productos cumplen del todo. El producto B necesita atención. El equipo trabaja para mejorar el rendimiento del panel y de los ajustes.
Estándares de rendimiento por tipo de dispositivo y zona geográfica
Los estándares pueden variar según el contexto. Los de escritorio son distintos de los de móvil. Los de EE. UU. son distintos de los internacionales.
Objetivo de LCP en escritorio: dos segundos (internet rápido, CPU rápida).
Objetivo de LCP en móvil: tres segundos (internet más lento, CPU más lenta).
Objetivo de LCP en EE. UU.: dos segundos (internet rápido en general).
Objetivo de LCP internacional: tres segundos (velocidades de internet variadas).
Ejemplo real: una empresa SaaS global con despliegue en varias regiones.
Estándar de LCP por zona geográfica:
- EE. UU.: 1.8 segundos (objetivo)
- UE: 2.2 segundos (objetivo, internet más lento que en EE. UU.)
- Asia-Pacífico: 2.5 segundos (objetivo, internet más variable)
Rendimiento por región (situación actual):
- EE. UU.: 1.5 segundos (bien, supera el objetivo)
- UE: 2.3 segundos (en el objetivo, hace falta una pequeña mejora)
- Asia-Pacífico: 3.0 segundos (por debajo del objetivo, necesita mejoras)
Acción: el equipo de Asia-Pacífico (o el equipo central de rendimiento si no hay equipo regional) optimiza el rendimiento en Asia-Pacífico. Foco: optimizar la CDN para las regiones de Asia-Pacífico y optimizar las imágenes para un ancho de banda menor.
Preguntas frecuentes
¿Cómo fijamos estándares de rendimiento distintos para productos distintos?
Según su importancia para el negocio y las expectativas de los usuarios. El producto que genera más ingresos: el objetivo más exigente. El que genera menos ingresos: un objetivo más relajado. Ejemplo: el pago en una tienda online es lo más crítico (genera ingresos). Objetivo: 1.5 segundos. El contenido del blog es menos crítico. Objetivo: 2.5 segundos. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿El equipo central de rendimiento debe optimizar todos los productos o solo fijar estándares?
Fijar estándares y vigilar. Deja que los equipos de producto se encarguen de optimizar. El equipo central ofrece herramientas, formación y escalado. Si un equipo de producto no logra cumplir el estándar, el equipo central ayuda. Pero la optimización del día a día es responsabilidad del equipo de producto.
¿Cómo resolvemos los conflictos entre el desarrollo de producto y los requisitos de rendimiento?
El rendimiento forma parte de los requisitos del producto. Una función nueva debe cumplir los estándares de rendimiento. Si la función añade código que empeora el rendimiento, no se aprueba hasta que se optimice. El rendimiento no se negocia (salvo que la dirección lo despriorice de forma explícita por una razón de negocio).
¿Debemos medir el rendimiento de las páginas con poco tráfico?
No. Céntrate en las páginas con mucho tráfico y mucho impacto. Las páginas con poco tráfico no merecen el esfuerzo de optimización. El tráfico multiplicado por el impacto en el negocio decide la prioridad. Mide donde el impacto es mayor.
¿Cómo tenemos en cuenta las diferencias de velocidad de red entre regiones?
Fija objetivos distintos por región. EE. UU. tiene redes rápidas. Fija un objetivo exigente (1.5 segundos). Las regiones internacionales tienen redes variadas. Fija objetivos realistas (de 2 a 3 segundos). Mide el rendimiento por región. Avisa si una región no llega a su objetivo (no al objetivo absoluto).
¿Debemos integrar presupuestos de rendimiento en el flujo de despliegue de todos los equipos?
Sí. Comprueba el presupuesto de rendimiento antes del despliegue. Si el código de un equipo supera el presupuesto, se bloquea el despliegue. Evita los retrocesos. También garantiza la responsabilidad (el equipo se ve obligado a optimizar antes de lanzar).