Corriger 'Reduce Unused JavaScript' dans Lighthouse

Qu'est-ce que l'avertissement 'reduce unused JavaScript' de Lighthouse ?

Dernière révision par Arjen Karel en Mars 2026

Lighthouse signale chaque fichier JavaScript contenant plus de 20 Kio de code inutilisé. Si vous voyez cet avertissement, cela signifie que votre page télécharge et exécute du JavaScript dont elle n'a pas besoin pour le chargement de la page actuelle.

Cet avertissement a un impact direct sur votre score de performance Lighthouse. Mais surtout, le JavaScript inutilisé nuit à vos vrais utilisateurs. Selon le Web Almanac 2025, la page mobile médiane distribue 646 Ko de JavaScript, et 251 Ko de cela restent inutilisés sur la page où ils sont chargés. Au 90e centile, ce nombre grimpe à 931 Ko de JavaScript gaspillé.

Pendant ce temps, le Total Blocking Time (temps de blocage total) sur mobile a augmenté de 58 % d'une année sur l'autre pour atteindre une médiane de 1 916 ms selon le chapitre Performance du Web Almanac 2025. Les poids du JavaScript augmentent plus vite que les appareils ne deviennent plus rapides. Sur les sites surveillés par CoreDash, les origines qui maintiennent leur JavaScript inutilisé en dessous de 100 Ko obtiennent un score "bon" (good) sur l'INP 93 % du temps, comparativement à 64 % pour les origines dépassant 400 Ko.

Qu'est-ce qui cause le JavaScript inutilisé ?

Le JavaScript inutilisé peut avoir de nombreuses causes. Les plus courantes sont :

• Trop de plugins dans votre CMS.
• Code mort qui n'est plus utilisé par le site web actuel.
• Scripts mal écrits avec des vérifications et des branches inutiles.
• Accès non restreint au gestionnaire de balises (tag manager), où les équipes marketing ajoutent des balises et oublient de les supprimer.
• Importations inutiles : tirer toute une bibliothèque alors que vous n'utilisez qu'une seule fonction.
• Code qui s'exécute sur chaque page mais n'est nécessaire que sur des routes spécifiques.
• Scripts chargés immédiatement qui auraient pu être chargés juste avant leur utilisation.

Comment le JavaScript inutilisé affecte-t-il les Core Web Vitals ?

Le JavaScript inutilisé nuit à vos performances de deux manières :

• Contention du réseau (Network contention). Chaque fichier JavaScript doit être téléchargé. Ces requêtes sont en concurrence pour la bande passante avec votre image LCP, vos polices et votre CSS. Sur une connexion mobile, ce retard peut repousser votre Largest Contentful Paint bien au-delà du seuil des 2,5 secondes.
• Blocage du fil principal (Main thread blocking). Le navigateur doit analyser (parse), compiler et exécuter tout ce JavaScript. Pendant qu'il le fait, il ne peut pas répondre aux actions de l'utilisateur ou continuer à afficher (render) la page. Cela a un impact direct à la fois sur le LCP et l'INP.

Gardez à l'esprit qu'un score Lighthouse n'est pas un score Core Web Vitals. Les Core Web Vitals sont mesurés avec des données de terrain provenant d'utilisateurs réels (CrUX). Lighthouse est un outil de diagnostic qui vous aide à trouver des problèmes, mais vos performances réelles sont ce que vos visiteurs vivent réellement. Vous pouvez vérifier vos performances sur le terrain avec le Real User Monitoring.

Comment trouver le JavaScript inutilisé

Il y a trois façons d'identifier le JavaScript inutilisé sur votre page :

1. Lire l'audit Lighthouse

Lighthouse répertorie chaque fichier JavaScript contenant plus de 20 Kio de code inutilisé. Il montre le nombre total d'octets, les octets inutilisés et les économies potentielles. C'est votre point de départ. Notez que Lighthouse 13 (octobre 2025) est passé à un format d'audit basé sur des insights, mais la vérification du JavaScript inutilisé est toujours là.

2. Utiliser l'outil Coverage de Chrome

L'outil Coverage (Couverture) vous donne une répartition ligne par ligne du code utilisé par rapport au code inutilisé pour chaque fichier JavaScript et CSS de la page.

Ouvrez Chrome DevTools avec Ctrl+Shift+I (ou Cmd+Option+I sur Mac). Ensuite, utilisez Ctrl+Shift+P pour ouvrir le menu de commande et tapez coverage. Sélectionnez Show Coverage, puis cliquez sur le bouton de rechargement pour démarrer l'instrumentation. Une fois la page chargée, vous verrez chaque fichier avec son pourcentage d'octets inutilisés.

Passez au mode de couverture "Per block" (menu déroulant en haut du panneau) pour des résultats plus granulaires. La couverture au niveau du bloc détecte les branches inutilisées au sein des fonctions, et pas seulement si une fonction a été appelée ou non.

Cliquez sur n'importe quelle ligne pour ouvrir le fichier dans le panneau Sources. Les lignes bleues correspondent au code utilisé. Les lignes rouges sont inutilisées. Cela vous indique exactement quelles fonctions et branches n'ont jamais été exécutées lors du chargement de la page.

3. Analyser vos bundles

Si vous utilisez un bundler comme webpack, Rollup ou Vite, utilisez un analyseur de bundle pour visualiser ce qui se trouve à l'intérieur de vos fichiers JavaScript. Des outils comme webpack-bundle-analyzer et source-map-explorer montrent une arborescence (treemap) de chaque module dans votre bundle, ce qui met en évidence lorsqu'une grande bibliothèque est importée pour une petite fonctionnalité.

