Code splitting: qué es y por qué

Un bundler resuelve tu grafo de módulos y, por defecto, lo aplana en un único archivo. Funciona, pero esconde un coste brutal: quien solo quiere ver la pantalla de login descarga, parsea y ejecuta también el editor enriquecido, el dashboard de analíticas y el visor de PDF que jamás abrirá en esa sesión. El code splitting es la técnica de partir ese monolito en fragmentos —los chunk— que llegan al navegador solo cuando hacen falta. No cambia lo que tu app hace; cambia cuándo llega cada parte.

El bundle monolítico y su coste oculto

Cuando el bundler emite un solo archivo, el tamaño de ese archivo crece con toda la aplicación, no con la pantalla que el usuario abre primero. Una SPA mediana en 2026 acumula con facilidad varios cientos de kilobytes de JavaScript ya minificado y comprimido; sin dividir, esos bytes forman una barrera que el navegador debe cruzar entera antes de pintar nada interactivo.

El problema no es solo la descarga. El JavaScript es, byte por byte, el recurso más caro que sirve una web. Una imagen de 300 KB se decodifica en un hilo aparte y aparece; 300 KB de JavaScript tienen que parsearse, compilarse a bytecode y ejecutarse en el hilo principal, el mismo que responde a los clics. Mientras ese hilo está ocupado evaluando código que la primera vista no usa, la interfaz está congelada.

La situación se agrava con el renderizado en servidor. Una app con SSR pinta el HTML en el servidor, pero ese HTML es inerte hasta que el JavaScript del cliente lo hidrata —vuelve a montar los componentes y engancha los listeners—. Si todo el código viaja en un monolito, la hidratación no empieza hasta descargar y parsear el bundle entero, así que la página se ve completa pero muerta durante un intervalo tanto más largo cuanto mayor sea el bundle. El splitting permite hidratar por partes, priorizando lo que el usuario ve y difiriendo el resto.

Hay además una asimetría perversa en cómo crece el monolito. Tu código de aplicación aumenta con cada funcionalidad que añades, pero también lo hace el árbol de dependencias que arrastras: una librería de gráficas, un cliente de mapas, un parser de fechas. Sin dividir, cada una de esas incorporaciones engorda el bundle que todos descargan, incluido quien nunca las usa. El coste de arranque de una feature deja de ser local —de quien la abre— y se vuelve global —de toda la base de usuarios—. Esa externalidad es la que convierte un monolito manejable en uno insostenible sin que ningún commit concreto parezca culpable.

Históricamente, esta técnica nació con webpack a mediados de la década de 2010, cuando las SPA crecieron hasta hacer inviable el bundle único, y desde entonces todo bundler serio la trae de fábrica. Lo que ha cambiado en 2026 no es la idea —sigue siendo diferir lo que no hace falta ahora— sino la calidad del automático: Rolldown, el motor en Rust de Vite 8, hace un chunking por defecto tan bueno que la mayoría de proyectos apenas necesita configurarlo. El trabajo del ingeniero se ha desplazado de implementar el splitting a decidir la política: dónde poner las fronteras y cuándo confiar en la herramienta.

Las tres fases del coste del JavaScript

Para razonar sobre qué gana el splitting hay que separar los tres costes que un bundle impone, porque el splitting ataca a los tres pero en distinta medida.

La fase que más sorprende es la segunda. Aunque el usuario nunca abra el visor de PDF, si su código está en el bundle inicial, el motor lo parsea y lo compila al arrancar. Ese trabajo es puro desperdicio: pagas por preparar código que esa sesión no ejecuta. El code splitting lo elimina de raíz al no enviar siquiera ese código hasta que se pide.

Los motores modernos intentan mitigar este coste con parseo perezoso: V8 hace una pasada superficial y difiere la compilación completa de cada función hasta su primera llamada. Pero es un paliativo, no una cura, porque incluso esa pasada superficial cuesta tiempo proporcional al tamaño del archivo, y las heurísticas de pre-parseo fallan a menudo, compilando de más código que no se usará. La única forma de no pagar por parsear un módulo es no enviarlo, y esa es exactamente la palanca del splitting: no optimiza el procesamiento del código muerto, lo hace ausente.

Puesto en una tabla, se ve cómo el splitting interviene en cada una de las tres fases por la vía de la ausencia, no del abaratamiento:

Dividir por el eje del tiempo

La idea central es partir la aplicación en dos conjuntos: lo que la primera vista necesita ahora —el camino crítico— y todo lo demás, que puede llegar después, cuando el usuario navegue a una ruta o abra una función pesada. El camino crítico debe ser lo más pequeño posible; el resto se difiere.

flowchart TD
subgraph Monolito
  M[bundle unico 800 KB parseado entero al arrancar]
