Ely Rendimiento

---
name: ely-frontend-performance
description: Mide y mejora rendimiento de frontends a partir de cuellos de botella observados en carga, imágenes, fuentes, red, layout y trabajo de renderizado. Úsala para investigar lentitud o regresiones y comparar cambios con evidencia; no inventa puntuaciones ni aplica dependencias por defecto.
---

# Ely Rendimiento

Mejora el coste que limita la experiencia real del flujo solicitado. Conserva sus funciones, dirección visual y arquitectura salvo que la evidencia justifique cambiar alguna de ellas.

## Establecer una comparación útil

Empieza por el síntoma: primera vista tarda, interacción responde tarde, scroll se entrecorta, navegación consume memoria o la página cambia de posición. Elige una ruta representativa, datos reales o claramente sintéticos y una condición reproducible. Usa el build de producción para conclusiones de rendimiento; el modo de desarrollo puede incluir costes ajenos al producto.

Recoge una línea base con las herramientas disponibles: waterfall de red, trace de rendimiento, tamaño de recursos, shifts de layout o perfil de memoria. Registra URL o commit, viewport, navegador, cache, dispositivo o emulación y configuración de throttling. No confundas tráfico total transferido con tamaño descomprimido, ni un test local con experiencia de usuarios reales.

Lee [references/measurement-plan.md](references/measurement-plan.md) para elegir medidas y comprobar causalidad. Define un presupuesto proporcional a la tarea a partir de su línea base y necesidad de producto; los objetivos son objetivos, no resultados medidos.

## Elegir el cambio según la evidencia

- **Carga crítica:** identifica el recurso o dependencia que retrasa el contenido principal. No apliques lazy loading a la imagen principal de la primera vista. Usa prioridades y preload de forma selectiva después de confirmar qué se descubre tarde; demasiadas prioridades compiten entre sí.
- **Imágenes y vídeo:** sirve dimensiones y formatos adecuados al uso, declara tamaño o ratio y proporciona variantes responsive. Conserva detalle donde importa visualmente; una reducción de bytes que arruina el producto no es una mejora suficiente. Posponer medios fuera de pantalla suele ser preferible a cargarlos todos al inicio.
- **Fuentes:** reduce familias, estilos o glifos solo cuando sean prescindibles para el contenido y sus idiomas. Define una estrategia de carga y fallback que mantenga lectura y geometría aceptables. Comprueba permisos antes de redistribuir archivos tipográficos.
- **JavaScript y red:** busca trabajo o dependencias costosas en la ruta medida. Elimina cargas innecesarias, divide por rutas o interacción cuando convenga y evita crear nuevos waterfalls. No sustituyas una librería solo por su reputación o tamaño publicado: confirma el coste que llega al bundle usado.
- **Interacción y render:** localiza tareas largas y trabajo repetido. Reduce o distribuye trabajo no urgente, mide antes de memoizar y separa lecturas de geometría de escrituras de estilos. Investiga recalculado, layout y paint en el trace; un FPS medio puede ocultar pausas notorias.
- **Animación:** limita actualizaciones a escenas activas y a propiedades adecuadas. No promotes toda la página a capas ni fuerces `will-change` permanente. Una máscara o blur costoso puede necesitar menor área, resolución o una alternativa móvil.
- **Navegación y memoria:** desmonta listeners, observers, requests cancelables e instancias. Si sospechas una fuga, repite un ciclo representativo y examina retenciones; una única lectura de memoria elevada no la demuestra.

Mantén contenido y controles funcionales con imágenes lentas, fuentes tardías y fallos de red relevantes al flujo. Evita cambiar comportamiento de caché de datos personalizados sin entender sus claves, caducidad y aislamiento. Un cambio de infraestructura o servicio externo requiere el alcance autorizado por el usuario.

## Confirmar la mejora y su coste

Repite la misma medición en condiciones comparables. Para resultados ruidosos, realiza suficientes muestras para distinguir variación de mejora y reporta su dispersión; no presentes una única ejecución favorable como conclusión. Comprueba además el recorrido funcional y el resultado visual que toca el cambio.

Entrega causa observada, cambio, medidas antes/después y límites del entorno. Separa datos de laboratorio, métricas de campo y estimaciones. Nunca inventes Lighthouse, Core Web Vitals, ahorro porcentual ni cobertura de dispositivos; si no puedes medir, presenta la hipótesis y el cambio verificable sin afirmar una ganancia cuantificada.