SiteGround ou Infomaniak pour accélérer WooCommerce sans partager les paniers ?

Définir ce que le cache peut partager

Une boutique WooCommerce veut réduire le temps de réponse de ses catégories et fiches produit. Deux visiteurs peuvent recevoir le même catalogue si le prix, le stock affiché et le contenu sont identiques pour eux. Dès que la réponse contient un panier, une adresse, des commandes ou des moyens de paiement calculés pour la session, elle doit rester propre au visiteur. Une page qui s’affiche plus vite peut masquer une erreur si elle reprend un ancien panier ou le contenu préparé pour quelqu’un d’autre.

Le point de départ est la liste des pages assignées dans WooCommerce, avec leurs URL réelles. Une boutique peut appeler ses pages `/panier/`, `/mon-compte/` et `/commande/`, ou utiliser d’autres chemins et langues. Relevez aussi les routes qui découlent de ces pages, par exemple l’affichage d’une commande ou la modification d’une adresse. Les libellés utilisés par un hébergeur dans ses règles ne donnent pas à eux seuls la preuve que toutes les variantes de la boutique sont couvertes.

Précisez ce que contient la vitrine. Un catalogue public peut afficher un mini-panier via une requête séparée. Si le HTML contient déjà un panier, un tarif réservé à un rôle ou un prix propre à une devise, le même document ne convient plus à tous les visiteurs. Il faut alors séparer la partie personnalisée, exclure les visiteurs concernés ou utiliser une variante de cache que l’équipe sait vérifier. Ce comparatif part d’une vitrine anonyme commune et de trois routes dynamiques propres à la session.

Identifier chaque cache qui peut répondre

Un cache de page réutilise une réponse HTML. Un cache d’objets réutilise des données que l’application a calculées ou lues. Le navigateur et un CDN peuvent aussi conserver des réponses. Une règle correcte dans l’extension WordPress ne couvre que ce que cette extension contrôle. Si un CDN ou un proxy peut réutiliser la réponse avant que WordPress ne s’exécute, vérifiez également les règles de cette couche et l’ordre de purge.

Inventoriez pour chaque couche son opérateur, ses indices de diagnostic et la façon de retirer une réponse mise en cache. Sur le catalogue, l’équipe cherche un premier chargement puis une réponse réutilisée, avec un prix et une disponibilité conformes. Pour le panier, le compte et le paiement, elle cherche une réponse dynamique dont le contenu correspond à la session. Le statut de cache et le contenu doivent être vérifiés ensemble. Une réponse issue de l’application peut encore être incorrecte à cause d’une session, d’une extension ou d’un cache d’objets.

Faites un relevé avant d’ajouter une extension ou d’activer un CDN. Notez les cookies présents sur une session sans panier, après un ajout et après connexion. La documentation WooCommerce décrit notamment les cookies liés au panier et à sa session. Utilisez deux profils de navigateur indépendants pour éviter qu’ils partagent des cookies ou des données locales. Toute preuve qui contient un identifiant de session doit rester dans un journal privé et être expurgée avant diffusion.

SiteGround part d’un cache de page serveur actif

SiteGround décrit Dynamic Caching comme un cache de page entière NGINX actif par défaut. Sa documentation répertorie des exclusions par URL et par cookie. Elle cite notamment `cart`, `my-account`, `checkout` et `add-to-cart`, ainsi que les cookies `wordpress_logged_in_`, `wp_woocommerce_session` et les cookies de panier. Les motifs documentés constituent un point de départ. Vérifiez le résultat sur les chemins réels, y compris leurs traductions et les extensions qui ajoutent un parcours de paiement ou un accès client.

