Réduire le JavaScript inutilisé : Améliorer PageSpeed & l’UX

Vous êtes en train de travailler sur votre site, fier de chaque bouton animé, quand soudain un outil d’audit comme PageSpeed Insights vient ruiner votre journée avec une phrase brutale : JavaScript inutilisé détecté. Votre score de performance s’effondre et vous vous demandez qui a laissé ce foutoir dans votre projet.

• Comprendre pourquoi un surplus de JavaScript ralentit un site et nuit à l’expérience utilisateur, afin de savoir où concentrer vos efforts d’optimisation.
• Identifier facilement le JavaScript inutile grâce à des outils accessibles, pour repérer en quelques minutes les scripts qui plombent vos performances.
• Adopter des techniques simples et durables pour ne charger que le code nécessaire, et rendre votre site plus rapide, plus agréable et mieux référencé.

La vérité, c’est que nous sommes nombreux à charger des kilos de scripts pour n’en utiliser que quelques grammes. Ce phénomène, invisible au premier coup d’œil, ralentit énormément les sites web, fait fuir les visiteurs impatients et pénalise le référencement. Pourtant, la plupart des développeurs ne réalisent même pas qu’ils embarquent du JavaScript superflu. On code, on installe des bibliothèques, on copie des scripts trouvés sur le Net… et on ne revient jamais faire le ménage.

Ce chapitre est là pour démystifier tout ça. Ensemble, nous allons découvrir ce qu’est réellement le JavaScript inutilisé, pourquoi il plombe vos performances, comment l’identifier facilement et surtout comment réduire le JavaScript de manière concrète et progressive. Même si vous débutez, vous allez voir que l’on peut faire de la magie, sans être un gourou de l’optimisation.

C’est quoi le JavaScript inutilisé ?

Le JavaScript inutilisé correspond à tout le code JavaScript chargé par la page mais qui ne sert à rien au moment où cette page est affichée. Le navigateur télécharge ces scripts, les analyse, les exécute parfois en partie… juste pour les garder au chaud, dans l’éventualité que vous en ayez besoin plus tard. Un peu comme si vous demandiez une petite salade au restaurant et que l’on vous servait un buffet complet, entrée, fromage, dessert, plat végétarien, vins compris… sous prétexte que “on ne sait jamais”.

Cette notion englobe plusieurs réalités. Il peut s’agir de fonctions que vous avez codées mais que vous n’utilisez plus. Cela peut être un module entier d’une bibliothèque externe dont vous n’affichez que le bouton Like. Ou bien un script prévu pour une autre page mais chargé partout par facilité.

Par exemple, ajouter jQuery UI juste pour avoir un seul effet d’apparition sur un formulaire : téléchargement de 250 Ko pour une animation de 0,5 seconde. Résultat, votre site mettra une éternité à charger sur un vieux téléphone… La violence du JavaScript inutilisé.

Pourquoi réduire le JavaScript inutilisé change tout

Vous vous demandez peut-être pourquoi ce sujet est si important. Après tout, vos scripts fonctionnent, votre site s’affiche… quel est le problème ?

Le problème vient du parcours que chaque script impose au navigateur. Quand une page se charge, le navigateur doit :

1. Télécharger le script
2. Le décompresser (s’il est minifié ou compressé en gzip/brotli)
3. Le parser (analyse syntaxique du code)
4. Le compiler
5. Potentiellement l’exécuter

Même si votre fonction reste sagement dans son fichier sans jamais être appelée, tout ce processus se produit quand même. Cela prend du temps, consomme de la mémoire, bloque le rendu visuel et agace les utilisateurs qui attendent leur contenu.

Réduire le JavaScript, c’est donc réduire :

• Le temps de chargement initial, notamment sur mobile avec un réseau modeste
• Le temps jusqu’à l’interaction (TTI), c’est-à-dire le moment où l’utilisateur peut enfin cliquer
• La consommation d’énergie, donc l’autonomie du téléphone
• La quantité de données consommées sur les petits forfaits

Google n’hésite pas : il pénalise les sites trop lourds en JavaScript. Autrement dit, réduire le JavaScript inutilisé aide directement votre SEO.

