Aller au contenu
La performance comme incidentLecture : 0 %

La performance comme incident

Quels budgets de performance tiennent en CI et lesquels deviennent du bruit, comment traiter une régression de terrain avec les mêmes règles qu'une panne, et à partir de quel trafic ce dispositif a un sens.

Par Elias Varen8 min de lectureMembres

Quand l'API renvoie des erreurs 500, quelqu'un est réveillé, le déploiement est annulé, et un compte rendu est écrit le lendemain. Quand le LCP de la page d'inscription passe de 1,8 à 3,1 secondes, il ne se passe rien. Personne n'est alerté, le déploiement reste en place, et la régression est découverte six semaines plus tard, mélangée à quarante autres changements, par quelqu'un qui regardait autre chose.

La performance front se dégrade rarement par un changement spectaculaire. Elle se dégrade par accumulation : une dépendance de 12 Ko ici, un composant client de plus là, une police ajoutée par le marketing. Chaque changement est raisonnable et passe la revue. Un système qui ne se dégrade que par petits pas raisonnables ne se défend pas avec de la vigilance ; il lui faut un cliquet, un mécanisme qui refuse le pas ou qui le fait remonter à quelqu'un dont c'est le travail de dire non.

Ce cliquet a deux étages. La CI attrape ce qui est déterministe, et le terrain attrape le reste, qu'il faut alors traiter comme une panne.

En CI, les octets bloquent et les temps commentent

Tout dépend du bruit de la mesure.

MesureBruitBloquer le merge ?
JavaScript client par route, compresséNulOui
Poids des images et polices critiquesNulOui
Nombre de requêtes et de domaines au chargementFaibleOui
Temps de blocage total, LCP en laboratoireFort sur un runner partagéNon : commentaire
INPNon mesurable sans interaction scénariséeNon

Les octets sont déterministes, puisque le même commit donne le même résultat à l'octet près. Un contrôle déterministe peut bloquer, parce que lorsqu'il échoue, il a raison.

La performance comme incident · Deepstack