Dans WordPress, la documentation actuelle situe les exclusions dans Speed Optimizer, rubrique Caching, puis Exclude URLs from Caching. Cette option couvre Dynamic Caching et le cache par fichiers du plugin. Comparez les chemins affichés dans WooCommerce avec les exclusions. Si le compte est réellement à /mon-compte/, vérifiez ce chemin et ses sous-routes. L’interface permet de saisir le chemin exact et d’utiliser un astérisque pour les sous-chemins, par exemple /mon-compte/*. Testez les deux cas après purge. Le cache par fichiers est désactivé par défaut et dépend du Dynamic Caching chez SiteGround. Laissez cette couche hors du premier essai si vous voulez isoler le fonctionnement du cache serveur. Memcached demande une activation dans Site Tools puis dans le plugin et concerne le cache d’objets.

Pour lire la couche serveur, SiteGround documente `x-proxy-cache` et les valeurs `HIT`, `MISS` et `BYPASS`. Après une purge, une page éligible peut produire `MISS` puis `HIT` à requête comparable. Pour le privé, contrôlez qu’une réponse ne passe jamais en `HIT` et contient les données du bon client. Les purges se trouvent dans Speed Optimizer et dans Site Tools sous Speed puis Caching. Si un CDN est actif, identifiez ses propres règles, car une exclusion dans le plugin ne démontre pas son comportement.

Infomaniak sépare le cache applicatif de l’option Varnish

Sur l’Hébergement Web Infomaniak, le guide d’optimisation présente un cache via extension WordPress et cite notamment WP Super Cache. Cette extension génère des fichiers HTML. WooCommerce documente son intégration pour exclure les pages assignées au panier, au paiement et au compte. Vérifiez néanmoins les URL réelles, les extensions de la boutique et les requêtes personnalisées. Sur cette offre, commencez par vérifier les réglages et le diagnostic de l’extension installée. L’en-tête SiteGround ne constitue pas une référence pour ce parcours.

Le Serveur Cloud Managé ouvre un autre parcours. Infomaniak liste Varnish dans Fast Installer et fournit un exemple de configuration VCL avec un serveur d’origine et une purge restreinte. Pour la redirection du trafic web vers un port applicatif, le guide distinct demande un site et HAProxy. Il indique que la configuration dans Fast Installer vise le domaine principal, avec un traitement séparé des alias. Vérifiez le chemin réellement suivi par les requêtes avant d’écrire une règle. L’installation du logiciel ne confirme ni son passage dans le circuit HTTP ni la présence d’une politique WooCommerce prête à l’emploi.

Dans ce parcours Cloud, désignez un responsable des règles VCL et de la purge. Examinez le passage sans cache des chemins privés, des requêtes authentifiées et des actions qui modifient la session. Conservez les cookies et en-têtes dont le paiement dépend. Redis et Memcached figurent parmi les possibilités du Serveur Cloud. Leur disponibilité ne fournit pas d’exclusion HTML. Si un cache d’objets est ajouté, testez à part la continuité des sessions et l’actualisation des données.

Comparer les offres sur la même durée

La grille française SiteGround consultée le 10 novembre affiche StartUp à 1,99 EUR par mois au départ et 15,99 EUR par mois au renouvellement, GrowBig à 3,99 puis 27,99 EUR et GoGeek à 5,99 puis 39,99 EUR. Sur douze mois, les totaux affichés ou calculés sont de 23,88 puis 191,88 EUR, 47,88 puis 335,88 EUR, et 71,88 puis 479,88 EUR, hors taxes. Confirmez le prix d’entrée du récapitulatif, car la grille de promotion peut varier. Le tarif d’entrée est un équivalent mensuel sur douze mois payés d’avance. Le tableau officiel de prix réguliers dépend aussi de la durée prépayée. Le renouvellement partagé est annuel par défaut et SiteGround indique une facturation automatique quinze jours avant échéance pour une période de douze mois ou plus.

Le cache multiniveau est annoncé sur les trois forfaits WordPress de cette grille. GrowBig et GoGeek affichent le staging intégré. GrowBig sert donc de repère lorsque l’équipe veut utiliser cet outil pour vérifier les exclusions avant de toucher à la boutique en ligne. Sur StartUp, l’équipe doit prévoir un environnement de test séparé si elle a besoin d’une copie. Faites figurer le coût de cet environnement et des extensions éventuelles dans la comparaison.

La grille suisse Infomaniak affiche l’Hébergement Web dès 10,91 CHF par mois et le Serveur Cloud Managé dès 38,41 CHF par mois, hors TVA. Sur douze mois, ces repères représentent 130,92 CHF et 460,92 CHF par multiplication du prix affiché. Le mutualisé est facturé annuellement par défaut. Le mensuel et le trimestriel dépendent d’un seuil, et la configuration Cloud influe sur la facture. La grille ne sépare pas un prix promotionnel d’un prix garanti au renouvellement. Le Manager indique l’échéance effective. Lorsque l’automatisme est activé, la première tentative de paiement est annoncée quatorze jours avant cette date. Gardez les devises et les taxes distinctes jusqu’au devis.

Protéger aussi les actions de panier et de paiement

Lisez les requêtes réseau lorsque les deux sessions ajoutent un article, changent une quantité, se connectent et arrivent au paiement. Selon le thème et les blocs, un écran utilise le HTML initial et des appels qui rechargent le mini-panier, la livraison ou les moyens de paiement. Vérifiez les appels qui transportent des jetons, un corps de requête ou des cookies, ainsi que ceux qui retournent des données propres au client. Une exclusion du document HTML ne protège pas automatiquement ces réponses.

Pour une boutique qui utilise la Store API WooCommerce, distinguez les routes publiques de produits des routes de panier et de commande. Relevez les appels réellement émis, par exemple /wp-json/wc/store/v1/cart et /wp-json/wc/store/v1/checkout. La lecture GET du panier est aussi propre à la session. La documentation précise que les écritures `POST` du panier et les requêtes de paiement de la Store API demandent un nonce, ou utilisent un Cart-Token selon le parcours. Évitez de partager les réponses de session ou de supprimer les en-têtes nécessaires. Vérifiez aussi les appels classiques de mise à jour du panier et de validation de la commande si votre boutique les utilise. Gardez la validation des jetons active lors des tests.

Testez enfin les extensions qui modifient le prix, les taxes ou le stock. Un catalogue identique à froid et à chaud doit être valide pour le public auquel il est servi. Si le prix dépend du client ou de sa devise, testez des états différents sur les deux sessions. Puis changez une donnée de test, purgez la couche concernée et vérifiez que catégorie, fiche produit et panier deviennent cohérents. Cette vérification couvre la fraîcheur du prix en plus de la séparation des visiteurs.

Ce que montrent les deux sessions fictives

Dans l’exercice, deux URL de catalogue anonymes ont chacune leur clé. Une première lecture produit `MISS`, la seconde `HIT`. Le prix de la lampe passe de 24 à 29 dans la boutique fictive. Une réponse peut encore montrer l’ancien prix tant que la copie reste en mémoire. Après la purge, la lecture retrouve 29 et les lectures suivantes réutilisent cette version. Une URL avec paramètre est écartée du cache dans le modèle, de même que la vitrine demandée avec une session. Ce choix rend le test simple et ne prescrit pas une politique générale pour toutes les boutiques.

Les sessions A et B ajoutent chacune leur article fictif. On lit les trois routes dans l’ordre A, B, A, avec des références de commandes différentes. Le contrôle vérifie le contenu exact, l’état `BYPASS` et l’en-tête `private, no-store`. Il refuse ensuite un jeton de A présenté par B, enregistre un paiement simulé par session, puis vérifie que la modification du panier de A ne change rien au panier de B. Le candidat conforme passe vingt et un contrôles.

Dans la variante défectueuse, une règle traite les trois GET privés comme des réponses partageables. B obtient trois `HIT` et reçoit le panier, la référence de commande et le formulaire de paiement fictifs de A. Les résultats sont reproductibles dans Python avec des objets en mémoire. Il n’y a ni serveur HTTP, ni installation WooCommerce, ni test de performance fournisseur. Les jetons sont des marqueurs de session destinés uniquement à démontrer le risque et les paiements restent des compteurs locaux.

• Téléchargez la maquette ZIP dans « Pour aller plus loin », extrayez l’archive puis exécutez python exercice.py.
• Comparez les 21 contrôles et les trois réponses privées de la règle défectueuse au fichier attendu.json.

Rejouer le parcours sur une copie chez le fournisseur

Utilisez une copie isolée qui reproduit les URL, les extensions actives, le thème, le protocole et les couches de cache de la boutique. Préparez deux clients fictifs aux contenus faciles à distinguer, par exemple une lampe et une tasse, avec deux commandes de test. Utilisez des profils de navigateur indépendants. Préparez le prestataire de paiement en mode bac à sable et coupez les notifications clients réelles. Mesurez séparément le catalogue froid puis chaud et consignez la couche qui répond. Gardez constants l’URL, le profil anonyme et les paramètres de mesure.

Dans chaque session, ajoutez un article, ouvrez le panier, changez la quantité, puis vérifiez le compte et le paiement. Alternez A, B, A et rechargez les écrans après navigation arrière. Vérifiez que le mini-panier, les frais de livraison et les moyens de paiement correspondent à la bonne session. Rejouez l’accès aux sous-routes de compte, les appels asynchrones, la confirmation et le retour du bac à sable. Vérifiez l’état de la commande dans la boutique de test. Une modification de prix ou de stock sur la copie doit aussi se propager à la vitrine au moment prévu.

Chez SiteGround, relevez `x-proxy-cache` et la présence d’un autre cache en amont. Chez Infomaniak, relevez l’indicateur de l’extension choisie ou celui que l’équipe a configuré pour Varnish et confirmez que le trafic l’atteint. Si les en-têtes et les marqueurs se contredisent, recherchez la couche qui a fourni la réponse avant de conclure. Notez dans le relevé le chemin, l’action, la session de test, le contenu attendu et le résultat. Ne copiez pas les jetons, cookies ou données personnelles.

Décider quoi purger et quand arrêter le test

Un contenu de A visible chez B, une donnée privée servie par un cache partagé ou une commande de test dont le statut diverge suffisent pour arrêter l’essai. Retirez la règle qui met ces réponses en cache et purgez les couches où elles ont pu être conservées. Conservez une trace expurgée de la cause. Vérifiez ensuite les trois routes et les appels associés dans des sessions neuves avant de réactiver une optimisation. Un catalogue chaud n’est utile que si ces contrôles passent.

Lorsque la séparation tient mais qu’un prix reste ancien, relevez la couche qui a servi la copie et vérifiez comment le changement de produit déclenche sa purge. Un prix juste sur la fiche et obsolète dans la catégorie indique que les deux représentations ont des cycles de mise à jour différents. Vérifiez aussi le mini-panier, qui peut être alimenté par un appel séparé. N’ajoutez une nouvelle couche que lorsque vous pouvez identifier son rôle et le moyen de l’invalider.

SiteGround convient à une équipe qui veut vérifier et ajuster un cache serveur déjà fourni. L’intérêt de GrowBig dans ce scénario tient à la présence du staging et aux essais que l’équipe peut y mener. L’Hébergement Web Infomaniak convient à une équipe qui veut gérer le cache de page au niveau de WordPress. Le Serveur Cloud Managé ouvre la voie à Varnish si quelqu’un peut administrer ses règles et son routage. La décision dépend de la facture à l’échéance et du résultat du parcours complet sur la copie.

Pour aller plus loin

• Consulter la fiche SiteGround
• Consulter la fiche Infomaniak
• Diagnostiquer un panier WooCommerce vide ou obsolète
• Télécharger la maquette de cache WooCommerce (ZIP)