Dans quel ordre auditer la vitesse d'une boutique WooCommerce ?

Une boutique WooCommerce lente est rarement lente pour une seule raison, et c'est ce qui rend le sujet pénible : chaque intervenant a sa cause préférée, l'hébergement pour l'un, les images pour l'autre, le thème pour le troisième, et l'on finit par tout changer sans savoir ce qui a produit l'amélioration. L'audit de vitesse d'une boutique WooCommerce gagne beaucoup à suivre une séquence fixe, du plus déterminant au plus anecdotique, avec une mesure à chaque étape. Cette discipline coûte une demi journée et évite les semaines de travail dépensées sur des optimisations réelles mais sans effet sur le problème constaté.

Mesurer avant de toucher à quoi que ce soit

La première erreur consiste à commencer par corriger. Sans état initial précis, aucune amélioration ne pourra être attribuée, et les efforts se dispersent. La mesure suit les mêmes principes que ceux exposés dans notre article sur le test de performance d'un site Internet, avec des particularités propres au commerce en ligne.

Séparer le temps serveur du temps navigateur

Deux durées très différentes se cachent derrière la lenteur perçue. Le temps de réponse du serveur, mesuré jusqu'au premier octet du document, dépend de PHP, de la base et du cache. Le temps d'affichage, qui suit, dépend des images, des scripts et des polices. Les corriger demande des compétences et des interventions sans rapport, et confondre les deux conduit à optimiser des images alors que le serveur met deux secondes à répondre. La première mesure à prendre est donc cette séparation, sur une poignée d'adresses.

Distinguer les gabarits, pas les pages

Une boutique comporte cinq gabarits qui se comportent très différemment : accueil, page de catégorie, fiche produit, panier et tunnel de commande. Les deux derniers ne sont jamais mis en cache et concentrent souvent le vrai problème, tout en n'apparaissant dans aucun rapport d'outil public, qui teste presque toujours l'accueil. Mesurer les cinq séparément, plusieurs fois, est la seule manière d'obtenir une image utilisable.

Mesurer avec et sans cache

Une page servie depuis le cache répond en quelques millisecondes et ne dit rien de la santé de la boutique. Il faut donc mesurer les deux états : le temps servi au visiteur ordinaire, qui reflète l'expérience réelle, et le temps de génération sans cache, qui reflète la charge que le serveur subira lors d'une pointe ou d'un passage de robot. Une boutique qui répond en cent millisecondes en cache et en quatre secondes sans cache est fragile, même si tous ses relevés publics sont excellents.

Regarder les données du terrain

Les mesures de laboratoire, prises depuis un poste unique, ne représentent pas la population réelle des visiteurs. Les données collectées auprès des utilisateurs, disponibles pour les sites suffisamment fréquentés, donnent la distribution effective et notamment le comportement des connexions les plus lentes. Sur une boutique, cette lecture change souvent les priorités : une médiane correcte peut cacher un quart de visiteurs pour qui la page met plus de cinq secondes à devenir utilisable.

Fixer un objectif chiffré

Un audit sans objectif ne se termine jamais. Poser d'emblée une cible pour chaque gabarit, par exemple un temps de réponse serveur sous trois cents millisecondes hors cache et un affichage utile sous deux secondes et demie sur connexion mobile moyenne, permet de savoir quand s'arrêter et d'arbitrer entre les chantiers. Cet objectif se discute avec le commerçant, car il a un coût, et il vaut mieux le poser avant d'avoir dépensé le budget. Il gagne à être exprimé en termes de conséquences plutôt qu'en secondes : ce qui intéresse un commerçant n'est pas le temps de réponse mais le nombre de visiteurs qui abandonnent avant l'affichage, et les deux se relient par les données de terrain.

Refaire la mesure dans les mêmes conditions

Une mesure de vitesse est très sensible aux conditions dans lesquelles elle est prise, et comparer un relevé du mardi matin avec un relevé du samedi soir ne prouve rien. Trois précautions rendent les comparaisons valables : prendre chaque mesure au moins cinq fois et retenir la médiane plutôt que la meilleure valeur, opérer toujours depuis le même point du réseau, et noter l'heure de la journée. Sur un hébergement mutualisé, la variation liée aux voisins peut atteindre un facteur deux entre deux moments de la journée, ce qui suffit à faire conclure à une amélioration là où il n'y a que du bruit. Consigner l'ensemble des relevés dans un tableau daté, avant et après chaque intervention, transforme cet exercice délicat en démonstration difficile à contester.

La base de données, premier suspect