Comment détecter le JavaScript inutilisé

Bonne nouvelle : vous n’avez pas besoin d’être dev senior pour trouver les coupables. Vous pouvez utiliser trois outils gratuits et simples :

1. Google Lighthouse ou PageSpeed Insights

Vous les connaissez peut-être déjà. Ils affichent un rapport détaillé avec une section “Réduire le JavaScript inutilisé”. Vous y verrez :

• Les fichiers JavaScript concernés
• Le pourcentage de code réellement utilisé
• Le poids économisable

Exemple d’analyse simplifiée : Un fichier script.js de 200 Ko, dont seulement 30 Ko sont utilisés sur la page. Ce qui signifie 170 Ko totalement inutiles à ce moment-là

Cela fait réfléchir, n’est-ce pas ?

2. Chrome DevTools : l’onglet Coverage

Ouvrez votre page depuis Google Chrome, puis DevTools, onglet Coverage. Rechargez. Une liste des fichiers JS apparaît avec deux couleurs :

• Couleur utilisée : portion de code exécutée
• Couleur inutilisée : portion totalement ignorée

Cet outil est parfait pour trouver les fonctionnalités dormantes.

3. Les messages de Performance en console

Votre navigateur peut afficher des warnings du type “Long main thread execution”. C’est souvent un signe que des scripts trop lourds sont analysés pour rien.

Les causes les plus courantes de JavaScript inutile

Pour bien réduire le JavaScript inutilisé, il faut comprendre d’où il vient. Plusieurs erreurs classiques en sont à l’origine :

Les bibliothèques trop lourdes

• Un slider complet pour afficher une seule image
• Une lib d’animations pour trois petits effets
• Importer un framework complet pour un bouton dynamique (jQuery, ..)

Vous voyez sûrement de quelles habitudes je parle.

Le JavaScript utilisé sur d’autres pages uniquement

• Un script de formulaire d’inscription sur la page d’accueil…
• Un script de panier e-commerce sur la page “À propos”…

C’est souvent par simplification : on inclut un header global contenant plein de scripts, et il se retrouve chargé partout.

Le JavaScript mis à la poubelle mais pas supprimé

On refactorise, on remplace une feature… mais on oublie d’enlever les fonctions anciennes dans le fichier.

Le JavaScript chargé trop tôt

Certains scripts ne devraient pas bloquer le rendu initial. On les charge pourtant au tout début de la page.

Ce chapitre vous permet de commencer à repérer vos propres erreurs, sans même ouvrir un outil d’analyse.

Commencer à réduire le JavaScript inutilisé

Maintenant que l’on comprend le problème, parlons solutions. La réduction du JavaScript inutilisé peut se faire progressivement. Une première approche consiste à se demander pour chaque script :

Ce code est-il réellement nécessaire sur cette page et dès le chargement ?

L’objectif n’est pas d’utiliser un marteau-piqueur tout de suite. On commence par un simple ménage de printemps.

Exemple concret : scripts chargés partout

Vous avez un site WordPress, vous installez une extension de formulaires. On dirait que le plugin charge un énorme fichier JavaScript sur toutes les pages du site. Pourtant, le formulaire n’est présent que dans une seule page : “Contact”.

Dans ce cas, la bonne pratique consiste à conditionner le chargement du script uniquement lorsque la page Contact est ouverte. Un simple contrôle dans votre thème WordPress et hop, ce JavaScript superflu disparaît du reste du site.

Autre exemple : animations non essentielles

Si votre page met 4 secondes à afficher juste à cause d’une animation dans le footer… peut-être que cette animation n’est pas la priorité absolue. Il existe des techniques pour la charger après le rendu principal, ce que nous aborderons dans la suite du guide.

Charger uniquement ce qui est utile, au bon moment

Vous avez probablement déjà entendu parler de lazy-loading pour les images. Eh bien, il existe exactement le même principe pour les scripts. Au lieu de tout charger dès l’ouverture de la page, on peut décider de ne récupérer le JavaScript qu’au moment où l’utilisateur en a réellement besoin.

C’est une manière très efficace de réduire le JavaScript inutile sur la phase critique de chargement.

Technique 1 : Defer et Async

