Pourquoi votre site est lent — et ce que ça vous coûte

Presque tous les clients qui nous disent « mon site est rapide » le testent sur un ordinateur de bureau, connecté en fibre, avec le site déjà en cache parce qu’ils l’ouvrent dix fois par jour. Leurs visiteurs, eux, arrivent sur un téléphone milieu de gamme, en 4G variable, sans rien en cache.

L’écart entre ces deux expériences est considérable, et il ne se voit jamais depuis le bureau. C’est la raison pour laquelle la lenteur d’un site est presque toujours découverte trop tard, généralement quand quelqu’un se demande pourquoi les publicités coûtent si cher.

Ce qui suit décrit ce que nous trouvons le plus souvent en ouvrant le capot, dans l’ordre où cela coûte de l’argent. Chaque chiffre cité vient d’une source publique nommée sous le graphique correspondant — nous ne publions pas de mesure maison présentée comme une statistique.

C’est écrit pour être appliqué sans nous : les vérifications se font depuis votre téléphone, et les deux premières corrections ne demandent aucune refonte.

Le même relevé décompose la page médiane. Les images en représentent 1 058 kilooctets, le JavaScript 697, et tout le reste — HTML, feuilles de style, polices, vidéos, données — se partage les 607 restants.

Cette répartition explique pourquoi l’ordre des corrections n’est pas une question de goût. Les images pèsent à elles seules plus que le JavaScript et le reste additionnés dans beaucoup de cas, et ce sont aussi celles qui se corrigent sans toucher au code, sans refonte et sans risque de casser quoi que ce soit.

Elle explique aussi pourquoi tant de projets d’optimisation échouent. On commence par le JavaScript parce que c’est là que se trouve la partie technique intéressante, on y passe deux semaines, on gagne deux cents kilooctets, et la page reste lente parce que la photo de couverture pèse toujours quatre mégaoctets.

Il faut ajouter une nuance que le graphique ne montre pas : ces catégories ne coûtent pas au même moment. Les images retardent surtout l’instant où la page paraît complète ; le JavaScript retarde l’instant où elle devient utilisable — un bouton peut être visible et ne rien faire pendant deux secondes. Un visiteur qui appuie sans effet ne conclut pas que le site est lent, il conclut qu’il est cassé, et c’est une pensée dont on ne revient pas.

Ce n’est pas une impression. Dans l’observatoire du marché de l’internet de l’ARPCE pour le deuxième trimestre 2025, sur 59,10 millions d’abonnements internet en Algérie, 88,71 % sont des abonnements mobiles et 11,29 % des abonnements fixes.

Autrement dit, environ neuf accès sur dix passent par un réseau mobile. Concevoir et tester pour le poste fixe, c’est optimiser pour le dixième de son audience — et pas le dixième le plus difficile à convaincre, puisque c’est souvent celui qui vous connaît déjà.

Il faut y ajouter un point que le pourcentage ne dit pas : sur mobile, les données ne sont pas seulement lentes, elles sont payées. Un visiteur qui charge huit mégaoctets pour lire trois paragraphes dépense son forfait pour votre code. Il ne le formulera jamais ainsi, mais il ne reviendra pas.

Un dernier effet n’apparaît sur aucun tableau de bord : la variabilité. Une connexion mobile n’est pas seulement plus lente qu’une fibre, elle est irrégulière — elle change selon l’heure, le lieu, le nombre de personnes sur la même antenne. Une page légère traverse cette irrégularité sans que le visiteur la remarque ; une page lourde la transforme en attente visible, et rarement la même deux fois, ce qui rend le problème difficile à reproduire pour celui qui essaie de le diagnostiquer.

Un serveur mutualisé bon marché et géographiquement éloigné ajoute un délai à chaque requête, avant même que le premier octet de contenu ne parte. Ce délai ne se voit sur aucune image et ne se corrige avec aucun plugin.

C’est rarement le problème principal, et c’est pour cela qu’il arrive en dernier dans cette liste : changer d’hébergeur pendant qu’une page charge huit mégaoctets d’images ne produit aucun effet mesurable. Mais c’est le seul poste qui pénalise toutes les pages en même temps, y compris celles qui sont propres.

Le bon moment pour s’en occuper est donc précis : quand les images sont traitées, les scripts inutiles retirés, et que le site reste lent malgré tout. À ce stade seulement, la distance devient la part dominante et le déplacement se justifie.

Un signe permet de le savoir sans instrument : si toutes les pages, y compris les plus légères, mettent le même temps avant que quoi que ce soit n’apparaisse, ce délai constant est le temps de réponse du serveur. Il ne dépend pas du contenu — c’est pour cela qu’il est identique partout, et c’est aussi pour cela qu’aucune optimisation de page ne le réduira.

Nous commençons par mesurer, avant de toucher à quoi que ce soit : depuis un téléphone réel, en données mobiles, aux heures où vos visiteurs arrivent réellement. Cette mesure de départ est écrite et vous est remise, parce que sans elle personne — ni vous ni nous — ne pourra dire ensuite si le travail a servi.

Nous vous rendons ensuite la liste ordonnée de ce qui coûte du temps sur votre site, avec le gain attendu de chaque correction et l’effort qu’elle demande. Vous décidez jusqu’où aller. Il arrive souvent que les deux premières lignes suffisent et que nous vous le disions, y compris quand cela réduit le travail que vous alliez nous confier.

Nous traitons ensuite ce qui a été retenu : les images et leur traitement automatique au téléversement, le retrait des scripts que plus personne ne revendique, les polices, et la limite de poids par page à respecter ensuite. Nous remesurons entre chaque changement, pas à la fin, pour que le gain soit attribuable.

Et nous vous disons quand le problème n’est pas de notre ressort. Un site lent parce que la ligne du serveur est saturée ne se corrige pas par de l’optimisation de page, et vous vendre trois semaines de travail dans ce cas serait vous vendre du temps. C’est le genre de réponse que l’audit gratuit sert à obtenir avant tout engagement.