Comment réduire le JavaScript de son site de 70 % en 2026

Pour réduire le JavaScript d’un site de 70 %, il faut dans cet ordre mesurer ce que vous livrez, supprimer ce qui ne sert à personne, puis différer le reste. L’optimisation du code vient en dernier, et elle pèse peu. Dans ma pratique sur les sites vitrines, l’essentiel du gain vient de la suppression pure et simple.

Un avertissement avant d’aller plus loin : « 70 % » n’est pas une promesse. Sur un site WordPress chargé de plugins, c’est un objectif réaliste. Sur un site déjà sobre, il n’y a plus rien à retirer. Plutôt que de recycler une statistique flatteuse, je vous montre le détail chiffré de ma propre page d’accueil, mesuré le 14 octobre 2026, avec ce qu’elle contient et ce que j’en pense.

Pourquoi le JavaScript est le poste le plus coûteux

Un octet d’image coûte du téléchargement. Un octet de JavaScript coûte trois fois : le téléchargement, l’analyse, puis l’exécution sur le fil principal du navigateur, celui-là même qui doit répondre quand quelqu’un touche l’écran.

C’est pour cela que l’INP (Interaction to Next Paint) est sensible au sujet. Il a remplacé le FID comme Core Web Vital, comme l’annonce web.dev, et le seuil « bon » est de 200 ms au 75e centile des visites. Un téléphone Android d’entrée de gamme exécute le JavaScript beaucoup plus lentement qu’un ordinateur portable de développeur. Un site qui paraît fluide sur votre machine peut être pénible sur celle de vos visiteurs.

Pour situer l’ordre de grandeur, le Web Almanac 2024 de HTTP Archive relève une médiane d’environ 558 Ko de JavaScript par page sur mobile, dont près de la moitié (47 %) est inutilisée au chargement. Autrement dit, sur une page médiane, on télécharge et on analyse du code qui ne servira pas.

Étape 1 : mesurer avant de toucher à quoi que ce soit

Je ne supprime rien sans avoir ouvert trois outils :

1. Le dossier de build. Avec Astro, dist/_astro contient tous les fichiers JS. Un ls -S suffit à voir qui pèse.
2. L’onglet Couverture de Chrome (DevTools). Il indique, fichier par fichier, la part de code réellement exécutée au chargement.
3. PageSpeed Insights, section « Réduire le JavaScript inutilisé », pour recouper avec les données de terrain.

Voici ce que donne la première étape sur le build de ce site (nouhbenzidane.fr), page d’accueil, tailles compressées en gzip, mesurées moi-même :

Fichier chargé par la page d’accueil	Taille gzip	Rôle
Runtime React (renderer Astro)	58,1 Ko	Hydrater les îlots React
Bibliothèque d’animation (Motion)	39,7 Ko	Animations d’entrée et interactions
Composant du hero	7,0 Ko	Animation du bloc principal
Outil d’audit (formulaire)	6,6 Ko	Lead-gen, utile seulement s’il est utilisé
Routeur de transitions de pages	4,8 Ko	Navigation fluide entre pages
Cinq petits îlots (curseur, compteur…)	2,9 Ko	Effets d’interface
Total	≈ 119 Ko

Ma conclusion, sans diplomatie : environ 86 % de ce poids (React, Motion et routeur : 102,6 Ko sur 119,1) sert à des effets et à la navigation, pas au contenu. Le texte, les prix, le formulaire de contact fonctionneraient sans une ligne de JavaScript. Je l’ai choisi en connaissance de cause pour mon propre site, qui est aussi ma vitrine technique. Chez un artisan qui veut des appels, je ne ferais pas ce choix.

Étape 2 : supprimer, c’est là que se gagne l’essentiel

Dans le tableau ci-dessus, si ce site était un site de dépannage local, je supprimerais d’abord le curseur personnalisé, les compteurs animés et l’effet d’inclinaison des cartes. Ces trois îlots pèsent à peine 2 Ko, mais ils obligent à embarquer le runtime qui les fait fonctionner. C’est le runtime qui coûte, pas l’îlot.

C’est un point que beaucoup de développeurs manquent : le coût marginal du premier composant React est de 58 Ko, celui du dixième est de quelques centaines d’octets. Si vous avez un seul petit effet qui justifie React, retirez l’effet et vous retirez tout.

Les candidats à la suppression que je retrouve le plus souvent en audit :

