Patu

Rendi l'ottimizzazione degli asset un passo di CI, non qualcosa che ti ricordi

L’ottimizzazione degli asset funziona benissimo finché qualcuno non dimentica. Un PNG principale da 3 MB viene committato, la build passa, il deploy parte, e nessuno se ne accorge finché un punteggio di prestazioni non crolla una settimana dopo. Poi qualcuno lo ottimizza a mano, e il conto alla rovescia ricomincia sulla prossima persona che dimenticherà.

Contare sul fatto che le persone si ricordino non è una strategia. Spostala dove dimenticare è impossibile.

Mettila nella pipeline

L’ottimizzazione va accanto ai tuoi test e alla tua build: automatica, a ogni push, imposta dalla macchina invece che dall’abitudine. Aggiungi un passo dopo che la tua build ha prodotto il suo output, e ogni deploy consegna asset ottimizzati, che qualcuno ci abbia pensato o no.

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

A ogni push, l’action ottimizza ciò che la build ha prodotto, prima che parta. Conserva la tua chiave come secret del repository e passala; non serve altro.

Due manopole che vale la pena conoscere

I limiti onesti

Ottimizza l’output della tua build, cioè l’insieme di asset che consegni. I caricamenti degli utenti a runtime hanno ancora bisogno di qualcosa sul percorso della richiesta, non nella CI.

E aggiunge un passo, quindi costa un po’ di tempo di pipeline. In pratica è poco, e gira dove nessun utente lo sta aspettando.

Il punto

Il valore non sta in una singola ottimizzazione. Sta nel fatto che “ci siamo dimenticati di comprimere le immagini” smette di essere una cosa che può capitare. La pipeline gira allo stesso modo ogni volta. La pagina delle integrazioni ha l’action, insieme al CLI e ai percorsi WordPress e Vite per quando i tuoi asset non vivono in una build.