Optimisez vos assets au build, pas à chaque requête

La plupart des assets d’un site sont connus bien avant qu’un seul visiteur n’arrive. L’image d’en-tête, les icônes, le CSS bundlé, les polices : ils vivent dans votre dépôt, et ils sont identiques d’une requête à l’autre. Il n’y a que deux endroits pour les optimiser. Une fois, au build. Ou encore et encore, en périphérie, à chaque chargement de page.

Pour les assets que vous livrez vous-même, le build est le meilleur endroit.

Pourquoi au build

Vous faites le travail une fois. La sortie est légère dès sa livraison et le reste, sans CPU par requête, sans cache de transformation à préchauffer, et sans facture de transformation à la volée qui gonfle avec votre trafic.

Le résultat est aussi quelque chose que vous pouvez voir. Les fichiers optimisés sont là, dans votre sortie de build, vous pouvez donc les comparer, les peser, et savoir exactement ce qui part. Une transformation en périphérie est une boîte noire à laquelle vous faites confiance ; un artefact de build est un fichier que vous pouvez ouvrir.

Et ça couvre plus que les images. Votre build gère déjà JavaScript, CSS, SVG et polices, et tout ça s’allège aussi. Un TTF brut livré à la place d’un WOFF2, c’est environ deux tiers de gaspillé à lui seul.

Là où la périphérie garde sa place

L’optimisation au build ne touche que les assets qui passent par votre build. Deux cas ont vraiment besoin du chemin de requête :

• Les envois d’utilisateurs. Si des gens envoient des images pendant que votre site tourne, vous ne pouvez pas les optimiser au build. Ça demande quelque chose sur le chemin de requête : une API, ou un plugin de CMS.
• Les catalogues énormes et variés qui demandent un dimensionnement par appareil. Si vous servez vraiment une taille différente par appareil sur des millions d’images, un service à la volée se rentabilise.

Pour un site normal, ce qui est le cas de la plupart des sites, aucun de ces deux cas n’est le goulot d’étranglement, et le build est plus simple et moins cher.

Le faire

Deux façons, toutes deux tournant sur l’API Patu pour que l’encodage se fasse en dehors de votre machine.

Une seule commande, dans n’importe quel script de build ou job de CI :

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

Elle parcourt le dossier, optimise les images, le SVG, le JS, le CSS et les polices sur place, et ignore tout ce qu’elle ne peut pas réellement battre. Ajoutez --cdn pour les uploader et réécrire les références vers cdn.patu.dev au lieu de réécrire sur le disque.

Ou branchez-la dans Vite, pour que chaque build soit couvert sans que vous y pensiez :

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

L’essentiel

La périphérie n’est pas une erreur. Mais il y a de bonnes chances que vous payiez pour transformer, à chaque requête, des assets qui ne changent jamais entre elles. Optimisez-les une fois, dans le build que vous lancez déjà, et livrez-les légers. La page intégrations a le CLI, le plugin Vite, et le reste.