Si un script n’est pas indispensable pour afficher le contenu principal, vous pouvez obtenir un énorme gain de performance simplement en remplaçant ceci :

<script src="app.js"></script>

Par :

<script src="app.js" defer></script>

ou :

<script src="app.js" async></script>

La différence ?

• Defer : le script est téléchargé en parallèle et exécuté après le rendu HTML
• Async : téléchargé en parallèle et exécuté dès qu’il est prêt, même si le rendu HTML n’est pas terminé

Pour les scripts qui ne modifient pas immédiatement le HTML au-dessus de la ligne de flottaison, Defer est souvent idéal.

Exemple réel

Votre menu mobile ne s’affiche qu’une fois que l’utilisateur clique sur l’icône. Il n’a aucune raison de bloquer la mise en page initiale.

Le simple ajout de defer permet de réduire le temps d’affichage du contenu visible. On ne supprime pas du JavaScript, mais on supprime son impact.

Le code-splitting, ou l’art de découper pour alléger

Imaginez une valise énorme contenant tous les vêtements nécessaires pour un voyage de six mois… alors que vous ne partez que deux jours. Vous gaspillez du temps et de l’énergie pour transporter des kilos inutiles. Le code-splitting fonctionne comme une valise optimisée : on ne prend que ce qu’il faut, quand il le faut.

Exemple concret

Vous avez un site avec trois pages : Accueil, Contact, Boutique. Et vous avez un seul gros fichier main.js de 500 Ko qui gère toutes les fonctionnalités.

Grâce au code-splitting, vous découpez votre code en plusieurs fichiers :

• accueil.js (150 Ko)
• contact.js (50 Ko)
• boutique.js (300 Ko)

Chaque page charge seulement ce qui lui est utile. Le JavaScript inutilisé disparaît.

Avec Webpack ou Vite

Ces outils permettent de créer automatiquement des chunks (morceaux) du script. Par exemple en Webpack, avec le dynamic import :

if (page === 'contact') {
  import('./contact.js').then(module => {
    module.initContactForm()
  })
}

Le JavaScript du formulaire Contact ne sera téléchargé que sur la page Contact. Vous venez de réduire le JavaScript inutilisé sans changer une seule fonctionnalité.

Remplacer les grosses bibliothèques par du JavaScript natif

C’est probablement la méthode la plus rentable. Beaucoup de développeurs installent encore des bibliothèques énormes pour une seule petite fonctionnalité.

• Créer un élément dynamique
• Ajouter une classe
• Faire un fetch AJAX
• Afficher une modal simple

Toutes ces actions sont aujourd’hui faciles en JavaScript natif. Et ça évite 200 Ko de jQuery juste pour trois lignes de code.

Exemple avant / après

Avant :

$('#bouton').on('click', function () {
  $('#menu').toggleClass('open')
})

Après :

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

document.getElementById('bouton').addEventListener('click', () => {
  document.getElementById('menu').classList.toggle('open')
})

0 dépendance, plus rapide, plus léger.

Même chose pour les sliders : 90 % du temps, vous pouvez utiliser scroll-snap, overflow-x et un peu de CSS plutôt que des plugins lourds.

Et si vraiment vous avez besoin d’une librairie, pensez à des alternatives ultra-légères comme Swiper ou Splide, plutôt que des mastodontes chargés avec des dizaines de modules inutilisés.

Supprimer ce qui ne sert plus à rien

Cela paraît évident… mais tellement de projets traînent du code fantôme.

• Fonction utilisée il y a deux ans
• Recherche et debug temporaires jamais retirés
• Animation abandonnée
• Fichiers liés à des phases de tests

Vous pouvez faire un audit manuel :

• Ouvrez chaque fichier JavaScript
• Recherchez les fonctions jamais appelées
• Encore mieux : regardez l’onglet Coverage

Quand vous verrez 90 % d’un fichier inutilisé, cela vous motivera à le supprimer sans regret.

Petit conseil

Dès que vous déplacez une fonctionnalité dans un autre fichier, supprimez l’ancien. Ne “laissez pas au cas où”. Ce “cas où” n’arrive jamais et vous portez un boulet invisible à chaque chargement.

Compresser et minifier correctement