Sur une boutique installée depuis plusieurs années, la base est presque toujours le facteur dominant du temps de génération. Elle grossit sans limite, ses tables les plus sollicitées se remplissent de données dont personne n'a besoin, et les requêtes qui la parcourent deviennent coûteuses. C'est le premier endroit à regarder, avant même les extensions, et c'est aussi le point de départ de tous les chantiers d'optimisation que nous menons dans la rubrique WooCommerce.

Compter les requêtes par page

Le nombre de requêtes exécutées pour afficher une page est l'indicateur le plus parlant. Une fiche produit correctement servie se situe entre trente et soixante requêtes ; au delà de deux cents, il y a un problème structurel, généralement une extension qui interroge la base dans une boucle. Ce comptage se fait avec un outil de profilage installé le temps de l'audit, et son résultat oriente immédiatement la suite du travail.

Identifier les requêtes lentes

Le nombre ne fait pas tout : une seule requête mal écrite peut consommer plus que les cent autres réunies. Le journal des requêtes lentes du serveur de base de données, activé le temps de l'audit avec un seuil bas, donne la liste exacte. Les coupables habituels sont les recherches sur les métadonnées de produits sans index adapté, les comptages sur l'historique de commandes et les requêtes de navigation à facettes portant sur un catalogue important.

Les tables qui gonflent

Trois tables méritent une inspection systématique. Celle des options, qui contient des données chargées à chaque requête et se remplit d'entrées temporaires jamais nettoyées. Celle des métadonnées d'articles, qui accumule les données des commandes et des produits supprimés. Celle des sessions et des paniers, qui peut atteindre des tailles considérables sur une boutique fréquentée. Leur volume se mesure en une requête, et un écart manifeste avec la taille du catalogue signale du nettoyage à faire.

Le chargement automatique des options

WordPress charge à chaque requête l'intégralité des options marquées comme telles, ce qui est efficace tant que leur volume reste raisonnable. Certaines extensions y stockent des caches applicatifs, des journaux ou des listes complètes, et le volume passe alors de quelques centaines de kilooctets à plusieurs mégaoctets, lus et désérialisés à chaque page. Ce contrôle prend deux minutes, produit souvent le gain le plus spectaculaire de tout l'audit, et il est rarement fait.

Les tables des commandes

Les versions récentes de WooCommerce proposent un stockage des commandes dans des tables dédiées plutôt que dans les tables génériques d'articles, ce qui change l'ordre de grandeur des requêtes sur l'historique. La migration demande des précautions et une vérification de compatibilité avec les extensions installées, mais sur une boutique comptant des dizaines de milliers de commandes, elle transforme l'administration autant que le site public. La bascule se prépare sur une copie de la boutique, avec un contrôle explicite des extensions qui lisent les commandes directement en base plutôt que par les fonctions prévues, ces dernières étant les seules à cesser de fonctionner silencieusement.

Les extensions, deuxième suspect

Une boutique accumule les extensions au fil des besoins, et leur coût ne se manifeste jamais au moment de l'installation. L'audit doit les traiter comme une population à mesurer, pas comme une liste à réduire par principe.

Mesurer le coût individuel

Un profileur permet d'attribuer à chaque extension le temps qu'elle consomme et le nombre de requêtes qu'elle déclenche, par gabarit. Le résultat est presque toujours très déséquilibré : deux ou trois extensions représentent la moitié du coût total, et les vingt autres se partagent le reste. C'est sur ces deux ou trois qu'il faut concentrer l'attention, en cherchant une alternative, un réglage, ou une désactivation ciblée sur les pages où elles ne servent pas.

Charger sur les pages concernées seulement

Beaucoup d'extensions chargent leurs scripts et feuilles de style sur toutes les pages, alors qu'elles ne servent que sur une. Un formulaire de contact chargé sur trois mille fiches produit, un carrousel présent uniquement sur l'accueil, une extension d'avis chargée sur le panier constituent du poids pur. Le désenregistrement conditionnel de ces ressources est un travail mécanique, sans risque quand il est fait avec méthode, et il allège considérablement les gabarits les plus visités. Il demande en revanche d'être refait après chaque mise à jour majeure d'extension, les noms des ressources enregistrées pouvant changer sans préavis, ce qui remet silencieusement en place les chargements retirés.

Repérer les appels externes bloquants

Une extension qui interroge un service distant pendant la génération de la page rend le temps de réponse dépendant d'un tiers. Si ce service ralentit, la boutique ralentit ; s'il tombe, la boutique attend le délai d'expiration, souvent plusieurs secondes. Ces appels se repèrent dans le profilage et doivent être soit mis en cache, soit déportés dans une tâche de fond, soit assortis d'un délai d'attente très court avec repli silencieux.

Traiter les tâches planifiées

