Six icônes affichées, 125,9 Ko téléchargés

Un site lent se répare rarement par un seul geste. Mais avant de chercher loin, il vaut la peine de compter ce qui part sur le réseau avant même la première image, parce que ce total se fabrique par décisions minuscules dont aucune n'est fautive.

Ce que coûtent les briques les plus courantes

Le code est compté compressé, tel qu'il quitte le serveur, et les polices sont comptées telles quelles, leur format contenant déjà sa compression. Cette distinction n'est pas cosmétique, elle déplace les classements du simple au triple.

Deux surprises dans ce tableau. Bootstrap complet, grille et composants, pèse moins du tiers d'une police d'icônes, parce que le CSS se compresse remarquablement bien, de 232 803 octets à 31 079. Et AOS, dont nous nous méfions, ne coûte que 6,8 Ko : son problème n'est pas son poids mais le piège d'opacité qu'il laisse derrière lui quand il ne s'initialise pas.

Pourquoi le compte grimpe sans que personne décide

Prenons une page ordinaire qui doit afficher six icônes, un graphique à quatre barres et un carrousel de trois visuels. Le réflexe professionnel donne Font Awesome, Chart.js et Bootstrap, soit 238,3 Ko avant la moindre police de caractères. Ajoutez la typographie du site et vous êtes à 311,6 Ko, ce qui représente 6,38 secondes de transfert sur une connexion 3G bridée à 400 kbit/s.

Aucun des trois choix n'est critiquable isolément. Font Awesome fait gagner une demi-journée et permet de changer d'icône en modifiant un nom de classe. Chart.js devient indispensable dès que les données arrivent en direct. Bootstrap fait gagner des journées entières quand on en utilise vraiment la moitié. Le problème est que personne, à aucun moment, ne décide de leur addition.

Le mécanisme est toujours le même. Une police d'icônes livre le jeu entier, qu'on affiche six dessins ou six cents, et rien dans l'outil ne signale l'écart. Une bibliothèque de graphiques pèse pareil pour quatre barres figées que pour un tableau de bord complet. Le coût est mutualisé, l'usage est marginal, et le décalage n'apparaît sur aucun écran de développement.

Le vrai coût n'est pas en octets

Il serait facile d'en conclure qu'il faut tout écrire soi-même, et ce serait faux. Les six icônes dessinées dans notre exemple pèsent 501 octets et représentent environ une heure de travail. La septième prend encore vingt minutes. La quinzième oblige à ranger, nommer, documenter, et quelqu'un devra reprendre ce système dans trois ans.

C'est là que se trouve la vraie arithmétique. Une bibliothèque s'installe en dix minutes et coûte du poids à chaque visite. Un développement dédié coûte du temps une fois, puis de l'entretien, et ne pèse presque rien. L'arbitrage dépend du nombre d'éléments concernés, de la durée de vie du projet et de qui le maintiendra. Sur une plateforme conçue pour durer cinq à dix ans, le calcul penche souvent vers le sur mesure. Sur un site vitrine à refaire dans deux ans, presque jamais. C'est le raisonnement que nous instruisons page par page dans notre façon de travailler, et il ne donne pas toujours la même réponse.

Ce que le poids ne dit pas

Le poids transféré n'est qu'une composante de la vitesse ressentie. La latence du réseau, le nombre de fichiers demandés, leur ordre d'arrivée et les décalages visuels au chargement comptent autant. Un site léger mal ordonné reste lent, et un site plus lourd mais bien orchestré peut paraître instantané. Les six secondes calculées plus haut sont du temps de transfert pur, pas une promesse de temps d'affichage.

Une nuance vaut d'être posée sur la typographie. Les 149,1 Ko de Montserrat au complet supposent une page qui utilise les huit fichiers, alors qu'un navigateur ne télécharge que les variantes réellement employées. C'est précisément pour cette raison que déclarer huit fichiers se justifie rarement.

Refaire les mesures vous-même

Deux commandes suffisent. La première demande explicitement une réponse compressée et lit la taille transférée, ce qu'aucune lecture de fichier sur disque ne donnera.

La seconde compte une police, sans compression puisqu'elle en porte déjà une. La vérification vaut le détour, un passage en gzip sur fa-solid-900.woff2 fait passer le fichier de 113 152 à 113 209 octets. Il grossit de 57 octets, ce qui est la raison technique pour laquelle le WOFF2 doit être exclu de la compression côté serveur.

Pour une page entière plutôt qu'un fichier, notre analyseur de performance donne le poids réel, les trois indicateurs de Core Web Vitals et le détail ressource par ressource. Et si vous préférez manipuler les arbitrages plutôt que les lire, nous avons transformé ces mesures en un jeu de budget de poids où l'on compose une page en restant sous 150 Ko, avec une course de chargement qui traduit les kilo-octets en secondes d'attente.

Questions fréquentes

Comment mesurer le poids réel d'une bibliothèque sur mon site ?

En interrogeant le serveur avec un en-tête Accept-Encoding explicite, puis en lisant la taille effectivement transférée. Le poids du fichier sur le disque ne dit rien de ce qui part sur le réseau, puisque le serveur compresse le CSS et le JavaScript avant l'envoi. Pour les polices, la taille du fichier est la bonne valeur, leur format contient déjà sa compression.

Existe-t-il un budget de poids à respecter en 2026 ?

Aucun chiffre ne fait autorité, et se donner un budget vaut mieux que d'en chercher un universel. La méthode qui fonctionne consiste à fixer une limite tenable pour le projet, à la mesurer à chaque mise en production, et à traiter tout dépassement comme une décision à justifier plutôt que comme une fatalité.

Faut-il réduire Font Awesome à un sous-ensemble d'icônes ?

C'est la meilleure option quand une équipe dispose déjà d'une étape de build, puisque le gain se compte en dizaines de kilo-octets. Sans cette étape, le sous-ensemble doit être regénéré à la main à chaque ajout d'icône, et cette dette de maintenance rend souvent le SVG livré dans la page plus raisonnable.