Ottimizza i tuoi asset in fase di build, non a ogni richiesta

La maggior parte degli asset di un sito è nota molto prima che si presenti un solo visitatore. L’immagine principale, le icone, il CSS in bundle, i font: vivono nel tuo repository e sono identici da una richiesta alla successiva. Ci sono solo due posti in cui ottimizzarli. Una volta, in fase di build. Oppure di continuo, sull’edge, ogni volta che una pagina si carica.

Per gli asset che consegni tu stesso, la build è il posto migliore.

Perché in fase di build

Fai il lavoro una volta. L’output è piccolo nel momento in cui viene consegnato e resta piccolo, senza CPU per richiesta, senza cache di trasformazione da scaldare, e senza una bolletta di trasformazione al volo che cresce con il tuo traffico.

Il risultato è anche qualcosa che puoi vedere. I file ottimizzati sono lì, nell’output della tua build, quindi puoi confrontarli, pesarli e sapere esattamente cosa esce. Una trasformazione sull’edge è una scatola nera di cui ti fidi; un artefatto di build è un file che puoi aprire.

E copre più delle immagini. La tua build gestisce già JavaScript, CSS, SVG e font, e tutti questi si riducono anch’essi. Un TTF grezzo consegnato al posto di WOFF2 è circa due terzi sprecato da solo.

Dove l’edge merita ancora il suo posto

L’ottimizzazione in fase di build tocca solo gli asset che passano dalla tua build. Due casi hanno davvero bisogno del percorso della richiesta:

• Caricamenti degli utenti. Se le persone caricano immagini mentre il tuo sito è in funzione, non puoi ottimizzarle in fase di build. Serve qualcosa sul percorso della richiesta: un’API, o un plugin per il CMS.
• Cataloghi enormi e vari che richiedono dimensioni per dispositivo. Se servi davvero una dimensione diversa per dispositivo su milioni di immagini, un servizio al volo si ripaga.

Per un sito normale, cioè la maggior parte dei siti, nessuno di questi è il collo di bottiglia, e la build è più semplice e più economica.

Farlo

Due modi, entrambi in esecuzione sull’API Patu così che la codifica avvenga fuori dalla tua macchina.

Un comando, in qualsiasi script di build o job di CI:

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

Percorre la cartella, ottimizza le immagini, l’SVG, il JS, il CSS e i font sul posto, e salta tutto ciò che non riesce davvero a battere. Aggiungi --cdn per caricarli e riscrivere i riferimenti su cdn.patu.dev invece di riscrivere sul disco.

Oppure collegalo a Vite, così che ogni build sia coperto senza che tu ci pensi:

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

Il punto

L’edge non è sbagliato. Ma c’è una buona probabilità che tu stia pagando per trasformare, a ogni singola richiesta, asset che non cambiano mai tra una e l’altra. Ottimizzali una volta, nella build che già esegui, e consegnali piccoli. La pagina delle integrazioni ha il CLI, il plugin per Vite e il resto.