Pourquoi le JavaScript non utilisé plombe-t-il vos Core Web Vitals même s'il n'est jamais exécuté ?

Pourquoi du code jamais appelé impacte-t-il quand même les performances ?

Le navigateur ne sait pas à l'avance quel JavaScript sera exécuté. Il doit donc télécharger, parser et compiler l'intégralité des fichiers JS servis. Même si une fonction n'est jamais appelée, son code a déjà consommé de la bande passante et du temps processeur.

Ce phénomène est particulièrement visible sur mobile : connexions lentes, processeurs limités. Un fichier de 300 Ko bourré de fonctions inutiles ralentit l'affichage de la page — et dégrade les Core Web Vitals, notamment le FID et le TBT.

La réutilisation de code, c'est quoi concrètement ?

Templates WordPress, thèmes préfabriqués, bundles Webpack mal configurés, librairies importées en totalité alors qu'on n'utilise qu'une poignée de fonctions. C'est le quotidien de la plupart des sites.

Google pointe un problème structurel : la facilité de développement (réutiliser un composant existant) entre en collision frontale avec la performance client. Le code legacy s'accumule, les développeurs ajoutent sans retirer.

Comment PageSpeed Insights détecte-t-il le JavaScript inutilisé ?

L'outil analyse la couverture de code via DevTools : il trace quelles lignes de JS ont été exécutées pendant le chargement et l'interaction initiale. Tout ce qui n'a pas été touché est marqué comme « potentiellement inutilisé ».

Attention au mot « potentiellement » — certains scripts ne s'exécutent que lors d'interactions spécifiques (clic sur un bouton, scroll profond). PSI ne peut pas simuler tous les parcours utilisateur. Mais dans la majorité des cas, le diagnostic est fiable.

• Le navigateur télécharge et parse tout le JS, même ce qui ne sert jamais
• La réutilisation de code (frameworks, templates) introduit mécaniquement du lest
• PageSpeed Insights mesure la couverture de code et identifie les scripts superflus
• Ce gaspillage impacte directement les Core Web Vitals (FID, TBT, LCP indirect)

Cette déclaration est-elle cohérente avec les observations terrain ?

Totalement. On observe régulièrement des sites avec 500 Ko de JS pour afficher… un formulaire de contact. WordPress + builder visuel + plugins mal codés = bundle obèse. Et PageSpeed Insights le mesure sans pitié.

Ce qui est intéressant, c'est que Google officialise enfin un point souvent minimisé par les développeurs : « Oui mais ce code ne s'exécute pas, ça ne coûte rien ». Faux. Le parsing et le téléchargement ont un coût mesurable, et ce coût dégrade l'expérience utilisateur.

Faut-il prendre PageSpeed Insights au pied de la lettre sur ce point ?

Oui, mais avec nuance. L'outil signale du « JavaScript inutilisé », pas forcément « JavaScript à supprimer ». Un script peut être nécessaire après interaction — lazy loading, modal, panier e-commerce.

Le vrai enjeu : séparer ce qui est critique au premier affichage de ce qui peut attendre. Code splitting, dynamic imports, defer/async. Mais ça, PageSpeed Insights ne le dit pas explicitement — il se contente de pointer le problème.

Dans quels cas cette recommandation devient-elle contre-productive ?

Si tu supprimes aveuglément tout ce que PSI marque en rouge, tu risques de casser des fonctionnalités. Un script de tracking, un chatbot, un système de paiement — tout ça peut apparaître comme « inutilisé » si l'outil n'a pas simulé le bon parcours.

L'autre piège : trop fragmenter le code. Multiplier les petits fichiers JS peut générer plus de requêtes HTTP, ce qui dégrade les perfs sur HTTP/1.1 ou en cas de latence réseau élevée. Il faut trouver l'équilibre — et c'est rarement binaire.

Que faut-il faire concrètement pour réduire le JavaScript non utilisé ?

Première étape : mesurer. Ouvre Chrome DevTools > Coverage, recharge la page, interagis normalement. Les barres rouges montrent le code jamais exécuté. Identifie les fichiers les plus lourds avec le moins de couverture.

Ensuite, priorise. Commence par les gros morceaux : frameworks importés en totalité, librairies obsolètes, plugins WordPress désactivés mais dont le JS reste chargé. Ne te perds pas à optimiser 2 Ko quand tu traînes 200 Ko de jQuery UI pour un seul datepicker.

Quelles erreurs éviter dans cette optimisation ?

Ne supprime pas aveuglément. Un script peut être « inutilisé » lors du chargement initial mais indispensable après interaction — formulaire, modal, carrousel. Teste chaque modification en conditions réelles, sur plusieurs parcours utilisateur.

Évite aussi de tomber dans le piège du « tout lazy ». Différer trop de scripts peut créer des décalages visuels (CLS) ou retarder l'interactivité (FID). L'objectif n'est pas d'avoir zéro JS au chargement, mais de charger le strict nécessaire pour le premier affichage.

Comment vérifier que mon site est conforme ?

PageSpeed Insights reste l'outil de référence — utilise-le régulièrement, en mode mobile et desktop. Compare les scores avant/après optimisation, et vérifie que le TBT (Total Blocking Time) diminue effectivement.

En complément : WebPageTest avec un profil mobile réaliste (3G/4G), Chrome User Experience Report pour les données terrain. Si tes Core Web Vitals « field data » ne s'améliorent pas après optimisation, tu as raté une étape.

• Mesurer la couverture de code avec DevTools > Coverage
• Identifier les fichiers JS les plus lourds et les moins utilisés
• Prioriser les optimisations : frameworks, librairies, plugins obsolètes
• Implémenter le code splitting et les dynamic imports pour différer le non-critique
• Tester en conditions réelles sur plusieurs parcours utilisateur
• Valider avec PageSpeed Insights et WebPageTest (mobile 3G/4G)
• Surveiller les Core Web Vitals terrain (CrUX) pour confirmer l'impact réel