« Vos commandes sont stockées comme des articles de blog. » Résumée ainsi, la limite historique de WooCommerce paraît presque absurde, et pourtant c’est très exactement le cas depuis les débuts du plugin : chaque commande est un post_type comme un autre, avec ses données éparpillées dans la table wp_postmeta, une table générique pensée pour des métadonnées d’articles, pas pour des enregistrements transactionnels structurés interrogés en masse par des rapports de vente.
WooCommerce propose depuis peu, en bêta activable volontairement dans les réglages avancés, un nouveau mode de stockage baptisé High-Performance Order Storage, qui déplace les données de commande vers des tables personnalisées dédiées, avec un schéma pensé spécifiquement pour ce type de données. Ce nouveau mode s’accompagne d’une compatibilité ascendante : chaque site peut basculer, tester, et revenir en arrière si besoin, ce qui a permis de le tester sereinement sur un environnement de préproduction avant d’envisager une migration en production.
Pourquoi les tables personnalisées changent la donne pour les rapports
Un rapport de ventes mensuel, dans le stockage historique, doit joindre la table wp_posts (pour le statut et la date de la commande) à la table wp_postmeta à plusieurs reprises (pour le montant total, la méthode de paiement, l’identifiant client), chaque jointure supplémentaire dégradant le plan d’exécution MySQL sur un volume de commandes important. Avec HPOS, ces données vivent nativement dans des colonnes typées d’une table dédiée (wc_orders), ce qui permet à MySQL d’exploiter des index bien plus efficaces sans jointure répétée sur une table générique.
Premières mesures, sur un jeu de données de test
Sur un environnement de préproduction chargé avec 50 000 commandes historiques importées pour l’occasion, un rapport de ventes mensuel agrégeant montant total, nombre de commandes et panier moyen a été comparé entre les deux modes de stockage :
| Mode de stockage | Temps de génération du rapport |
|---|---|
| Stockage historique (posts/postmeta) | 2,1 secondes |
| HPOS (tables personnalisées, bêta) | 0,49 seconde |
Soit un gain de 4,3 fois sur ce rapport précis, le plus consommateur en jointures parmi les rapports testés. Les fiches de commande individuelles, elles, montrent un gain plus modeste, de l’ordre de 30 %, cohérent avec le fait qu’elles sollicitent moins de jointures qu’un rapport agrégé sur plusieurs milliers de lignes.
Ce qui n’a pas encore été testé
Cette bêta reste jeune, et plusieurs zones méritent encore la prudence avant une migration en production : la compatibilité de certaines extensions tierces qui accèdent directement aux données de commande via get_post_meta() plutôt que via l’API WooCommerce officielle, ce qui pourrait casser silencieusement si ces extensions ne sont pas encore mises à jour pour prendre en charge le nouveau mode de stockage. Un audit des extensions actives est un préalable indispensable avant tout essai, même en environnement de test.
Pour qui hésite encore
- Un site avec un faible volume de commandes ne ressentira probablement pas de différence perceptible : le gain se manifeste surtout à partir de plusieurs milliers de commandes historiques.
- Un site fortement dépendant d’extensions tierces anciennes gagnera à attendre que ces extensions confirment explicitement leur compatibilité avec le nouveau mode.
- Un site aux rapports de vente lents, déjà identifiés comme un point de friction, a tout intérêt à tester la bêta dès maintenant sur un environnement de préproduction, la réversibilité du mode limitant le risque d’un premier essai.
Tester une bêta réversible sur un clone de production coûte une après-midi. Attendre qu’elle devienne obligatoire sans l’avoir jamais essayée coûte beaucoup plus cher le jour venu.
En résumé
Le nouveau mode de stockage des commandes en tables personnalisées, encore en bêta optionnelle, montre déjà des gains significatifs sur les rapports de vente agrégés, jusqu’à plus de quatre fois plus rapide sur le cas testé ici. La prudence reste de mise sur la compatibilité des extensions tierces, mais l’essai sur un environnement de test, réversible et sans risque pour la production, semble une démarche raisonnable pour tout site dont les rapports de vente commencent à ralentir.
