Enviar menos código

Lazy loading (carga diferida) es retrasar la descarga de todo lo que no se necesita para la primera vista hasta el momento en que hace falta. Para imágenes e iframes, los navegadores lo hacen de forma nativa con el atributo loading="lazy": no los piden hasta que el usuario se acerca a ellos con el scroll.

Así la red queda libre para lo importante al principio, y quien no baja hasta el final no descarga lo que nunca iba a ver. Para el código, los equivalentes son el import() dinámico y, en Angular, @defer y las rutas lazy, que verás a continuación.

Un import normal, arriba del archivo, mete el módulo en el mismo paquete que el código que lo usa. El import() dinámico es una función que devuelve una promesa y descarga el módulo cuando la llamas. Los bundlers lo detectan y ponen ese módulo en un archivo aparte.

Es perfecto para librerías pesadas que solo usan algunas personas: exportar a PDF o a Excel, un editor de texto enriquecido, una librería de gráficos para un informe que se abre de vez en cuando.

Las rutas lazy cargan una página solo cuando el usuario navega a ella: en la configuración del router usas loadComponent con un import() dinámico (o loadChildren para un grupo de rutas), y Angular pone ese código en su propio archivo.

Los bloques @defer hacen lo mismo dentro de una plantilla. Envuelves un componente pesado y Angular lo separa, junto con sus dependencias, y lo carga según un disparador: on viewport al entrar en pantalla, on interaction al pulsar, on hover, on timer(…), when una condición o, si no indicas ninguno, on idle, cuando el navegador está libre. Con @placeholder y @loading decides qué se ve mientras tanto. Lo viste también en el módulo de frameworks, al hablar de rendimiento.

En lugar de un único main.js enorme, el bundler genera varios chunks: el inicial, con lo que necesita cualquier página, y otros que se descargan bajo demanda. Los puntos de corte son tus import() dinámicos: por ruta, un chunk por página, y por componente, para un widget pesado.

El bundler también extrae los chunks compartidos: si dos páginas usan la misma librería, va en un archivo aparte que se descarga una sola vez y queda en caché. Y como cada chunk lleva un hash en el nombre, un cambio en una página no invalida la caché de las demás.

El tree shaking (sacudir el árbol para que caigan las hojas secas) elimina las funciones y módulos que nadie usa. Funciona gracias a que import y export de los módulos ES son estáticos: el bundler sabe al compilar exactamente qué se usa y qué no.

Con CommonJS no puede: require() es una llamada a una función que se puede hacer con un nombre calculado o dentro de un if, así que el bundler no se atreve a quitar nada. Por eso lodash, en CommonJS, entra entero, y lodash-es solo con lo que usas.

Las librerías pueden ayudar con "sideEffects": false en su package.json: le dice al bundler que importar un módulo no hace nada más que exportar cosas, así que puede descartar entero cualquier módulo que no se use. Si algunos archivos sí tienen efectos, como el CSS, se listan: "sideEffects": ["*.css"].

Un presupuesto de rendimiento es un compromiso medible: «el JavaScript inicial no pasa de 300 kB», «el LCP de laboratorio, menos de 2,5 segundos», «menos de 50 peticiones». Sin él, cada nueva función añade un poco y nadie se da cuenta hasta que la web ya va lenta.

Angular trae presupuestos de tamaño en angular.json, dentro de budgets. Cada uno tiene un tipo, como initial (el paquete inicial) o anyComponentStyle (el CSS de cada componente), y dos umbrales: al superar maximumWarning avisa, y al superar maximumError, la build falla. Para métricas como el LCP, Lighthouse CI permite fijar límites similares en el pipeline.