Patu

Faites de l'optimisation des assets une étape de CI, pas quelque chose dont on se souvient

L’optimisation des assets marche parfaitement jusqu’à ce que quelqu’un oublie. Un PNG d’en-tête de 3 Mo est committé, le build passe, le déploiement part, et personne ne remarque rien jusqu’à ce qu’un score de performance s’effondre une semaine plus tard. Puis quelqu’un l’optimise à la main, et le compte à rebours repart sur la prochaine personne qui oubliera.

Compter sur les gens pour s’en souvenir n’est pas une stratégie. Déplacez-la là où l’oubli est impossible.

Mettez-la dans le pipeline

L’optimisation a sa place à côté de vos tests et de votre build : automatique, à chaque push, imposée par la machine plutôt que par l’habitude. Ajoutez une étape après que votre build a produit sa sortie, et chaque déploiement livre des assets optimisés, que quelqu’un y ait pensé ou non.

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

À chaque push, l’action optimise ce que le build a produit, avant la livraison. Stockez votre clé comme secret de dépôt et passez-la ; rien d’autre n’est requis.

Deux réglages à connaître

Les limites honnêtes

Elle optimise votre sortie de build, c’est-à-dire l’ensemble des assets que vous livrez. Les envois d’utilisateurs à l’exécution ont toujours besoin de quelque chose sur le chemin de requête, pas dans la CI.

Et elle ajoute une étape, elle coûte donc un peu de temps de pipeline. En pratique c’est faible, et ça tourne là où aucun utilisateur ne l’attend.

L’essentiel

La valeur n’est pas dans une optimisation en particulier. C’est que « on a oublié de compresser les images » cesse d’être une chose qui peut arriver. Le pipeline tourne de la même façon à chaque fois. La page intégrations a l’action, ainsi que le CLI et les chemins WordPress et Vite pour quand vos assets ne vivent pas dans un build.