On parle souvent de Gzip ou Brotli, mais encore aujourd’hui de nombreux sites envoient du JavaScript brut, sans minification ni compression. Ce n’est pas vraiment du JavaScript inutilisé d’un point de vue fonctionnel… mais c’est une surcharge inutile en termes de poids.

Minifier consiste à retirer les espaces, renommer les variables inutiles, supprimer les commentaires. Vous pouvez gagner 30 à 70 % de taille gratuitement.

Et si votre serveur ou CDN active Brotli, les fichiers peuvent encore perdre 20 à 25 %.

Moins de poids = moins de temps perdu.

Charger certains scripts uniquement après interaction

Il existe une autre astuce : ne charger un script qu’après que l’utilisateur ait déclenché une action.

Exemple : votre page possède une vidéo YouTube dans un onglet caché. Inutile de charger l’API YouTube au début.

Technique :

document.getElementById('onglet-video').addEventListener('click', () => {
  const script = document.createElement('script');
  script.src = 'https://www.youtube.com/iframe_api';
  document.body.appendChild(script);
});

Résultat : 0 JavaScript à charger avant l’interaction. Vous avez réduit le JavaScript inutile d’un seul geste, et Google adorera ça.

Cas particulier : WordPress

WordPress est fantastique, mais certains plugins peuvent ruiner vos performances. Ils chargent leurs scripts partout, même quand le module n’est pas utilisé.

Solution simple dans functions.php

Vous pouvez déclencher conditionnellement l’extension JS d’un formulaire uniquement sur la page Contact :

function charger_scripts_contact() {
  if (is_page('contact')) {
    wp_enqueue_script('form-js');
  }
}
add_action('wp_enqueue_scripts', 'charger_scripts_contact');

C’est une bonne pratique universelle : on ne charge que ce qui est nécessaire sur la page.

Et maintenant ?

Nous avons déjà pratiquement éliminé une énorme partie du JavaScript inutilisé. Mais il reste deux sujets essentiels :

• Auditer régulièrement le code
• Mettre en place une stratégie sur tout le projet

Mettre en place une vraie stratégie sur le long terme

Réduire le JavaScript inutilisé n’est pas un “coup de chiffon” que l’on fait une fois puis que l’on oublie. C’est un processus d’amélioration continue, à intégrer dans votre manière de développer.

Quand vous ajoutez une fonctionnalité, posez-vous systématiquement trois questions :

• Ce code sera-t-il utilisé sur toutes les pages ou seulement sur une partie du site
• Doit-il être exécuté immédiatement ou peut-on attendre l’interaction
• Existe-t-il une version plus légère ou native de ce que je m’apprête à intégrer

En adoptant ces réflexes, vous évitez l’accumulation invisible de JavaScript inutilisé. Et vous gardez un site agréable à utiliser.

Il est également très utile de documenter ces décisions. Par exemple, noter dans votre README ou dans les commentaires du code : “Ce script ne doit être chargé que sur la page X”, ou encore “Cette fonctionnalité peut être lazy-loadée”. Vous gagnerez un temps fou lors des futures évolutions du projet.

Faire des audits réguliers

Les projets évoluent, les besoins changent, et parfois on oublie de nettoyer une fonctionnalité abandonnée. L’audit régulier est donc indispensable.

Un audit basique tous les trimestres suffit largement :

• Vous ouvrez PageSpeed Insights
• Vous regardez la section Réduire le JavaScript inutilisé
• Vous traquez les fichiers suspects
• Vous passez un petit coup de Coverage dans Chrome DevTools

Cinq minutes peuvent suffire pour détecter des dizaines de Ko inutiles à supprimer ou à lazy-loader.

Si vous travaillez en équipe, vous pouvez même en faire un rituel : après chaque sprint, un développeur fait une passe d’optimisation. Cela évite de se retrouver, six mois plus tard, avec un site qui met dix secondes à charger sur téléphone.

Et croyez-moi, il c’est gratifiant de voir son score Lighthouse passer de 50 à 90 juste en ayant retiré trois scripts cachés dans un coin.

Exemple d’un cas réel avant / après

Prenons un cas simple rencontré régulièrement sur un site vitrine :