Le mécanisme de tâches planifiées de WordPress s'exécute pendant les requêtes de visiteurs, ce qui signifie qu'un visiteur malchanceux paie le temps d'un traitement lourd. Sur une boutique où des synchronisations de stock ou des envois de courriels sont programmés, cet effet est très perceptible. Le basculement vers une planification système, avec désactivation du déclenchement par le trafic, supprime cette catégorie entière de ralentissements aléatoires.

Se méfier des couches d'optimisation empilées

Il n'est pas rare de trouver deux extensions de cache, une extension d'optimisation d'images et un service externe faisant la même chose, chacun tentant de réécrire le HTML produit par les autres. Le résultat est un site plus lent que sans rien, et surtout impossible à diagnostiquer. La règle est simple : une seule couche par fonction, et vérification que chacune fait bien ce qu'elle promet avant d'en ajouter une autre. Le contrôle se fait en lisant le HTML servi et les en têtes de réponse, où chaque couche laisse sa trace, ce qui révèle immédiatement les traitements qui s'annulent les uns les autres.

Vérifier le comportement en administration

La lenteur ressentie par le commerçant vient très souvent de l'administration plutôt que du site public, et personne ne l'audite. Les écrans qui posent problème sont toujours les mêmes : la liste des commandes, la liste des produits avec ses filtres, et l'écran d'édition d'un produit à nombreuses variantes. Ces pages ne sont jamais mises en cache, exécutent des requêtes lourdes et chargent tout ce que les extensions veulent bien y ajouter. Les mesurer explicitement, au même titre que les gabarits publics, est indispensable : une boutique dont chaque commande demande quinze secondes d'attente à la préparation coûte bien plus cher en temps de travail que quelques dixièmes de seconde gagnés sur une fiche produit.

Cache, ressources et priorités

Vient enfin la couche la plus visible, celle par laquelle beaucoup commencent à tort. Elle apporte de vrais gains une fois les deux étapes précédentes traitées, et des gains illusoires si elles ne le sont pas. Elle a par ailleurs un effet direct sur la mesure du parcours d'achat, telle que décrite dans notre article sur la manière de suivre le tunnel de conversion WooCommerce dans Google Analytics 4.

Ce qui ne doit jamais être mis en cache

Panier, commande, compte client et pages de confirmation doivent être exclus du cache de pages, sans exception, sous peine d'afficher le panier d'un autre client. La plupart des extensions de cache connaissent ces adresses, mais les configurations personnalisées et les traductions d'adresses créent régulièrement des trous. Un contrôle explicite, avec deux navigateurs et deux paniers différents, fait partie de la recette obligatoire de toute mise en place, et mérite d'être refait après toute modification de la configuration du cache, y compris celles qui semblent sans rapport.

Le cache d'objets, souvent plus utile que celui de pages

Un cache d'objets persistant conserve en mémoire les résultats de requêtes coûteuses, et profite aux pages qui ne peuvent pas être mises en cache, c'est à dire précisément celles qui posent problème. Sur une boutique, son effet sur le panier et le tunnel de commande est souvent supérieur à celui du cache de pages sur le reste du site. Il demande un service dédié sur le serveur, ce qui n'est pas disponible partout, et constitue un bon critère de choix d'hébergement. Sa mise en place demande une vigilance particulière au moment des déploiements, un cache d'objets non vidé après une mise à jour servant des données structurées selon l'ancienne version du code.

Les images, dans le bon ordre

Le travail sur les images vient après, et se fait dans un ordre précis : servir des dimensions adaptées à l'affichage, ce qui est de loin le plus rentable, puis choisir un format moderne, puis différer le chargement de ce qui n'est pas visible d'emblée. L'erreur courante consiste à commencer par la compression, dont le gain est réel mais bien plus faible que celui obtenu en cessant de servir une image de trois mille pixels dans un emplacement qui en fait trois cents.

Décider ce qu'on ne fera pas

Un audit produit toujours plus de recommandations qu'il n'y a de budget. Les classer par rapport entre gain mesuré et coût d'intervention, et assumer d'écarter explicitement le bas de la liste, vaut mieux qu'un document de quarante points dont on traitera les cinq premiers avant de l'oublier. La liste écartée doit être conservée : elle redevient utile au moment où la boutique change d'échelle et où les arbitrages se posent différemment. Elle constitue aussi une trace de ce qui a été vu et écarté sciemment, ce qui vaut mieux que de redécouvrir le même point deux ans plus tard en croyant l'avoir manqué. Elle gagne à mentionner la version de la boutique et celle des extensions au moment de l'audit, deux informations qui expliquent souvent à elles seules pourquoi une mesure ancienne ne se reproduit plus dans les mêmes conditions.