Inutilisé ne signifie pas toujours inutile

Gardez à l'esprit qu'"inutilisé" (unused) sur une page ne signifie pas "inutile" (unneeded). Un script qui alimente votre formulaire de paiement s'affiche comme 100 % inutilisé sur votre page d'accueil. Cela ne veut pas dire que vous devez le supprimer. Cela signifie que vous ne devriez pas le charger sur la page d'accueil.

C'est ce que résout le code splitting (fractionnement de code) : chaque route ne charge que le JavaScript dont elle a réellement besoin. Si vous voyez de grandes quantités de JavaScript "inutilisé" et que votre site est une application monopage (SPA), la solution est presque toujours un meilleur code splitting au niveau de la route, et non la suppression de code.

Comment résoudre 'reduce unused JavaScript'

Pour corriger l'avertissement 'reduce unused JavaScript', vous devez d'abord remonter à la source du gaspillage. Lighthouse vous indique quels scripts ont une grande quantité d'octets inutilisés. Voici 7 façons de le réduire :

1. Supprimer les plugins inutiles. Si vous utilisez un CMS comme WordPress, la victoire la plus facile est de supprimer les plugins dont vous n'avez pas besoin ou de remplacer des plugins triviaux par quelques lignes de code. Votre plugin d'analyse (analytics), les boutons de partage social et le widget de chat sont des coupables fréquents.
2. Supprimer le code mort. Le code mort (dead code) est du code que le site web actuel n'utilise plus. Planifiez un audit de code mort au moins deux fois par an. Des outils comme Knip peuvent automatiser la détection des exports et dépendances inutilisés dans les projets JavaScript.
3. Tree shaker vos bundles. Le tree shaking supprime les exportations inutilisées lors du processus de build. Pour que cela fonctionne, vous avez besoin de la syntaxe de module ES (import/export), et non de CommonJS (require). Ajoutez "sideEffects": false à votre package.json pour que votre bundler puisse supprimer de manière agressive le code inutilisé. N'importez que ce dont vous avez besoin :

   // Mauvais : importe toute la bibliothèque (70+ Ko)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Bon : importe seulement debounce (~1 Ko avec tree shaking)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. Code splitting de vos routes. Ne chargez que le JavaScript dont chaque page a réellement besoin. Utilisez import() dynamique pour diviser vos bundles par route ou par fonctionnalité :

   // Au lieu de tout importer au début :
   import { validateForm } from './formValidation.js';
   
   // Le charger seulement quand l'utilisateur interagit avec le formulaire :
   document.querySelector('form').addEventListener('focus', async () => {
     const { validateForm } = await import('./formValidation.js');
     validateForm();
   }, { once: true });

   Dans React, utilisez React.lazy() avec <Suspense> pour le fractionnement au niveau des composants. Dans le App Router de Next.js, les React Server Components n'envoient aucun JavaScript au client par défaut. Dans Vue, utilisez defineAsyncComponent() ou les importations dynamiques dans Vue Router.

5. Nettoyer votre tag manager et en restreindre l'accès. Le gestionnaire de balises est une source fréquente de code inutilisé, en particulier lorsque les équipes marketing ajoutent des balises sans supprimer les anciennes. Auditez régulièrement votre conteneur de tag manager. Chaque balise qui se déclenche au chargement de la page ajoute du JavaScript qui entre en concurrence pour les ressources.
6. Supprimer les importations inutiles. Dans les projets React, Vue et Next.js, vérifiez vos instructions d'importation. Importez-vous toute une bibliothèque de composants alors que vous n'utilisez que deux composants ? Importez-vous moment.js (330 Ko) alors que l'API Intl native ou une alternative de 2 Ko comme dayjs suffirait ?
7. Différer le chargement des scripts non critiques. Parfois, vous avez besoin d'un script (pour soumettre un formulaire, par exemple) mais vous n'en avez pas besoin pendant le chargement de la page. Chargez-le lorsque l'utilisateur en a réellement besoin. Un script qui se charge lors d'une interaction au lieu de se charger avec la page n'est plus du "JavaScript inutilisé" dans l'audit Lighthouse. Voir aussi async vs defer pour comprendre la différence entre les deux stratégies de chargement.

Lorsque vous ne pouvez pas le résoudre complètement

Parfois, vous ne pouvez pas supprimer tout le JavaScript inutilisé. Les scripts tiers, les outils de test A/B et les réseaux publicitaires livrent souvent de gros bundles sur lesquels vous n'avez aucun contrôle. Dans ce cas, minimisez leur impact :

• Auto-hébergez (Self-host) les scripts tiers sur votre domaine principal dans la mesure du possible. Cela évite le coût d'une nouvelle recherche DNS et d'une connexion TCP pour chaque domaine externe.
• Priorisez les ressources critiques. Préchargez (preload) votre image LCP et les polices critiques afin qu'elles ne soient pas coincées derrière les téléchargements JavaScript dans la file d'attente du réseau.
• Différez autant de JavaScript que possible. Retirez les scripts non critiques du chemin de rendu critique (critical rendering path) en utilisant defer, async, ou un chargement retardé.
• Utilisez fetchpriority="low" sur les ressources de script non essentielles pour indiquer au navigateur qu'elles peuvent attendre.
• Surveillez vos données de terrain (field data). Utilisez le Real User Monitoring pour vérifier que vos modifications ont réellement amélioré l'expérience des vrais utilisateurs, et pas seulement le score Lighthouse.