Rendimiento de microfrontends: los costos y cómo controlarlos
Dividir un frontend en partes que se despliegan por separado agrega peticiones, bytes y trabajo de arranque. Nada de eso es fatal. Hay que medirlo y gestionarlo como cualquier otro presupuesto.
De dónde viene el costo
Una aplicación única se compila una sola vez. El bundler ve todo el código, elimina duplicados y decide cómo dividirlo. Una plataforma de microfrontends se compila por partes, en pipelines distintos, y ningún bundler ve el panorama completo. La optimización que la herramienta de build hacía gratis ahora se logra con acuerdos entre equipos.
| Costo | Causa | Control principal |
|---|---|---|
| Dependencias duplicadas | Cada remoto empaqueta su propia copia de una librería | Singletons compartidos con versiones alineadas |
| Más peticiones | Manifiesto, remote entry y chunks por remoto | Lazy loading, caché, precarga |
| Cascada de carga | Cada paso descubre el siguiente | Manifiesto temprano, precarga |
| CSS duplicado | Cada remoto incluye los estilos del design system | Un tema compartido que carga el host |
| Más trabajo de arranque | Cada remoto ejecuta su propio código de inicio | Cargar solo lo que la ruta necesita |
Dependencias duplicadas
Suele ser el costo más grande. Si el host y tres remotos empaquetan cada uno su copia de Angular, RxJS y la librería de componentes, el usuario descarga y procesa el mismo código cuatro veces. Con un framework como Angular, dos instancias en una página también pueden causar bugs reales.
El control es compartir. Module Federation y Native Federation permiten declarar librerías como compartidas, de modo que la primera copia que carga la reutilizan todos. Declara el framework y cualquier librería con estado como singleton y activa la verificación estricta de versiones.
Compartir tiene una condición: las versiones deben ser compatibles. Si un remoto se queda atrás, el runtime carga una segunda copia o falla, según la configuración. La alineación de versiones se explica en dependencias compartidas y versiones.
No compartas todo. Una librería compartida suele cargarse completa, porque ningún build sabe qué partes usan los demás remotos. También se convierte en una versión que todos los equipos deben coordinar. Comparte el framework, el design system y las pocas librerías que guardan estado. Deja que las utilidades pequeñas se empaqueten dentro de cada remoto, donde el tree shaking todavía elimina el código sin uso.
Peticiones y cascada de carga
Una primera carga típica sigue este orden: HTML del host, bundles del host, manifiesto, remote entry, chunks del remoto y luego los datos. Cada paso empieza cuando termina el anterior.
Formas de aplanar la cascada:
- Carga los remotos de forma diferida, por ruta. Un usuario que abre el área de pedidos no debería descargar facturación.
- Pide el manifiesto temprano, o inclúyelo en el HTML del host cuando el modelo de despliegue lo permita.
- Precarga el remoto más probable. Cuando el navegador esté inactivo, o cuando el usuario pase el cursor sobre un enlace de navegación, pide ese remote entry por adelantado.
- Configura bien la caché. Los archivos con hash de contenido en el nombre pueden guardarse en caché por mucho tiempo. El manifiesto y los remote entry necesitan una caché corta o revalidación, porque apuntan a la versión vigente.
Presupuestos por remoto
Un presupuesto de plataforma sin dueño se ignora. Dale a cada remoto su propio presupuesto y haz que su pipeline lo exija.
- Presupuesto de tamaño. Angular CLI soporta
budgetsen la configuración de build, con umbrales de advertencia y de error. - Chequeo de dependencias compartidas. Haz fallar el build si un remoto empaqueta una librería que debería venir del scope compartido. Un reporte del analizador de bundles en el pipeline lo hace visible.
- Presupuesto por ruta. Define una meta para el tiempo de renderizado de la pantalla principal de cada área, en un dispositivo y una red de referencia.
El equipo de plataforma es dueño del presupuesto del host. Todos los usuarios pagan el host en cada visita, así que debe mantenerse pequeño: layout, navegación, sesión y la lógica de carga. Más en el host o shell de microfrontends.
Cómo medir
Las herramientas de laboratorio muestran lo que costaría un build. Los datos de campo muestran lo que viven los usuarios. Necesitas ambos.
- Datos de campo. Recoge Core Web Vitals (LCP, INP, CLS) de usuarios reales y etiqueta cada medición con la ruta y el remoto dueño. Sin la etiqueta, un remoto lento se esconde en un promedio global.
- Tiempo de carga del remoto. Mide el tiempo desde el inicio de una navegación hasta que el remoto queda montado. La Performance API del navegador permite marcar ambos puntos.
- Chequeos de laboratorio en el pipeline. Corre Lighthouse o una herramienta similar contra la aplicación compuesta en cada publicación del host y de cada remoto.
El costo en ejecución
El tamaño de descarga es solo una parte. Varios remotos en una pantalla también significan más JavaScript que procesar y más trabajo de renderizado. Es una de las razones para dividir por área de negocio y evitar un remoto por widget. Más sobre esto en errores comunes en microfrontends.
Una meta realista: la primera carga de una plataforma de microfrontends debería estar cerca de lo que logra una aplicación única bien construida para la misma pantalla. Si es mucho peor, las causas habituales son un framework duplicado, un host pesado o remotos que cargan de forma anticipada.
Más en esta sección
- Pruebas en microfrontends: una estrategia práctica
- Monorepo vs polirepo para microfrontends
- De monolito frontend a microfrontends, paso a paso
- Una app AngularJS legacy dentro de un host de microfrontends
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn