Quand on demande à quelqu’un ce qui alourdit un site, la réponse est presque toujours « les images ». C’est vrai en volume. C’est trompeur en pratique, parce que les images sont aussi le poste le plus facile à corriger - et parce que le poids ne raconte qu’une partie de l’histoire.
Sur une page vitrine jamais optimisée, la répartition est presque toujours la même : 45 à 60 % du poids pour les images, 15 à 30 % pour le JavaScript, 5 à 15 % pour les polices, le reste pour le CSS et le HTML. Le poste le plus lourd n’est pourtant pas le plus coûteux, et c’est ce décalage qui fait échouer la plupart des optimisations.
Où part le poids d’une page ?
Sur une page vitrine ordinaire, jamais optimisée, on retrouve à peu près toujours ceci :
| Poste | Part du poids | Difficulté à corriger |
|---|---|---|
| Images | 45 à 60 % | Faible |
| JavaScript | 15 à 30 % | Élevée |
| Polices | 5 à 15 % | Faible |
| CSS | 3 à 8 % | Moyenne |
| HTML | 1 à 3 % | Négligeable |
Ce tableau explique pourquoi tant de démarches d’optimisation s’arrêtent en chemin. On compresse les images, on gagne 40 %, on est content, et on ne touche jamais au JavaScript - qui est pourtant le poste qui coûte le plus cher à l’usage.
Le poids n’est pas le coût
Un mégaoctet d’image et un mégaoctet de JavaScript ne se valent pas.
Une image, le navigateur la télécharge, la décode, l’affiche. C’est linéaire, et ça se parallélise. Si elle est hors écran et correctement marquée en chargement différé, elle ne coûte rien tant qu’on n’a pas fait défiler jusqu’à elle.
Un octet de JavaScript, il faut le télécharger, l’analyser, le compiler, l’exécuter - puis en garder le résultat en mémoire. Sur un téléphone d’entrée de gamme, analyser et compiler un mégaoctet de JavaScript prend plusieurs secondes, pendant lesquelles la page ne répond à rien. C’est cette phase que les visiteurs ressentent comme « le site rame », bien plus que le téléchargement.
Un mégaoctet d’image ralentit l’affichage. Un mégaoctet de JavaScript ralentit tout le reste.
Trois postes, trois gestes
Les images : la question avant la compression
Le premier réflexe est de compresser. Le bon réflexe est de se demander si l’image sert à quelque chose.
Une photographie de bandeau générique - l’équipe qui rit devant un ordinateur, la poignée de main, le bureau lumineux - n’apporte aucune information. Elle occupe l’espace où le visiteur cherchait à comprendre ce que vous faites. La retirer améliore le poids et la page.
Pour celles qui restent :
- Servir en AVIF, avec un repli WebP. À qualité perçue égale, on divise souvent le poids par trois par rapport au JPEG.
- Dimensionner à la taille d’affichage réelle. Une image affichée sur 600 pixels n’a aucune raison d’en faire 3000.
- Toujours poser
widthetheight, ou unaspect-ratio. Sans ça, la page saute quand l’image arrive. loading="lazy"sur tout ce qui est sous la ligne de flottaison, jamais au-dessus.
Un détail qui traîne souvent : l’attribut lazyload="true" n’existe pas. C’est loading="lazy". La faute est fréquente, et l’attribut inventé ne fait rien du tout.
Les polices : le poste le plus gaspillé
Une famille de caractères téléchargée en cinq formats - eot, ttf, svg, woff, woff2 - sert quatre formats pour rien. woff2 est compris par tous les navigateurs encore maintenus. eot visait Internet Explorer 8, svg un vieux Safari mobile.
Ensuite viennent les graisses. Un projet embarque volontiers quarante fichiers pour en afficher trois. Chacun est une requête et plusieurs dizaines de kilo-octets.
Enfin, le sous-ensemble. Une police complète transporte le cyrillique, le grec, des symboles mathématiques. Un site en français a besoin du latin, de quelques caractères accentués et de la ponctuation typographique. Sous-ensembler divise le poids par cinq ou six sans qu’aucun caractère de la page ne disparaisse.
Cumulé : trois graisses en woff2 sous-ensemblé, c’est de l’ordre de 40 Ko. Contre plusieurs mégaoctets dans le cas non traité.
Le JavaScript : compter ce qu’on utilise
Le plus dur, parce que le gain demande de dire non.
Une bibliothèque de dates pour afficher trois dates, alors que Intl.DateTimeFormat est déjà dans le navigateur. Une bibliothèque de graphiques pour deux barres qu’un SVG écrit à la main dessine en quinze lignes. Un composant de carrousel pour trois images qu’une liste en défilement horizontal afficherait mieux.
L’outil qui aide vraiment ici est l’onglet de couverture du navigateur : il montre, ligne par ligne, quelle part du code chargé a réellement été exécutée. Les résultats sont souvent brutaux - 5 à 10 % d’utilisation réelle n’a rien d’exceptionnel.
Le scénario qu’on oublie de tester
Tout ce qui précède se mesure sur une connexion rapide, sur un ordinateur récent, avec un cache déjà chaud. Ce n’est pas la situation de vos visiteurs.
Le test qui compte : première visite, cache vide, réseau mobile bridé, téléphone d’entrée de gamme. Les outils de développement de Chrome savent simuler tout ça. C’est désagréable la première fois. C’est aussi la seule mesure qui reflète ce que vit quelqu’un qui découvre votre site depuis un quai de gare.
Par où commencer ?
Un plan de travail après arbitrage. Ce n’est pas une question de goût : c’est ce qui reste quand on retire ce qui n’informe pas.
Si vous ne devez faire que trois choses :
- Retirez les images qui n’informent pas. Gain immédiat, et la page gagne en clarté.
- Ramenez vos polices à woff2, sous-ensemblé, et aux seules graisses affichées.
- Ouvrez l’onglet de couverture et regardez quelle proportion de votre JavaScript sert vraiment.
Ces trois gestes, sur un site jamais optimisé, font couramment passer une page de 2,5 Mo à moins de 600 Ko. Sans rien retirer de ce que le visiteur était venu chercher.