• Les bibliothèques d’animation pour un simple fondu. Un @keyframes CSS et une propriété animation-timeline ou un IntersectionObserver de 10 lignes font le même travail.
• jQuery et ses plugins sur des thèmes WordPress dont le seul usage est un menu mobile et un carrousel.
• Les carrousels et sliders d’accueil. Rarement utiles pour la conversion, toujours coûteux.
• Les widgets tiers empilés : chat, pop-up de réduction, outils de cartes thermiques, pixels publicitaires. Chacun apporte son propre JavaScript, et vous n’en maîtrisez pas la taille.
• Les polices d’icônes ou bibliothèques d’icônes entières quand cinq icônes SVG en ligne suffiraient.

Les widgets de suivi ont aussi un coût réglementaire. La CNIL accepte des mesures d’audience exemptées de consentement sous conditions strictes, et un outil cookieless comme Plausible évite à la fois le bandeau et le script lourd. Remplacer un outil d’analytics lourd par une solution cookieless, c’est un script et un bandeau de consentement en moins.

Étape 3 : différer ce qui reste

Ce qui survit à la suppression doit se charger au bon moment. C’est le principe de l’architecture en îlots d’Astro : la page est du HTML statique, et seuls les composants marqués par une directive client:* reçoivent du JavaScript.

Les directives d’Astro s’utilisent ainsi :

• client:load : hydratation immédiate, pour ce qui doit être interactif tout de suite (un menu, un formulaire au-dessus de la ligne de flottaison).
• client:idle : hydratation quand le navigateur est inactif, pour les éléments secondaires.
• client:visible : hydratation quand le composant entre dans la fenêtre, pour tout ce qui est plus bas dans la page.
• Sans directive : aucun JavaScript, le composant est rendu en HTML pur au build.

Dans les composants de ma page d’accueil, j’ai compté 20 usages de client:visible contre 1 seul client:idle. L’outil d’audit de 6,6 Ko, situé bas dans la page, ne devrait donc consommer du temps d’exécution que si le visiteur y arrive. Pour les sites sans Astro, import() dynamique et l’attribut defer sur les scripts jouent le même rôle.

Le piège à éviter : tout passer en client:load par réflexe, parce que « ça marche ». Cela annule l’intérêt du framework, et vous retombez sur un site qui hydrate tout au chargement.

Ce que j’appliquerais pour un e-commerce comme eotra.fr

Un site marchand n’a pas le même arbitrage qu’une vitrine. Pour eotra.fr, en cours de construction, la règle que je suis est de réserver le JavaScript aux endroits où il rapporte directement de l’argent : panier, sélecteur de variante, recherche. Les pages de présentation et les fiches de contenu restent en HTML statique, et le reste se charge à la demande.

Ce découpage allège aussi la maintenance : moins de dépendances, moins de mises à jour de sécurité à suivre, moins de régressions après un changement de version. Cela se répercute sur le budget en euros d’un projet, bien plus que le TJM.

Étape 4 : fixer un budget et le faire respecter

Une optimisation sans garde-fou se dégrade en six mois, dès que quelqu’un ajoute un widget. Je fixe un budget au démarrage : moins de 100 Ko de JavaScript compressé pour une page vitrine, zéro pour une page d’article. Ce sont des plafonds de conception, pas des mesures tirées d’un site précis.

Pour les faire respecter, trois mécanismes simples :

1. Un script de CI qui additionne la taille des fichiers de dist/_astro et échoue au-delà du seuil.
2. Une revue systématique de toute nouvelle dépendance : taille sur Bundlephobia, alternative native possible ?
3. Un contrôle trimestriel sur PageSpeed Insights, avec les données de terrain de PACA ou d’ailleurs selon la clientèle visée, pas seulement le test de laboratoire.

Résumé

Réduire fortement le JavaScript passe par trois étapes : mesurer le build (sur ma page d’accueil, environ 119 Ko gzip dont environ 86 % servent à des effets et à la navigation), supprimer les bibliothèques et widgets qui n’apportent rien au visiteur, puis différer le reste avec des îlots hydratés à la demande. Le premier composant d’un framework coûte cher, les suivants presque rien : retirer le dernier effet permet donc de retirer tout le runtime.

Ce qu’il faut retenir

• Un objectif de 70 % est réaliste sur un site chargé de plugins, pas sur un site déjà sobre : mesurez d’abord.
• Le Web Almanac 2024 relève environ 558 Ko de JavaScript médian sur mobile, dont 47 % inutilisé.
• Le coût d’un framework est dans son runtime (58 Ko gzip pour React sur ma page), pas dans vos composants.
• Supprimez avant d’optimiser : carrousels, jQuery, widgets tiers et animations remplaçables par du CSS.
• Dans Astro, préférez client:visible et client:idle à client:load, et aucune directive quand le composant n’a pas besoin d’être interactif.
• Fixez un budget (moins de 100 Ko gzip pour une vitrine) et faites échouer la CI quand il est dépassé.