Juste après avoir déployé en production la première tranche du travail d'internationalisation, un test Lighthouse est revenu avec Performance : 89 — en dessous du seuil de règle stricte ≥90 fixé par ce projet lui-même, et une vraie baisse par rapport à la référence de 93/100/99 mesurée le même jour, avant ce déploiement.
Le réflexe évident est de supposer que le nouveau code a causé une régression et de commencer à tout annuler. Je ne l'ai pas fait, et la raison est la partie la plus utile de cette histoire.
Lire le rapport plutôt que réagir au chiffre
Un seul score Lighthouse représente les données d'une seule requête HTTP, sur un seul démarrage à froid (cold start) serverless, à un instant donné. Avant de traiter 89 comme un verdict, j'ai ouvert le rapport réel et regardé ce qui faisait baisser le score plutôt que le seul chiffre affiché.
L'audit server-response-time montrait un TTFB (délai jusqu'au premier
octet) du document racine de 1 150 ms — environ 15 à 20 fois la valeur
de chaque test précédent de cette même page. Ce seul chiffre s'est répercuté
sur le speed-index, qui est tombé à 12,7 s (score 0,03), parce que rien
sur la page ne peut s'afficher avant que le document lui-même n'arrive.
Note
1 150 ms de pur délai jusqu'au premier octet, avec chaque autre métrique expliquée par ce seul chiffre, ne ressemble pas à une régression de rendu causée par du nouveau code. Ça ressemble au serveur ayant mis un temps inhabituel à répondre à cette seule requête — ce qui, sur une plateforme serverless, correspond à un démarrage à froid.
Tester l'hypothèse plutôt que la supposer vraie
Une hypothèse n'est pas une conclusion. J'ai relancé Lighthouse contre la production deux fois de plus, à quelques minutes d'intervalle :
- Test 2 : 94/100/100/100 —
server-response-timerevenu à environ 70 ms, correspondant presque exactement à la référence d'avant déploiement.speed-indexrevenu à 1,4 s (score 1). - Test 3 : cohérent avec le test 2.
Le chunk JS de 72 Ko que les audits bootup-time/mainthread-work-breakdown
de Lighthouse signalent à chaque test de ce site — une dette technique
préexistante et déjà suivie, sans lien avec ce déploiement — était identique
octet pour octet entre le rapport à 89 et celui à 94. Si le nouveau code
avait réellement causé une régression, ce chunk (ou un nouveau) aurait dû
différer entre les deux tests. Ce n'était pas le cas.
Decision
Aucun retour en arrière. Les preuves indiquaient un pic ponctuel de démarrage à froid sur une plateforme serverless, pas une régression durable causée par le déploiement — et les mesures répétées l'ont confirmé plutôt que de simplement l'affirmer. Annuler sur la base d'une seule donnée aurait jeté du vrai travail déjà livré pour « corriger » un problème que les deuxième et troisième tests ont montré comme inexistant.
Ce que je ferais différemment
Rien dans l'investigation elle-même — lire les audits sous-jacents plutôt que le chiffre affiché, puis re-mesurer plutôt que supposer, est exactement ce qui a permis de bien diagnostiquer la situation. Si je devais changer quelque chose, ce serait d'intégrer la mesure répétée dans la vérification standard post-déploiement dès le départ, plutôt que de n'y recourir qu'après un premier chiffre inquiétant.