Optimiza tus assets en el build, no en cada petición

La mayoría de los assets de un sitio se conocen mucho antes de que aparezca un solo visitante. La imagen principal, los iconos, el CSS empaquetado, las fuentes: viven en tu repositorio y son idénticos de una petición a la siguiente. Solo hay dos lugares para optimizarlos. Una vez, cuando compilas. O una y otra vez, en el edge, cada vez que se carga una página.

Para los assets que entregas tú mismo, el build es el mejor lugar.

Por qué en el build

Haces el trabajo una vez. La salida es pequeña en el momento en que se entrega y se mantiene pequeña, sin CPU por petición, sin caché de transformación que calentar, y sin una factura de transformación al vuelo que crece con tu tráfico.

El resultado también es algo que puedes ver. Los archivos optimizados están ahí mismo, en la salida de tu build, así que puedes compararlos, pesarlos y saber exactamente qué está saliendo. Una transformación en el edge es una caja negra en la que confías; un artefacto de build es un archivo que puedes abrir.

Y cubre más que las imágenes. Tu build ya se encarga de JavaScript, CSS, SVG y fuentes, y todos ellos también se reducen. Un TTF en bruto entregado en lugar de WOFF2 son unos dos tercios desperdiciados por sí solo.

Dónde el edge sigue ganándose su sitio

La optimización en el build solo toca los assets que pasan por tu build. Dos casos necesitan de verdad la ruta de la petición:

• Subidas de usuarios. Si la gente sube imágenes mientras tu sitio está en marcha, no puedes optimizarlas en el build. Eso necesita algo en la ruta de la petición: una API o un plugin de CMS.
• Catálogos enormes y variados que necesitan tamaños por dispositivo. Si de verdad sirves un tamaño distinto por dispositivo a lo largo de millones de imágenes, un servicio al vuelo se amortiza.

Para un sitio normal, que es la mayoría de los sitios, ninguno de esos es el cuello de botella, y el build es más simple y más barato.

Cómo hacerlo

Dos maneras, ambas funcionando sobre la API de Patu para que la codificación ocurra fuera de tu máquina.

Un comando, en cualquier script de build o tarea de CI:

PATU_KEY=your_key npx @patu.dev/cli ./dist

Recorre la carpeta, optimiza las imágenes, el SVG, el JS, el CSS y las fuentes en el sitio, y omite cualquier cosa que no pueda superar de verdad. Añade --cdn para subirlos y reescribir las referencias a cdn.patu.dev en lugar de escribir de vuelta en el disco.

O conéctalo a Vite, para que cada build quede cubierto sin que pienses en ello:

import patu from '@patu.dev/vite'
export default { plugins: [patu()] }

La idea

El edge no está mal. Pero hay bastantes probabilidades de que estés pagando por transformar, en cada petición, assets que nunca cambian entre ellas. Optimízalos una vez, en el build que ya ejecutas, y entrégalos pequeños. La página de integraciones tiene el CLI, el plugin de Vite y lo demás.