Checklist de performance avant la mise en ligne d’une boutique WooCommerce

Une checklist de performance générale, pensée pour un site vitrine, ne couvre pas les zones les plus sensibles d’une boutique WooCommerce : le panier, le compte client et le tunnel de commande sont par nature dynamiques, ne peuvent pas être mis en cache de la même façon que le reste du site, et concentrent pourtant l’essentiel de la valeur commerciale d’un abandon évité. Cette checklist se concentre sur ces vingt points spécifiques, à vérifier avant l’ouverture au public d’une nouvelle boutique ou d’une refonte, en complément (et non à la place) d’une checklist générale de performance qui reste pertinente pour le reste du site.

Pages produit

1. Vérifier que l’image principale de chaque type de fiche produit porte l’attribut fetchpriority="high" ou équivalent pour prioriser le LCP.
2. Contrôler que les variations de produit (taille, couleur) ne provoquent pas de décalage visuel (CLS) au chargement du sélecteur.
3. Vérifier la taille des images de galerie produit : un format WebP ou AVIF avec des dimensions adaptées à l’affichage réel, pas l’image source brute.
4. Confirmer que le compteur de stock et le prix ne déclenchent pas d’appel Ajax synchrone bloquant l’affichage initial de la page.
5. Tester le temps de génération d’une fiche produit avec de nombreuses variations (au-delà de trente), cas souvent oublié en recette avec des produits de test simplifiés.

Cache et exclusions

1. Vérifier explicitement que les pages /panier/, /mon-compte/ et /commande/ sont exclues du cache de page, pas seulement supposées l’être par défaut par l’extension de cache.
2. Contrôler que les cookies de session WooCommerce (woocommerce_cart_hash, wp_woocommerce_session_) déclenchent bien le contournement du cache côté serveur (Varnish, FastCGI cache) et pas seulement côté extension PHP.
3. Vérifier qu’un visiteur avec un panier non vide ne voit jamais un fragment de page mis en cache pour un autre visiteur (test avec deux sessions simultanées dans deux navigateurs différents).
4. Confirmer que le mini-panier et le compteur d’articles dans l’en-tête se rafraîchissent bien après un ajout, sans nécessiter un rechargement complet de page.

Tunnel de commande et paiement

1. Mesurer le temps de réponse de la page de paiement sous une charge simulée d’au moins cinquante commandes simultanées avec k6, avant l’ouverture, pas après un premier pic réel.
2. Vérifier que l’intégration de la passerelle de paiement ne charge pas de script bloquant sur toutes les pages du site, mais uniquement sur la page de paiement elle-même.
3. Contrôler le temps de traitement d’une commande côté serveur (création de la commande, envoi de l’e-mail de confirmation), en particulier si des extensions tierces s’accrochent au hook woocommerce_thankyou.
4. Vérifier que l’envoi des e-mails de confirmation de commande ne bloque pas la réponse HTTP au client (utilisation d’Action Scheduler ou d’une tâche différée plutôt qu’un envoi synchrone).
5. Tester le comportement du site en cas d’échec de la passerelle de paiement : un délai d’attente mal configuré peut faire percevoir le site entier comme lent alors que seul le prestataire de paiement répond mal.

Base de données et volumétrie

1. Vérifier l’indexation des tables personnalisées liées aux commandes si le site utilise le stockage haute performance des commandes (HPOS), disponible depuis WooCommerce 8.2.
2. Contrôler la taille de la table wp_options et l’absence d’options avec autoload activé inutilement volumineuses, un piège classique après l’installation de plusieurs extensions boutique.
3. Simuler un volume de catalogue réaliste en recette (pas dix produits de démonstration mais le volume réel attendu à l’ouverture) avant de valider les temps de réponse des pages de catégorie.

Supervision post-ouverture

1. Mettre en place une alerte sur le taux d’erreur du tunnel de commande (paiements refusés côté serveur, erreurs 500 sur /commande/), distincte d’une alerte générale de disponibilité du site.
2. Vérifier que les journaux WooCommerce (WC_Logger) sont accessibles et suivis dès le premier jour, pas configurés a posteriori après un premier incident.
3. Programmer un contrôle de charge à J+7, une fois le trafic réel observé, pour ajuster les ressources serveur si le volume constaté dépasse les hypothèses de recette.

Une checklist générale de site vitrine rassure sur l’essentiel, mais elle n’a jamais eu à se demander ce qui se passe quand cinquante visiteurs valident un panier au même instant.

Ce que cette checklist ne couvre pas

Cette liste se concentre strictement sur la performance du tunnel commercial. Elle ne traite ni la sécurité de la boutique (protection contre la fraude au paiement, conformité PCI-DSS déléguée au prestataire de paiement) ni son référencement (structuration des données produit, sitemaps), deux sujets traités séparément et tout aussi importants avant une ouverture au public.

En résumé

Sur les projets où cette checklist a été appliquée avant ouverture, les points les plus souvent oubliés en pratique restent l’exclusion explicite du cache pour le panier et le compte client, et le test de charge du tunnel de commande avant plutôt qu’après le premier pic de trafic réel. Les deux se vérifient en une demi-journée et évitent le scénario le plus coûteux : une boutique qui s’ouvre, attire du trafic, et perd des ventes sur le seul écran où l’argent change réellement de main.