Fixer un budget de JavaScript client

Une page peut sembler légère tout en envoyant au navigateur des scripts qui retardent son affichage ou sa réactivité. Pour le catalogue, vous devez fixer une limite vérifiable et empêcher qu’une modification l’augmente sans justification.

Dans les leçons précédentes, vous avez défini les indicateurs et les conditions à conserver pour comparer vos mesures. Le rapport initial de `/randonnees/cretes-du-jura` reste à remplir avec un audit réel : aucune taille de JavaScript ni aucun score ne peut être déduit de cette référence tant que vous ne les avez pas mesurés.

Définir ce que vous comptez

Un budget de JavaScript client est une limite de transfert imposée aux scripts nécessaires sur une route. Pour éviter les comparaisons trompeuses, choisissez une mesure stable : le poids transféré après compression, en kilooctets, des ressources JavaScript de première partie chargées lors d’une navigation à froid. Relevez aussi le total non compressé si votre outil le fournit, mais ne mélangez pas ces deux valeurs.

Pour la première règle du catalogue, posez un plafond provisoire de 150 Ko compressés par route, sur les scripts de première partie. C’est une limite de travail, pas une mesure de l’application ni une garantie de bonne expérience. Après avoir relevé la valeur réelle sur la route de référence, consignez-la ; si elle dépasse déjà le plafond, traitez le dépassement comme une dette à réduire et n’augmentez pas la limite pour le faire disparaître.

Lire le waterfall de la route

Construisez d’abord le projet avec la commande de production définie dans votre projet, puis servez ce build et ouvrez la route dans les outils réseau du navigateur. Activez la désactivation du cache et rechargez la page. Filtrez les ressources JavaScript, vérifiez leur domaine et relevez la colonne de transfert ; additionnez les ressources de première partie effectivement chargées pour cette navigation.

Dans ce waterfall, repérez les scripts associés à Next.js, ceux propres à la route et les éventuels scripts ajoutés par votre application. Ne comptez pas une feuille CSS ou une image comme du JavaScript. Les ressources tierces peuvent être consignées à part : leur poids et leur disponibilité dépendent d’autres services, mais elles peuvent tout de même peser sur l’expérience mesurée.

Appliquer une règle de non-régression

Une règle exploitable combine le plafond et la comparaison avant-après : aucune route contrôlée ne dépasse 150 Ko compressés de JavaScript de première partie, et aucune modification ne doit provoquer une hausse inexpliquée par rapport à sa référence. Si vous constatez une hausse, identifiez les nouveaux scripts ou les ressources dont le poids a changé avant de valider le changement.

Le poids transféré ne suffit pas à décider qu’une modification est acceptable. Comparez les résultats Lighthouse dans les mêmes conditions à votre rapport de référence et appliquez la règle du projet : aucune régression Lighthouse n’est acceptée. Une baisse du volume de scripts ne justifie donc pas une dégradation de la mesure ; inversement, un score stable ne rend pas acceptable le dépassement du budget.

Inscrivez le plafond, la méthode de calcul, le résultat réellement observé et la décision dans la fiche de référence du projet. Ce relevé donne un point de comparaison ; la leçon sur le découpage client montrera ensuite comment limiter les scripts envoyés au navigateur, sans déplacer ici la structure des fichiers ni anticiper cette implémentation.

À retenir

• Fixez un plafond provisoire de 150 Ko compressés de JavaScript de première partie par route ; ne le présentez pas comme une mesure déjà obtenue.
• Relevez le transfert sur un build de production, en navigation à froid et dans des conditions comparables à la référence.
• Consignez les ressources, la méthode et le total réellement observé.
• N’acceptez ni dépassement inexpliqué du budget ni régression Lighthouse.