Presupuestos de tamaño: fallar el CI si el bundle crece

El treemap es una foto; el peso, una película. Optimizas un bundle a 160 KB, y tres semanas después alguien añade una librería “pequeña”, otro un polyfill, otro un import descuidado, y sin que nadie lo decida el bundle vuelve a 240 KB. La regresión de rendimiento rara vez llega de golpe: llega por mil cortes, cada uno defendible en aislamiento. La única defensa que escala es hacer del peso una restricción mecánica: fijar un presupuesto y que el CI falle cuando un PR lo supere. size-limit mide el tamaño comprimido real y bloquea el merge si el número cruza la línea. Deja de ser algo que recuerdas vigilar y pasa a ser algo que el sistema no te deja olvidar.

Medir el comprimido, no el disco

size-limit no lee el tamaño en disco de tus archivos: los procesa como lo haría un navegador. Coge el fichero de salida, lo comprime como lo haría un CDN —brotli por defecto en las versiones recientes, que es lo que sirve la red de verdad— y compara esa cifra con el límite que declaras. El preset @size-limit/preset-app va un paso más allá y estima, además del peso, el tiempo de descarga en una conexión lenta y de ejecución en un dispositivo modesto, uniendo tamaño y experiencia en una sola medida.

// .size-limit.json — un presupuesto por artefacto, con limite explicito
[
  {
    "name": "App inicial",
    "path": "dist/assets/index-*.js",
    "limit": "160 KB"
  }
]

// package.json — el preset elige como medir; file basta si solo quieres peso
{
  "scripts": { "size": "size-limit" },
  "devDependencies": {
    "size-limit": "^11.0.0",
    "@size-limit/preset-app": "^11.0.0"
  }
}

El campo path acepta globs, de modo que el asterisco absorbe el hash de contenido que cambia en cada build. Ejecutar size imprime el tamaño comprimido y sale con código cero si cabe en el presupuesto, o con código distinto de cero si lo rebasa —exactamente lo que un CI necesita para pasar o fallar—. Y cuando el número sube y no sabes por qué, size-limit --why abre un analizador que explica qué módulos entraron, cerrando el círculo con la lección anterior.

El presupuesto como puerta del CI

Un presupuesto que solo corres en tu máquina es un buen propósito; uno que corre en cada PR es una ley. La integración con GitHub comenta en el pull request el tamaño actual y su delta respecto a la rama base, de modo que quien revisa ve, sin salir del diff, que este cambio suma 34 KB comprimidos. Si el total supera el límite, el check se pone en rojo y bloquea el merge.

# .github/workflows/size.yml — el presupuesto vive en cada pull request
name: size
on: [pull_request]
jobs:
  size:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci && npm run build
      - uses: andresz1/size-limit-action@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

flowchart TD
pr[Abres un pull request] --> build[El CI construye el bundle]
build --> medir[size-limit comprime y mide]
medir --> puerta{Supera el presupuesto}
puerta -->|si| rojo[Check en rojo bloquea el merge]
puerta -->|no| verde[Check en verde con el delta comentado]
style rojo fill:#f38ba8,color:#11111b
style verde fill:#a6e3a1,color:#11111b

Lo valioso de la puerta no es solo que atrape la regresión, sino cuándo la atrapa: en el momento de la revisión, cuando el autor todavía tiene el contexto fresco y el coste de revertir es mínimo. Detectar el mismo problema semanas después, en un informe de rendimiento de producción, significa arqueología —averiguar cuál de cien commits lo introdujo— en lugar de una conversación de dos líneas en el PR. Mover la detección hacia la izquierda del ciclo es la esencia de la calidad barata.

Presupuestos por ruta y el trinquete

Un único presupuesto global es un comienzo, pero pronto miente. No todas las pantallas merecen el mismo límite: la landing pública que decide tu tasa de rebote debe ser mucho más ligera que un panel de administración que solo ven usuarios ya comprometidos. Un presupuesto global promedia ambos y esconde el problema —la landing puede engordar mientras el promedio se mantiene porque el panel adelgazó—. La solución es un presupuesto por ruta: una entrada por chunk de ruta, cada una con su propio umbral.

// .size-limit.json — cada ruta defiende su propio limite
[
  {
    "name": "Landing (critica)",
    "path": "dist/assets/landing-*.js",
    "limit": "90 KB"
  },
  {
    "name": "Panel (tolerante)",
    "path": "dist/assets/panel-*.js",
    "limit": "320 KB"
  }
]

Fijar el número correcto es un arte con una trampa: el instinto es poner el límite muy por encima del tamaño actual “por si acaso”, pero un presupuesto holgado no protege de nada. La disciplina es el trinquete: ajusta el límite un pelo por encima del peso real y, cada vez que una optimización lo reduzca, baja el límite hasta el nuevo suelo. Así el presupuesto solo se mueve en una dirección —hacia abajo— y el terreno ganado queda blindado contra la regresión.