« Notre page fait 400 Ko, c’est très bien. » Peut-être. Mais 400 Ko d’images, c’est un décodage et un rendu ; 400 Ko de JavaScript, c’est un téléchargement, un parsing, une compilation et une exécution — sur un fil unique, celui-là même qui doit répondre aux clics.
L’octet n’est pas l’unité pertinente
À poids égal, le JavaScript est de loin l’octet le plus cher du web. Sur un mobile d’entrée de gamme, le rapport de coût entre une image et un script de même taille se compte en ordres de grandeur.
Un octet de JavaScript coûte bien plus cher qu’un octet d’image : il faut le parser, le compiler, puis l’exécuter.
Une règle empirique qui a mal vieilli — dans le bon sens
Ce qu’on peut retirer sans rien perdre
- Les carrousels — coûteux, mal fichus en accessibilité, et cliqués par presque personne.
- Les polices superflues — deux graisses d’une variable suffisent presque toujours.
- Les librairies d’animation —
transitionet@keyframescouvrent l’essentiel des besoins, sans JavaScript. - Les tag managers empilés — le champion discret des sites lents.
L’amélioration progressive n’est pas un luxe
Une page dont le contenu dépend du JavaScript pour s’afficher a un point de défaillance unique. Réseau instable, script bloqué par une extension, erreur d’exécution : l’utilisateur voit une page blanche. La même page rendue côté serveur, enrichie ensuite, dégrade au lieu de casser.
Ce n’est pas une position idéologique. C’est de la gestion du risque.