La plupart des sites lents ne le sont pas pour une seule raison, et presque jamais pour celle qu'on croit. Avant de toucher au code, il faut savoir ce que vivent les visiteurs réels, séparer les causes serveur des causes navigateur, et accepter que certains gains demandent beaucoup d'effort pour peu d'effet. Voici la méthode que nous appliquons, l'ordre dans lequel nous corrigeons, ce que vous recevez par écrit, et ce que ce type de chantier ne règle pas.
Mesurer d'abord, et mesurer deux choses différentes
Il existe deux familles de mesures et elles ne racontent pas la même histoire. Les tests de laboratoire lancent une page dans des conditions simulées : ils sont reproductibles, utiles pour comparer avant et après, et ils pointent précisément ce qui coince. Les données de terrain, elles, remontent de vrais visiteurs, sur de vrais appareils, avec de vrais réseaux. C'est la seule source qui dise si votre audience attend vraiment. Un site peut afficher un bon score synthétique et rester pénible en 4G sur un téléphone modeste, où l'exécution du JavaScript coûte beaucoup plus cher.
Nous commençons donc par échantillonner les pages qui comptent : la page d'accueil bien sûr, mais surtout les pages d'entrée depuis Google, les fiches produit ou service, et le formulaire ou le tunnel de commande. Sur chacune, nous testons cache vide, en mobile, en connexion bridée. Ensuite seulement nous regardons la répartition du temps : combien avant le premier octet (le serveur), combien pour télécharger et exécuter (le navigateur). Cette séparation évite l'erreur la plus fréquente, changer d'hébergement pour un problème qui vient du navigateur, ou l'inverse.
L'ordre dans lequel nous corrigeons, et ce qui se décide avec vous
Nous ne traitons pas tout en même temps, parce que les postes n'ont ni le même gain ni le même risque. Passent en premier les corrections qui ne retirent rien à personne : images envoyées en pleine résolution puis redimensionnées par le navigateur, formats anciens, éléments chargés alors qu'ils sont trois écrans plus bas, place non réservée qui fait sauter la mise en page. Viennent ensuite le cache, la compression et les polices, qui retardent l'affichage du texte ou provoquent un changement visuel brutal au chargement. Rien de tout cela ne demande votre arbitrage, donc rien ne bloque.
La deuxième vague ne nous appartient pas. Mesure d'audience, tags publicitaires, chat, avis clients, cartes, tests A/B, bandeau de consentement : chacun ajoute une connexion vers un domaine externe, du code à exécuter et une latence hors de notre contrôle. Nous vous remettons le coût en temps de chacun, vous décidez de ce qui reste, de ce qui part et de ce qui attend le consentement. La troisième vague est structurelle : hébergement sous-dimensionné, thème surchargé, page qui n'envoie qu'une coquille vide avant de tout reconstruire en JavaScript. Elle se compte en semaines, elle se décide après le diagnostic, jamais avant.
Ce que nous mesurons, et ce que vous recevez par écrit
Le document que nous vous envoyons tient en trois parties. L'état de départ d'abord, page par page : le temps avant le premier octet, le moment où le contenu principal devient visible, la réactivité quand le visiteur clique sur un menu ou un filtre, la stabilité de la mise en page pendant le chargement. Nous traduisons ces indicateurs en français courant, avec ce que chacun implique pour vos visiteurs, plutôt qu'en sigles. L'inventaire ensuite : chaque script externe, chaque image lourde, chaque ressource qui bloque le rendu, avec le poids et le temps associés. La liste des actions enfin, classées par gain attendu et par effort, en signalant celles qui relèvent d'une décision de votre côté.
Après les corrections, nous remesurons les mêmes pages dans les mêmes conditions : même appareil simulé, même bridage réseau, cache vide. C'est la seule comparaison qui veut dire quelque chose. Nous écrivons ce qui a bougé et ce qui n'a pas bougé, y compris quand le résultat déçoit. Nous ne promettons aucun chiffre à l'avance, parce que ces indicateurs dépendent des appareils, des réseaux et du trafic réel, donc de facteurs hors de notre contrôle. Le document reste exploitable par votre prestataire actuel si vous préférez faire réaliser les corrections ailleurs.
Vitesse, SEO et conversion : ce qui est vrai, ce qui est exagéré
Le lien avec le SEO existe, mais il est plus modeste que ce que promettent beaucoup d'argumentaires. Google prend en compte l'expérience de page parmi de nombreux signaux, et la pertinence du contenu reste dominante : accélérer une page qui ne répond pas à la requête ne la fera pas monter. En revanche, à qualité de contenu comparable, la lenteur devient un désavantage, et elle a un effet indirect bien réel. Un visiteur qui repart avant l'affichage ne lit rien, ne partage rien et ne revient pas.
Ce que nous constatons de plus net se joue du côté de la conversion. L'attente sur une fiche produit, une page de contact ou une étape de paiement fait partir une partie des visiteurs, surtout sur mobile, où le réseau est plus capricieux. C'est pourquoi nous commençons rarement par la page d'accueil : nous priorisons les pages qui reçoivent le trafic de recherche et celles où le visiteur agit. Un gain réel sur une page très consultée vaut mieux qu'un score parfait sur une page que personne ne visite. Cette logique guide aussi l'arbitrage des scripts marketing : un outil de mesure d'audience se défend, dix outils qui se recouvrent coûtent plus qu'ils ne rapportent.
Ce qui fait varier l'effort, et ce que ce chantier ne règle pas
Trois facteurs déterminent l'ampleur du travail. Le socle technique d'abord : un site déjà construit proprement se règle par des corrections ciblées, tandis qu'un thème générique bourré d'extensions demande des arbitrages lourds, parfois une reconstruction. Le nombre de scripts tiers ensuite : chaque suppression est une discussion avec ceux qui s'en servent. La dépendance à un CMS enfin : quand une fonctionnalité indispensable est portée par une extension lente, il faut soit la remplacer, soit la réécrire, soit assumer ce qu'elle coûte en temps de chargement.
Il faut aussi dire ce que l'optimisation ne fait pas. Elle ne compense pas un contenu qui ne répond pas à la demande, ne crée pas de trafic là où il n'y en a pas, et ne garantit aucune position. Elle ne fige pas non plus le résultat : un site optimisé redevient lent en quelques mois si l'on rajoute des tags, des vidéos intégrées et des images non préparées, raison pour laquelle nous laissons des règles simples et écrites. Sur certaines plateformes fermées, une partie du chargement nous échappe et le plafond est atteint plus vite.
Les corrections et les reconstructions en Next.js et React sont faites par Robin Monteiro, cofondateur et développeur, l'arbitrage des outils marketing se fait avec Florian Loppion. Nous sommes à Dijon, 9 rue Jean-Jacques Rousseau, et nous travaillons à distance et par écrit : aucun trajet, aucun frais de déplacement au devis, et tout ce qui est décidé reste retrouvable dans vos emails.