end
subgraph Dividido
  E[entry 140 KB camino critico] --> R1[ruta editor 300 KB bajo demanda]
  E --> R2[ruta dashboard 240 KB bajo demanda]
  E --> S[compartido 120 KB cacheable]
end
style M fill:#f38ba8,color:#11111b
style E fill:#a6e3a1,color:#11111b
style S fill:#89b4fa,color:#11111b

El eje de división más rentable es la ruta: en una app con navegación, cada pantalla es una frontera natural. El usuario que aterriza en /login no necesita el JavaScript de /settings. Por debajo de la ruta está el eje del componente: un editor de texto enriquecido o un mapa interactivo son piezas pesadas que conviene diferir aunque vivan dentro de una misma pantalla, cargándose solo cuando el usuario los invoca.

Conviene ver estos ejes como un espectro de granularidad, no como una dicotomía. En un extremo, no dividir nada: el monolito. En el otro, dividir cada módulo: el over-splitting que estudiaremos al final del nivel. Entre ambos hay un continuo, y el arte consiste en elegir el grano adecuado para cada zona de la app —grueso donde el uso es homogéneo, fino donde hay piezas caras y opcionales—. La ruta es el grano que casi siempre acierta; el componente, el que hay que justificar caso por caso.

El splitting tampoco vive solo: se apoya en el tree shaking, la eliminación del código muerto que el bundler hace dentro de cada chunk. Son complementarios y actúan en planos distintos. El tree shaking pregunta “de lo que importas, ¿qué se usa?” y borra lo demás; el splitting pregunta “de lo que se usa, ¿qué hace falta ahora?” y difiere el resto. Un chunk bien formado es uno del que el tree shaking ya quitó lo inerte y que el splitting colocó en el momento correcto de carga.

En la práctica, el paso de una ruta cargada por defecto a una ruta diferida es un cambio de una línea, y todo el nivel siguiente lo dedicaremos a entender qué ocurre por dentro cuando lo escribes:

// Antes: la ruta pesada viaja en el bundle inicial de todos
import Settings from "./rutas/Settings.tsx";

// Despues: la ruta se difiere en su propio chunk, bajo demanda
const Settings = lazy(() => import("./rutas/Settings.tsx"));

El import() es la mitad mecánica del asunto; la otra mitad es la experiencia de espera. Un componente diferido necesita algo que mostrar mientras su chunk viaja, y de ahí las fronteras de carga como Suspense, que declaran el estado intermedio:

// La frontera decide que se ve mientras el chunk del componente llega
<Suspense fallback={<Esqueleto />}>
  <Settings />
</Suspense>

Sin esa frontera, diferir una vista dejaría un hueco en blanco durante la descarga; con ella, el usuario ve un esqueleto y percibe continuidad. Por eso el code splitting y el diseño de los estados de carga son dos caras de la misma decisión: no basta con partir el código, hay que orquestar con gracia el instante en que el trozo aún no ha llegado.

Lo que mide el usuario

El impacto del splitting se lee en las métricas de arranque. Un bundle inicial más pequeño mejora el FCP y el LCP, porque el navegador cruza antes la barrera de JavaScript y pinta contenido. Reduce el TBT y el INP, porque hay menos código bloqueando el hilo principal durante la carga. Y acorta el TTI, el momento en que la página deja de mentir: se ve lista pero ya responde de verdad.

Ninguna de esas métricas mejora por comprimir mejor los mismos bytes; mejoran porque hay menos bytes que procesar en el momento crítico. Esa es la diferencia entre el splitting y la minificación: la minificación hace el mismo código más pequeño, el splitting hace que parte del código ni siquiera esté presente cuando no toca.

De estas métricas, la que más peso gana en 2026 es el INP, que mide la latencia real de las interacciones a lo largo de toda la vida de la página, no solo en el arranque. Un bundle inicial hinchado la castiga por partida doble: retrasa el momento en que la primera interacción responde y, si el código diferido se carga en mal momento, introduce bloqueos del hilo principal en plena sesión. El splitting bien hecho no solo acelera el primer pintado; reparte el trabajo de JavaScript en el tiempo para que ninguna interacción concreta tope con una pared de compilación.

Medir bien, eso sí, exige honestidad sobre las condiciones. Un build local en una red de fibra y una CPU de sobremesa oculta casi todos los costes que este nivel describe; el bundle solo revela su verdadero peso en un dispositivo modesto y una red móvil, que es donde vive buena parte de tus usuarios. La regla es medir en el percentil que te importa, no en tu propia máquina, porque el splitting existe precisamente para los usuarios cuyo hardware y red hacen que cada kilobyte del arranque cuente.