« Le site est lent » est un symptôme, pas un diagnostic. Avant de changer d'hébergeur ou d'acheter un module de cache supplémentaire, il faut répondre à une question simple et rarement posée : lente où, et pour qui ? Une page d'accueil qui met deux secondes et une page catégorie qui en met huit ne se soignent pas de la même façon.
Mesurer d'abord, et pas au mauvais endroit
Un test depuis votre navigateur, connecté au back-office, ne mesure rien d'utile : vous êtes hors cache, souvent en mode débogage, et votre connexion n'a rien à voir avec celle de vos clients. Ce qu'il faut relever, c'est le temps de réponse du serveur sur les pages réellement visitées, pour un visiteur anonyme, avec le cache actif — puis le même relevé avec le cache vidé.
L'écart entre les deux est l'information la plus utile du diagnostic. S'il est énorme, le cache ne corrige pas un problème : il le cache. Le premier visiteur après chaque vidage, et chaque page peu fréquentée, prendront le temps réel.
La base concentre presque toujours le problème
Sur un catalogue qui a grossi, la seconde perdue est le plus souvent dans une requête, pas dans le processeur. Les suspects sont toujours les mêmes : la recherche à facettes sur des tables sans index adapté, un module qui recalcule un total à chaque affichage de page au lieu de le stocker, et les tables techniques qui gonflent sans limite — connexions, invités, paniers abandonnés — parce que personne n'a jamais activé leur purge.
Le journal des requêtes lentes coûte quelques minutes à activer et désigne les coupables sans discussion. C'est la seule étape que je ne saute jamais, parce qu'elle transforme une opinion en fait.
Les images pèsent plus que tout le reste réuni
Sur une page produit ordinaire, les images représentent souvent quatre-vingts pour cent du poids transféré. Trois réglages règlent l'essentiel : générer les formats modernes plutôt que servir des JPEG surdimensionnés, déclarer les dimensions dans le HTML pour que la page ne saute pas pendant le chargement, et ne charger que ce qui est visible à l'écran — sauf l'image principale, qui doit au contraire être prioritaire.
Cette dernière nuance est celle qu'on rate le plus souvent : appliquer le chargement différé à l'image du haut de page dégrade la mesure au lieu de l'améliorer, parce que c'est précisément elle que le navigateur chronomètre.
Ce que le cache peut et ne peut pas
Le cache de pages sert des visiteurs anonymes sur des pages identiques. Il ne peut rien pour un panier, un compte client, un tunnel de commande — et c'est justement là que la lenteur coûte de l'argent. Une boutique dont la page d'accueil est instantanée et dont le tunnel met six secondes a un problème que le cache ne résoudra jamais.
Un réseau de diffusion devant la boutique change la donne pour les fichiers statiques, à condition de délimiter précisément ce qu'il a le droit de garder. La frontière se trace au niveau du panier et du compte : un fragment personnalisé servi depuis le cache est bien pire qu'une page lente.
Le serveur, en dernier
Passer sur une machine deux fois plus puissante divise rarement le temps par deux : cela masque le problème pendant quelques mois, jusqu'à ce que le catalogue reprenne son avance. Le changement d'hébergement se justifie quand la mesure le désigne — une base saturée, une version de PHP dépassée, un disque lent — pas comme première réponse.
Dans l'ordre, donc : mesurer, corriger la base, corriger les images, régler le cache, et seulement ensuite parler d'infrastructure. Cet ordre n'est pas une préférence, c'est celui du rapport entre l'effort et le gain.
Commentaires
Aucun commentaire pour l’instant. Le vôtre sera le premier.