El coste de las polyfills y de los transpilados que ya no hacen falta

La configuración de compilación de un proyecto es un sedimento: cada capa se añadió por una razón válida en su momento y casi ninguna se retira cuando la razón desaparece. El resultado, en un proyecto de tres o cuatro años, suele ser un bundle que envía polyfills para navegadores que ya no existen y transpila sintaxis moderna a equivalentes de 2015 que todos los motores entienden nativamente desde hace ocho años. El coste combinado está entre el 15 y el 40 por ciento del peso, y se recupera cambiando una línea de configuración.

Polyfill y transformación no son lo mismo

Son dos mecanismos distintos con costes distintos, y confundirlos impide razonar sobre ellos.

Una polyfill implementa una API que falta. Array.prototype.at, Object.hasOwn, structuredClone, Promise.allSettled: son funciones que o están en el motor o no están, y si no están se pueden añadir en tiempo de ejecución. Una polyfill es código adicional que se ejecuta y se queda.

Una transformación de sintaxis reescribe tu código en una forma equivalente que un motor antiguo pueda parsear. El encadenamiento opcional, la desestructuración, async/await, los campos privados de clase: son formas gramaticales, y si el motor no las entiende, el fichero entero falla al parsearse. No se pueden polirrellenar; hay que reescribirlas.

La diferencia práctica: una polyfill que no hace falta es peso muerto pero no toca tu código. Una transformación innecesaria cambia todo tu código y afecta al tamaño, al parseo y a la velocidad de ejecución.

Lo que cuestan las polyfills

Los números concretos de lo que se suele encontrar en una configuración heredada:

Las tres últimas filas son ejemplos de un patrón que hay que buscar activamente: polyfills de APIs que llevan años en todos los motores. Están en el bundle porque alguien las añadió cuando hacían falta y nadie las quitó. Buscar sus nombres en el árbol de dependencias es un ejercicio de diez minutos que suele encontrar tres o cuatro.

# Polyfills clasicos que ya no hacen falta en ningun navegador con soporte
npm ls whatwg-fetch isomorphic-fetch es6-promise promise-polyfill \
       intersection-observer resize-observer-polyfill \
       object-assign babel-polyfill core-js@2 2>/dev/null

La otra mitad del problema es la inyección automática. Las herramientas modernas insertan solo las polyfills que tu código necesita, según tu objetivo de navegadores. Eso está bien y es lo correcto, con dos matices que producen sorpresas.

Matiz uno: la inyección se hace por uso sintáctico, no por análisis de flujo. Si en algún sitio escribes .includes(, la herramienta puede inyectar la polyfill de Array.prototype.includes y la de String.prototype.includes, porque no sabe de qué tipo es el receptor. La suma de esos falsos positivos es real.

Matiz dos: el objetivo de navegadores lo controla una lista que a menudo nadie ha mirado. Si tu proyecto tiene un browserslist con > 0.2% o, peor, defaults, estás sirviendo compatibilidad para navegadores que representan una fracción de tu tráfico o directamente cero. La comprobación es inmediata:

npx browserslist
# Y cuanto trafico representan de verdad, con tus propios datos:
npx browserslist --coverage

Ver la lista resultante es normalmente la parte más convincente del ejercicio: aparecen versiones de navegadores que ninguno de tus usuarios tiene.

Lo que cuesta transpilar sintaxis

Aquí las cifras son mayores y menos conocidas. Transpilar sintaxis moderna a la de 2015 no solo añade ayudantes: reescribe el código en formas más largas y más lentas.

Los tres casos que más pesan:

async/await a generadores y máquinas de estado. Es la transformación más cara con diferencia. Una función asíncrona de diez líneas se convierte en una máquina de estados con un switch, un objeto de contexto y llamadas a un ayudante de tiempo de ejecución. El código resultante puede ser tres o cuatro veces más largo y ejecutarse notablemente más lento, porque el motor pierde la capacidad de optimizar la función asíncrona nativa.

Clases a funciones con prototipos. Cada clase genera funciones auxiliares para la herencia, para la comprobación de instancia, para los campos. En una base de código con doscientas clases, esos ayudantes se repiten o se importan y suman.

Desestructuración y propagación a bucles. Un const { a, b, ...resto } = obj se convierte en varias líneas con un ayudante que copia propiedades. Inocuo una vez, medible dos mil veces.

El efecto agregado, medido sobre una aplicación real al cambiar el objetivo de compilación de sintaxis de 2015 a sintaxis moderna, está típicamente entre el 10 y el 25 por ciento del tamaño del bundle, y una parte proporcional del tiempo de ejecución. Sin tocar una línea de código propio.

// El fuente que escribes
async function cargar(id) {
  const { datos, meta } = await pedir(`/api/${id}`);
  return { ...meta, total: datos.length };
}

// Aproximadamente lo que produce un objetivo antiguo: mas largo y mas lento
function cargar(id) {
  return _asyncToGenerator(function* () {
    var _yield = yield pedir("/api/".concat(id)),
        datos = _yield.datos,
        meta = _yield.meta;
    return _objectSpread(_objectSpread({}, meta), {}, { total: datos.length });
  })();
}

El fragmento de arriba es ilustrativo, no literal —cada versión de cada herramienta genera algo ligeramente distinto— pero la forma es exactamente esa, y el ayudante _asyncToGenerator con su tiempo de ejecución de regenerador puede añadir por sí solo entre 5 y 15 KB al bundle.

{
  "browserslist": [
    "chrome >= 111",
    "edge >= 111",
    "firefox >= 113",
    "safari >= 16.4",
    "not dead"
  ]
}

La auditoría, en veinte minutos

Cuatro comprobaciones, por orden.

Uno: mira tu browserslist y ejecuta npx browserslist para ver la lista expandida. Si aparecen navegadores que no reconoces o versiones de hace ocho años, ahí está el problema.

Dos: busca importaciones de bibliotecas de compatibilidad en tu código. Un import 'core-js' o similar en el punto de entrada arrastra el conjunto completo, ignorando cualquier configuración de inyección automática. Es el fallo más común.

Tres: busca el tiempo de ejecución del transpilador en el informe del bundle. Los ayudantes suelen aparecer con nombres reconocibles y agrupados. Si suman más de 10 KB comprimidos, tu objetivo de compilación es demasiado antiguo.

Cuatro: cambia el objetivo, compila y compara. Es la medición que decide, y es la que hay que llevar a la discusión:

npm run build && node scripts/tamanos.mjs > /tmp/antes.txt
# edita browserslist al objetivo moderno
npm run build && node scripts/tamanos.mjs > /tmp/despues.txt
diff -u /tmp/antes.txt /tmp/despues.txt

Ejecuta las pruebas después del cambio y prueba manualmente en la versión más antigua del suelo que has fijado. Es un cambio de bajo riesgo, no de riesgo cero: si tu código usa una API que tu objetivo antiguo estaba polirrellenando y el nuevo no, se rompe en tiempo de ejecución y no en compilación.