• Page d’accueil avec un slider
• Formulaire de contact présent uniquement sur la page Contact
• Une carte Google Maps affichée dans le pied de page, mais visible uniquement après un clic

Avant optimisation :

• Un seul fichier main.js de 450 Ko chargé partout
• L’API Google Maps chargée dès le départ
• Le script du formulaire chargé même quand il n’y a aucun formulaire

Résultat : un TTI de 4,5 secondes sur un smartphone milieu de gamme

Après optimisation :

• Code-splitting : accueil.js (180 Ko), contact.js (70 Ko), map.js (40 Ko)
• L’API Google Maps chargée uniquement au clic sur le bouton “Afficher la carte”
• Le script du formulaire chargé seulement sur la page Contact

Résultat : TTI de 1,8 seconde. Gain total : 250 Ko en moins au chargement initial et une page visuellement prête deux fois plus vite

Ce type d’amélioration transforme l’expérience utilisateur, sans sacrifier une seule fonctionnalité. On garde le même site, mais en version sportive.

Le JavaScript inutilisé vu par les utilisateurs

L’utilisateur, lui, ne sait pas que vous avez des fichiers en trop. Il ne connaît pas Lighthouse. Ce qu’il voit, c’est un site qui met trop longtemps à réagir.

Et malheureusement, l’attention d’un internaute tient parfois en moins de 3 secondes. Une étude bien connue montre qu’au-delà de 4 secondes d’attente, un grand nombre de visiteurs abandonnent le site. Une autre étude révèle qu’un gain d’une seule seconde peut augmenter les conversions de 7 %. C’est énorme.

Réduire le JavaScript, c’est donc avoir un site qui donne une bonne première impression, qui semble bien conçu, bien entretenu, agréable à naviguer. Un site qui respecte le temps des visiteurs.

Et au passage, un site qui consomme moins de batterie : ça, on l’oublie souvent, mais un code léger est un code écologique.

Conseils pour aller encore plus loin

Si vous avez envie de devenir le maître du nettoyage JavaScript, voici quelques idées que vous pouvez explorer ensuite (quand vous serez prêt) :

• Utiliser un bundler moderne (Vite, esbuild, Rollup)
• Charger les scripts en HTTP/2 pour profiter du multiplexage
• Utiliser un CDN qui compresse et met en cache automatiquement vos fichiers
• Désactiver les scripts inutiles côté admin sur WordPress
• Remplacer certains boutons dynamiques par de simples liens HTML ou ancres

Ce ne sont pas des obligations. Ce sont des armes supplémentaires que vous pourrez utiliser progressivement.

Le secret, c’est de commencer par le plus simple. Et de rester cohérent dans le temps.

Votre site web mérite une cure de légèreté

Ce n’est pas la peine de chercher midi à quatorze heures : l’immense majorité des sites web chargent beaucoup trop de JavaScript. Parce que c’est facile d’ajouter, mais tellement rare de retirer. Parce qu’on veut aller vite, parce que les outils modernes nous mâchent le travail, parce que “ça fonctionne”.

Pourtant, réduire le JavaScript inutilisé, c’est faire du bien à tout le monde. À vous, parce que votre site devient plus propre et plus maîtrisé. Aux utilisateurs, qui voient du contenu apparaître plus rapidement et interagir sans frustration. Aux moteurs de recherche aussi, qui mettent en avant les sites performants et bien optimisés.

Au fond, c’est un peu comme ranger son appartement. On peut vivre dans le bazar, mais on respire tellement mieux quand tout est à sa place. Une navigation fluide, c’est aussi une forme de respect pour celles et ceux qui visitent vos pages.

Alors je vous encourage : prenez le temps, régulièrement, d’ouvrir votre projet et de faire un état des lieux. Regardez ce qui peut disparaître, ce qui peut être déplacé, ce qui peut être allégé. Vous n’êtes pas obligé de tout faire en un jour. Chaque petite amélioration compte.

Un script de moins aujourd’hui, un chargement plus rapide demain. Et à la fin de l’histoire, un site web plus agréable et performant, dont vous pourrez être fier.

Chapitre 9 : Optimiser la version mobile

Alban

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr