terser, esbuild y oxc-minify: el trade-off velocidad/tamaño

Todos los minificadores hacen lo mismo —quitar espacios, acortar nombres, podar lo muerto—, pero no todos lo hacen igual de bien ni igual de rápido, y ahí nace una decisión de ingeniería con consecuencias reales sobre tu tiempo de build y sobre los bytes que envías. terser es el veterano que exprime cada byte a costa de ser lento; esbuild es el velocista que sacrifica un poco de tamaño por ir cien veces más deprisa; oxc-minify, el recién llegado en Rust, aspira a no ceder en ninguno de los dos frentes. Elegir bien exige entender que velocidad y tamaño son ejes en tensión, y que el eje que de verdad importa a tu usuario no es ninguno de los dos que el minificador optimiza directamente.

Tres motores para una misma tarea

terser es el patrón oro de la compresión. Heredero de UglifyJS —que solo entendía ES5— fue reescrito para hablar JavaScript moderno, y está escrito en JavaScript. Ofrece el compress y el mangle más agresivos del ecosistema, con decenas de opciones y hasta varias pasadas sobre el mismo código. Ese refinamiento se paga en tiempo: analizar y reescribir el AST en un lenguaje de un solo hilo es lento, y en un proyecto grande el paso de minificado puede volverse el cuello de botella del build.

esbuild invirtió la ecuación. Escrito en Go, compilado y paralelo, minifica como parte de su propia generación de código a una velocidad de uno a dos órdenes de magnitud sobre terser. Su salida es un poco mayor —un pequeño porcentaje— porque no persigue cada micro-optimización, pero a cambio el minificado deja de notarse en el reloj. Expone la operación de forma granular con minifyWhitespace, minifyIdentifiers y minifySyntax, por si quieres activar solo una parte.

oxc-minify es la apuesta de 2026. Forma parte de Oxc —el Oxidation Compiler, en Rust— y su ambición declarada es alcanzar una compresión cercana a la de terser a una velocidad del orden de la de esbuild. Todavía madura, pero viaja dentro de Rolldown, así que a medida que Rolldown se convierte en el motor de Vite 8, oxc-minify pasa a ser el minificador nativo de todo el stack, sin instalar nada aparte.

Conviene nombrar también a swc, el otro minificador en Rust nacido antes que Oxc: existe y funciona, pero en 2026 el impulso del ecosistema converge sobre Oxc por su integración con Rolldown y Vite. La historia se repite: primero JavaScript, luego Go, ahora Rust, cada salto recortando un orden de magnitud.

Ese relevo de motores deja una pregunta práctica: dado que los tres hacen la misma tarea, ¿qué decide cuál usar? Tres ejes, y ninguno es “cuál comprime más en abstracto”:

• Cuánto pesa tu tiempo de build, que pagas en cada commit y en cada despliegue.
• Cuántas veces se descarga tu salida, que multiplica el valor de cada byte ahorrado.
• Qué motor es nativo de tu bundler, porque integrarse ahorra un parseo y una dependencia.

El trade-off velocidad/tamaño

Los tres motores ocupan puntos distintos de una misma frontera de Pareto. terser vive en el extremo de tamaño mínimo y tiempo máximo; esbuild, en el de tiempo mínimo y tamaño ligeramente mayor; oxc-minify intenta lo difícil, empujar la frontera hacia dentro para no ceder en ninguno. Que exista frontera significa que, con las herramientas de una misma generación, ganar tamaño cuesta tiempo y ganar tiempo cuesta tamaño.

Conviene nombrar los ejes que esa frontera enfrenta:

• Tiempo de build: cuánto tarda el minificador; lo pagas tú, en cada compilación.
• Tamaño de salida: cuántos bytes produce; lo paga el usuario, en cada descarga.
• Agresividad: cuántas transformaciones intenta; más ahorro a cambio de más tiempo.
• Integración: si es un paso aparte o parte del bundler, lo que cambia la velocidad total.

flowchart TD
P[Que priorizas en el build] --> V{Velocidad o tamano}
V -->|tamano minimo| T[terser mas lento]
V -->|velocidad bruta| E[esbuild muy rapido]
V -->|ambos a la vez| O[oxc-minify emergente]
style T fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b
style O fill:#a6e3a1,color:#11111b

Dentro de terser, ese trade-off aparece incluso en una sola opción: compress.passes. Cada pasada adicional vuelve a recorrer el código en busca de nuevas oportunidades que la anterior abrió, y suele arañar algún byte más, pero con rendimientos decrecientes y un coste de tiempo lineal. Dos pasadas es un compromiso común; cinco rara vez justifican la espera.

Puesto en una tabla, cada motor ocupa un punto distinto del compromiso:

El trade-off se afina con unas pocas palancas, todas con rendimientos decrecientes:

• Número de pasadas: cada una araña bytes, pero el tiempo crece y el ahorro se agota.
• Agresividad del compress: más reglas activas, más tiempo de análisis por un puñado de bytes.
• mangle de propiedades: ahorra de verdad, pero solo si asumes su riesgo con listas de reservados.
• Paralelismo del motor: lo que uno en Rust o Go reparte entre núcleos, terser lo hace en un solo hilo.

// vite.config.ts — elegir y afinar el minificador
export default defineConfig({
  build: {
    minify: "terser",           // por defecto seria "esbuild"
    terserOptions: {
      compress: { passes: 2 },  // rendimientos decrecientes a partir de aqui
      mangle: true,
    },
  },
});

Qué elige tu herramienta, y qué deberías medir

Vite trae esbuild como minificador por defecto —build.minify vale "esbuild"— justamente porque el tiempo de build importa y la diferencia de tamaño es pequeña. Poner "terser" es opt-in y exige instalarlo aparte; tiene sentido cuando cada kilobyte cuenta y el build puede permitirse la lentitud. Con Vite 8 y Rolldown, el cuadro se desplaza: el minificador nativo pasa a ser oxc-minify, y la elección deja de ser entre lento-pequeño y rápido-grande.

# terser no viene incluido: instalalo si vas a usarlo
npm install -D terser
# esbuild ya viaja dentro de Vite; oxc-minify llega con Rolldown

esbuild permite además activar solo una parte del minificado, útil cuando quieres apretar espacios pero conservar los nombres para poder leer el bundle:

// esbuild expone la operacion de forma granular
export default defineConfig({
  esbuild: {
    minifyWhitespace: true,
    minifyIdentifiers: false,   // conserva los nombres legibles
    minifySyntax: true,
  },
});

La decisión práctica se reduce a unos pocos escenarios:

• App de producto en iteración rápida: esbuild u oxc-minify, porque el tiempo de build se paga en cada commit.
• Librería muy descargada: terser con varias pasadas, porque el byte ahorrado se multiplica por millones de descargas.
• Presupuesto de bytes al límite: la máxima compresión disponible, midiendo siempre el tamaño comprimido.
• Monorepo con builds frecuentes: el motor más rápido, y la compresión del servidor haciendo el resto.