Por qué empaquetar en producción

En el nivel 16 viste la paradoja: en desarrollo, Vite sirve ESM nativo sin empaquetar —cientos de módulos diminutos, cada uno su propia petición— y va como un tiro. La pregunta incómoda es entonces obvia. Si sin empaquetar funciona, ¿por qué empaquetar para producción? La respuesta es que localhost te engaña. Sobre tu máquina, con latencia casi nula, servir mil módulos sueltos es gratis; sobre internet real, con latencia de verdad y navegadores de verdad, ese mismo enfoque se desploma. Empaquetar en producción se gana el sueldo en tres frentes: reduce las peticiones, habilita optimizaciones que exigen ver el grafo entero, y produce un artefacto compatible con el mundo tal como es, no como nos gustaría.

El problema de las mil peticiones

Con ESM nativo, cada módulo es una petición HTTP. Una app real no tiene diez módulos: tiene cientos o miles, entre tu código y sus dependencias. Pero el número no es lo peor; lo peor es la cascada. El navegador no puede pedir un módulo hasta que ha descargado y parseado a quien lo importa y ha descubierto ese import. La profundidad del grafo se traduce en rondas de ida y vuelta secuenciales: para llegar a un módulo enterrado diez niveles abajo, el navegador encadena diez viajes a la red antes de poder ejecutarlo.

En localhost ese coste es invisible porque el tiempo de ida y vuelta es casi cero. Pon la misma app sobre internet, con 50 a 100 milisegundos de latencia por viaje y un grafo de diez niveles de profundidad, y tienes medio segundo o más de pura espera en cascada antes de que corra la primera línea útil. Empaquetar colapsa esos cientos de módulos en unos pocos archivos: pocas peticiones, sin cascada de descubrimiento, porque todo lo que se necesita junto viaja junto.

El coste de servir sin empaquetar no es un solo número, sino una suma de sobrecostes que se acumulan:

• La cascada de descubrimiento, donde la profundidad del grafo se paga en rondas de red secuenciales.
• El coste por petición, con sus cabeceras y su ida y vuelta, multiplicado por cada módulo.
• Una compresión peor, porque muchos archivos diminutos comparten menos redundancia que unos pocos grandes.
• La contención, cuando un enjambre de peticiones satura los límites de conexiones concurrentes del navegador.

flowchart TD
subgraph sin[Sin empaquetar]
  h1[HTML] --> e1[main.js]
  e1 --> e2[app.js]
  e2 --> e3[Button.js]
  e3 --> e4[util.js]
end
subgraph con[Empaquetado]
  h2[HTML] --> b1[bundle unico]
end
style e4 fill:#f38ba8,color:#11111b
style b1 fill:#a6e3a1,color:#11111b

Optimizaciones que exigen el grafo completo

El segundo pilar es más sutil. Hay optimizaciones que son imposibles viendo un módulo aislado y triviales viendo el grafo entero, porque son globales por naturaleza. Servir módulos crudos, uno a uno, renuncia a todas ellas; empaquetar las desbloquea de golpe.

Y no se agotan ahí; tener el grafo entero delante habilita toda una familia de decisiones globales:

• Eliminación de código muerto que cruza fronteras de módulo, no solo dentro de uno.
• Concatenación en un único ámbito que borra el runtime de envoltura entre módulos.
• Elevación de constantes compartidas y plegado de expresiones ya conocidas en compilación.
• Reordenación segura de módulos cuando el análisis demuestra que no hay efectos observables.

El hilo común es que ninguna de estas optimizaciones cabe en la frontera de un solo módulo. El tree shaking necesita la clausura transitiva para razonar sobre alcanzabilidad de exports; el scope hoisting necesita saber quién importa a quién para fusionar ámbitos sin colisiones; la minificación agresiva y la compresión rinden en proporción a cuánto contexto abarcan. Empaquetar no es solo juntar archivos: es crear la condición —tener el grafo entero en la mano— bajo la cual estas transformaciones globales se vuelven posibles.

Un ejemplo mínimo lo hace tangible. Si tu código importa una sola función de un módulo con varias, solo el grafo completo puede demostrar que el resto no se usa en ninguna parte y borrarlo sin miedo:

// utils.js exporta dos funciones
export function usada() { return 1; }
export function jamas() { return 2; }   // nadie la importa en todo el grafo

// app.js importa solo una
import { usada } from "./utils.js";
usada();
// tras el tree shaking, jamas() no existe en el bundle: era codigo muerto

Compatibilidad con el mundo real

El tercer pilar es el menos glamuroso y el más ineludible. El navegador es un entorno hostil para el código tal como lo escribes y tal como te llegan las dependencias. Empaquetar es también el acto de normalizar esa maraña en un artefacto que el navegador acepte sin protestar.

Empieza por la resolución. El navegador no tiene concepto de node_modules: si le sirves import React from "react", no sabe dónde está react, porque un especificador bare no es una URL. El bundler resuelve esos especificadores a rutas concretas —es, de hecho, por lo que Vite pre-empaqueta las dependencias incluso en dev, como viste en el nivel 13—. Sigue por el formato: media web publica sus paquetes en CommonJS, y un navegador no sabe hacer require; el bundler convierte ese CJS a ESM para que cargue. Y termina por la sintaxis y los assets: rebaja las construcciones modernas al target de navegadores que soportas, e integra CSS, imágenes y fuentes que el navegador jamás importaría como módulos.

// Lo que escribes y lo que te llega no es lo que el navegador entiende
import React from "react";        // bare specifier: el navegador no sabe resolverlo
const x = require("left-pad");    // CommonJS: el navegador no tiene require
import "./estilos.css";           // un import que el navegador no haria de un css

Normalizar, en concreto, significa hacerse cargo de todo esto de una sola vez, para que el navegador reciba un artefacto que ya no asume ningún build ni ningún resolvedor de Node:

• Resolver los especificadores bare a rutas reales, porque el navegador no conoce node_modules.
• Convertir CommonJS a ESM, porque un navegador no tiene require y buena parte del ecosistema aún publica en CJS.
• Rebajar la sintaxis al conjunto de navegadores que soportas, guiado por tu target.
• Integrar los assets —CSS, imágenes, fuentes— que el navegador jamás importaría por sí mismo como módulos.

Esta normalización es tan ineludible que asoma incluso en desarrollo. Aunque Vite no empaquete tu código en dev, sí pre-empaqueta las dependencias con esbuild —el optimizeDeps del nivel 13— justamente para convertir su CommonJS a ESM y resolver sus especificadores bare antes de servirlas. Es decir: la parte de compatibilidad del empaquetado no es negociable ni siquiera cuando renuncias al resto. El navegador nunca sabrá qué es react ni cómo hacer require, corras en dev o en prod.