Patu

Haz de la optimización de assets un paso de CI, no algo que recuerdas

La optimización de assets funciona hasta que alguien se olvida. Un PNG principal de 3 MB se sube al repositorio, el build pasa, el despliegue sale, y nadie se da cuenta hasta que una puntuación de rendimiento se desploma una semana después. Entonces alguien lo optimiza a mano, y el reloj vuelve a empezar con la siguiente persona que se olvide.

Depender de que la gente se acuerde no es una estrategia. Muévela a donde olvidarse sea imposible.

Ponla en el pipeline

La optimización pertenece junto a tus pruebas y tu build: automática, en cada push, impuesta por la máquina en lugar de por la costumbre. Añade un paso después de que tu build produzca su salida, y cada despliegue entrega assets optimizados, haya pensado alguien en ello o no.

- run: npm run build
- uses: Gheop/patu-action@v1
  with:
    directory: dist
    api-key: ${{ secrets.PATU_KEY }}

En cada push, la acción optimiza lo que el build produjo, antes de que salga. Guarda tu clave como un secreto del repositorio y pásala; no hace falta nada más.

Dos ajustes que vale la pena conocer

Los límites honestos

Optimiza la salida de tu build, que es el conjunto de assets que entregas. Las subidas de usuarios en tiempo de ejecución siguen necesitando algo en la ruta de la petición, no en CI.

Y añade un paso, así que cuesta un poco de tiempo de pipeline. En la práctica es poco, y se ejecuta donde ningún usuario lo está esperando.

La idea

El valor no está en ninguna optimización concreta. Está en que “se nos olvidó comprimir las imágenes” deja de ser algo que puede pasar. El pipeline se ejecuta igual cada vez. La página de integraciones tiene la acción, junto con el CLI y las rutas de WordPress y Vite para cuando tus assets no viven en un build.