Votre JavaScript est-il téléchargé pour rien ?

Pourquoi Google s'intéresse-t-il au JavaScript non exécuté ?

Le problème est simple : beaucoup de sites téléchargent du JavaScript qu'ils n'utilisent jamais. Des bibliothèques entières, des fonctions obsolètes, des modules chargés « au cas où ». Le navigateur doit télécharger, parser et compiler ce code même s'il ne sert à rien.

Résultat : temps de chargement rallongé, consommation de bande passante gaspillée, processeur sollicité pour rien. Sur mobile, avec des connexions limitées, ça pèse lourd. Google l'a bien compris et intègre cette métrique dans PageSpeed Insights pour forcer la prise de conscience.

Comment PageSpeed Insights détecte-t-il ce code inutilisé ?

L'outil s'appuie sur Coverage API de Chrome, qui trace l'exécution réelle du code lors du chargement. Chaque ligne de JavaScript est analysée : exécutée ou non. Si des blocs entiers restent inertes, PageSpeed les remonte comme "unused JavaScript".

La métrique apparaît dans la section "Opportunities" avec une estimation du gain potentiel en temps de chargement. Plus le pourcentage de code non exécuté est élevé, plus l'alerte est sévère.

Quel est l'impact réel sur le référencement ?

Le JavaScript inutilisé ralentit First Contentful Paint (FCP) et Time to Interactive (TTI), deux métriques qui alimentent les Core Web Vitals. Même si l'impact direct sur le classement reste modéré, un site lent dégrade l'expérience utilisateur, augmente le taux de rebond et réduit les conversions.

Google ne va pas pénaliser un site uniquement pour du JS non exécuté, mais c'est un signal indirect : un code mal optimisé traduit souvent une gestion technique approximative. Et ça, Google le capte.

• PageSpeed Insights identifie le JavaScript téléchargé mais jamais exécuté
• Ce code mort ralentit le chargement sans apporter de valeur
• L'outil utilise Coverage API pour tracer l'exécution réelle du code
• Impact sur FCP, TTI et indirectement sur les Core Web Vitals
• Gain potentiel affiché dans la section "Opportunities"

Cette alerte est-elle vraiment nouvelle ?

Non. L'audit "Remove unused JavaScript" existe dans Lighthouse (et donc PageSpeed Insights) depuis plusieurs années. Ce qui change, c'est que Google communique désormais explicitement dessus, signe que le sujet monte en priorité.

Sur le terrain, on observe que beaucoup de sites ignorent cette recommandation, la considérant comme secondaire. Erreur. Les sites qui nettoient leur JS gagnent souvent 20 à 40% de temps de chargement sur mobile.

Le seuil de tolérance de Google est-il connu ?

[A vérifier] Google ne donne aucun chiffre officiel sur le pourcentage acceptable de JavaScript non exécuté. PageSpeed Insights signale le problème dès qu'il détecte un potentiel d'optimisation, mais aucun seuil précis n'est documenté.

D'expérience, on voit des alertes dès 15-20% de code inutilisé. Au-delà de 40%, l'impact devient critique. Mais ces observations sont empiriques, pas officielles.

Tous les frameworks JavaScript sont-ils égaux face à ce problème ?

Non. Les sites utilisant React, Vue ou Angular sans tree-shaking correct se retrouvent souvent avec des bundles énormes dont seule une fraction est utilisée. Les frameworks modernes avec code-splitting (Next.js, Nuxt) s'en sortent mieux.

Les sites WordPress avec 15 plugins qui chargent chacun leur propre bibliothèque jQuery ? Catastrophe. Le problème n'est pas le framework, c'est la discipline (ou son absence) dans la gestion des dépendances.

Comment identifier le JavaScript inutilisé sur mon site ?

Première étape : lancez PageSpeed Insights sur vos pages clés. Descendez jusqu'à la section "Opportunities" et repérez "Remove unused JavaScript". Cliquez pour voir quels fichiers sont concernés et dans quelle proportion.

Deuxième vérification : utilisez l'onglet Coverage dans Chrome DevTools (Cmd+Shift+P > "Show Coverage"). Chargez votre page, interagissez avec, et observez les barres rouges (code non exécuté). Les fichiers avec plus de 50% de rouge sont prioritaires.

Quelles actions concrètes pour réduire ce code mort ?

Commencez par auditer vos dépendances. Listez toutes les bibliothèques JavaScript chargées et demandez-vous : est-elle vraiment nécessaire ? Utilisée sur cette page précise ? Souvent, on découvre des libs obsolètes ou redondantes.

Ensuite, implémentez le code-splitting : ne chargez que le JavaScript nécessaire à chaque page, différez le reste. Webpack, Rollup et Vite offrent des configs pour automatiser ça. Pour les CMS, explorez les plugins de minification intelligente.

Enfin, lazy-loadez les scripts non critiques. Tout ce qui n'est pas indispensable au premier affichage (tracking analytics, widgets sociaux, chat) peut être chargé après l'événement "load" ou au scroll.

Quelles erreurs éviter lors du nettoyage ?

Ne supprimez jamais du code sans tester. Certains scripts semblent inutilisés au chargement mais sont déclenchés par interaction utilisateur (modales, sliders, formulaires). Testez tous les parcours critiques après chaque modification.

Attention aussi aux scripts tiers (Google Ads, Facebook Pixel). Vous ne contrôlez pas leur code. L'optimisation passe par un chargement asynchrone ou différé, pas par la suppression du code interne qu'ils contiennent.

• Auditer PageSpeed Insights et Coverage DevTools
• Lister toutes les dépendances JavaScript et éliminer les redondances
• Implémenter le code-splitting par page ou composant
• Lazy-loader les scripts non critiques (analytics, widgets)
• Tester toutes les fonctionnalités après chaque modification
• Monitorer régulièrement l'évolution de la métrique