El presupuesto de JavaScript: medir, minimizar, decidir

Medir cuánto pesa cada isla

No se administra lo que no se mide, y el primer instrumento lo trae Astro de fábrica: la propia salida del build. Cada trozo de cliente que emite aparece en la terminal con su tamaño en crudo y comprimido con gzip, que es lo que de verdad viaja por la red. Ese informe es tu extracto de cuenta.

npm run build# Astro lista cada trozo de cliente con su tamano# dist/_astro/Comentarios.a1b2c3.js   42.10 kB | gzip: 14.80 kB# dist/_astro/client.e4f5g6.js         9.30 kB | gzip:  3.70 kB

La columna que importa es la de gzip: un componente de cuarenta kilobytes que se comprime a quince cuesta quince en la red. Lee esa lista como un balance —cada línea es un cargo— y asocia cada trozo a la isla que lo originó por su nombre. Cuando un chunk sorprende por su peso, casi siempre esconde una dependencia dentro, no el componente en sí.

Para ver qué infla un trozo, un visualizador de bundle desglosa el interior en un mapa de áreas donde cada rectángulo es un módulo y su superficie es proporcional a lo que aporta.

npx vite-bundle-visualizer# genera un treemap: el rectangulo mas grande suele ser# una dependencia, no tu propio codigo

Minimizar la hidratación

Con la medición en la mano, minimizar es actuar sobre tres palancas ordenadas por impacto. La primera y más rentable es cuestionar la existencia de la isla: mucho de lo que se marca interactivo se resuelve con HTML y CSS —un details nativo, un enlace ancla, una animación por CSS— sin una gota de JavaScript. La isla más barata sigue siendo la que no existe.

La segunda palanca es el framework. Ya viste en el nivel de islas que Preact, Solid o Svelte pesan una fracción de React; en un presupuesto ajustado, esa elección se paga en cada visita y es de las que más rinde. La tercera es la dependencia: una librería de fechas de cien kilobytes importada dentro de una isla para formatear una hora cuesta eso, se use o no, y suele ser el rectángulo grande del treemap.

---// Antes: una isla solo para desplegar contenidoimport Acordeon from '../components/Acordeon.jsx';---<Acordeon client:visible /><!-- Despues: cero JavaScript, con un elemento nativo --><details>  <summary>Ver detalles</summary>  <p>Contenido que ya estaba en el HTML.</p></details>

client:visible frente a client:only

Las directivas ya las conoces; lo que este nivel exige es elegir entre las dos que más se confunden. client:visible renderiza la isla a HTML en el servidor y difiere solo su hidratación hasta que entra en pantalla: el visitante ve el marcado desde el primer instante y el JavaScript llega después. client:only hace algo distinto y más drástico: omite el renderizado de servidor por completo. El componente no produce HTML; el navegador lo monta desde cero tras descargar su código.

---import Grafica from '../components/Grafica.jsx';---<div class="reserva-grafica">  <Grafica client:only="react" /></div><style>  /* Reserva el alto para que la grafica no empuje el layout al montar */  .reserva-grafica { min-block-size: 320px; }</style>

El criterio es claro. Prefiere siempre client:visible: da HTML de servidor, mejor LCP y ninguna sorpresa de layout. Reserva client:only para lo que no puede renderizarse en el servidor —un componente que lee window o document en su cuerpo, o depende de una librería que solo existe en el navegador—. Cuando lo uses, recuerda dos cosas: nombrar el framework (client:only="react") porque Astro no lo infiere sin SSR, y reservar el espacio con CSS para no provocar un salto visual cuando la isla aparezca de golpe.

El presupuesto como contrato, no como buena intención

Un límite que solo vive en la cabeza del autor se erosiona en el primer día de prisa. Para que el presupuesto sobreviva, hay que convertirlo en una comprobación automática que falle el build cuando se rebase, igual que un test que se pone rojo. Herramientas como size-limit fijan un techo por entrada y lo verifican en cada integración.

# Falla la comprobacion si una entrada supera su techonpx size-limit# index:    48.2 kB (limite 50 kB)  OK# articulo: 63.1 kB (limite 50 kB)  EXCEDIDO

Con esa red puesta, el presupuesto deja de depender de la disciplina individual y pasa a ser una propiedad del proyecto que nadie rompe sin enterarse. La conversación cambia de tono: en vez de descubrir semanas después, en las métricas de campo, que una página engordó, el autor lo ve en la revisión, cuando aún es barato revertirlo. Un presupuesto vigilado por la máquina es lo que separa una intención de una garantía.