Hébergement WooCommerce : dimensionner son hébergement selon le catalogue, les visites et les commandes

Hébergement WooCommerce : pourquoi une boutique ne se dimensionne pas comme un site vitrine

Un hébergement WooCommerce se dimensionne à partir de trois chiffres que vous connaissez déjà : le nombre de produits, déclinaisons comprises, les visites par jour et les commandes par jour. Un site vitrine WordPress sert à tous les mêmes pages, qu’un cache renvoie sans exécuter PHP. Une boutique WooCommerce fabrique à chaque visite des pages propres au client : panier, commande, compte, recherche, stocks. Ces pages passent par PHP et par la base de données à chaque appel, et ce sont elles qui fixent le besoin en ressources.

Ce guide donne une méthode, des paliers indicatifs et les réglages à contrôler avant d’acheter des ressources. Il ne reprend pas le paramétrage de la boutique, couvert par le guide pour configurer WooCommerce et sécuriser le parcours de paiement, ni la méthode de diagnostic d’un ralentissement, décrite dans le guide pour améliorer la performance d’une boutique et traiter les incidents.

Les sept postes qui consomment sur une boutique WooCommerce

• PHP : chaque page non mise en cache occupe un processus PHP-FPM pendant sa génération, souvent de 300 ms à plus d’une seconde.
• Base de données : attributs, variations, prix et stocks lus à chaque affichage ; commandes, sessions et tâches écrites en continu.
• Panier, commande et compte client : exclus du cache par construction, la part la plus coûteuse du trafic, et la plus rentable.
• Recherche et filtres : ils parcourent les tables de métadonnées, lentes au-delà de quelques milliers de produits.
• Extensions : chacune s’exécute à chaque page, qu’elle serve ou non à cette page.
• Tâches planifiées : WP-Cron et l’Action Scheduler de WooCommerce tournent sur les mêmes ressources que vos visiteurs.
• Images : chaque photo envoyée est déclinée en plusieurs tailles, une opération lourde en processeur et en écriture disque.

Ce que consomme réellement une boutique : PHP, base de données, cron et images

Le tableau relie chaque poste à ce qui le fait grossir et à la ressource qu’il sollicite ; la section sur les signes de saturation indique où le constater.

Deux points sont souvent oubliés. D’abord, la base de données grossit même sans nouveau produit : chaque commande, chaque session et chaque action planifiée y écrivent des lignes. Une boutique qui fait 30 commandes par jour depuis trois ans en compte plus de 30 000, à parcourir dès qu’un employé ouvre la liste des commandes. Le stockage des commandes dans des tables dédiées (HPOS, « High-Performance Order Storage »), activé par défaut pour les nouvelles boutiques depuis WooCommerce 8.2, réduit nettement ce coût ; une boutique ancienne doit vérifier qu’elle l’utilise.

Ensuite, les tâches de fond ne sont presque jamais comptées. Un connecteur qui synchronise les stocks toutes les cinq minutes consomme en pleine journée, sur le même compte que les clients qui commandent, et compte dans vos limites comme une visite.

Quel hébergement pour WooCommerce : les paliers selon le catalogue, les visites et les commandes

Il n’existe pas de chiffre universel : 500 produits variables pèsent plus que 5 000 produits simples, et une boutique qui vend par newsletter concentre son trafic en une heure. Les paliers ci-dessous sont des ordres de grandeur observés en général ; retenez le palier le plus élevé atteint par l’un des trois critères, puis ajustez après un mois de mesures.

Estimer la charge réelle : raisonner en pages dynamiques par seconde

Le dimensionnement se fait sur l’heure de pointe, pas sur la moyenne de la journée.

1. Relevez les pages vues sur la meilleure heure du mois dans votre outil de statistiques.
2. Estimez la part qui échappe au cache : panier, commande, compte, recherche, et toute page vue par un visiteur ayant un article au panier ; souvent entre un quart et la moitié.
3. Mesurez trois fois le temps de génération de la page Panier : curl -o /dev/null -s -w "%{time_starttransfer}\n" https://votre-boutique.fr/panier/.
4. Multipliez les pages dynamiques par seconde par ce temps : c’est le nombre moyen de processus PHP occupés. Prévoyez trois à cinq fois cette valeur pour les rafales.

Exemple : 3 000 pages vues sur l’heure de pointe, dont 40 % dynamiques, soit 0,33 page par seconde ; à 900 ms de génération, un processus PHP est occupé en moyenne, donc quatre à cinq à prévoir. Le même calcul montre pourquoi la boutique s’effondre quand une newsletter envoie 2 000 personnes en dix minutes sur une page produit.

Ce qu’un cache ne règle pas : panier, paiement et compte client

Un cache de pages enregistre le HTML d’une page et le renvoie aux visiteurs suivants sans exécuter PHP. Il est très efficace sur l’accueil, les catégories et les fiches produit pour un visiteur anonyme, et il améliore le TTFB et le LCP décrits dans le guide sur la vitesse de site et les Core Web Vitals côté hébergement. Mais il ne peut rien pour ce qui est propre à une personne.

WooCommerce dépose des cookies dès qu’un visiteur ajoute un article : woocommerce_items_in_cart, woocommerce_cart_hash et wp_woocommerce_session_…. Sa documentation sur les caches demande d’exclure les pages Panier, Commande et Mon compte, et la plupart des caches contournent aussi toute page demandée avec ces cookies. Un visiteur qui a un article au panier voit donc toutes ses pages générées par PHP, catégories comprises. Plus votre boutique convertit, plus la part non cachée augmente.

Ce qui reste dynamique quoi qu’il arrive

• Le panier, la commande, le compte client et la page de confirmation.
• Les requêtes ?wc-ajax=… émises par le thème pour rafraîchir le mini-panier, parfois à chaque page.
• Les résultats de recherche, les filtres à combinaisons libres, les webhooks de paiement et toute page vue par un utilisateur connecté.

Dimensionnez donc votre hébergement WooCommerce sur ce trafic dynamique. Le cache allège la vitrine ; il ne remplace jamais les processus PHP et la base de données nécessaires au moment où vos clients paient. Un cache objet (Redis ou Memcached) aide davantage ici, mais il demande un service dédié, disponible en général sur un VPS ou un serveur dédié.

Signes de saturation et où les lire dans Plesk

Sur un hébergement mutualisé ou e-commerce NovaHoster, chaque compte est encadré par CloudLinux : les limites LVE fixent le processeur, la mémoire, les entrées-sorties et les processus disponibles. Le guide pour comprendre CloudLinux, LVE et CageFS explique le mécanisme. Dans Plesk, ouvrez Sites web & domaines, puis la rubrique d’utilisation des ressources de l’extension CloudLinux (le libellé varie selon la version) ; les journaux sont dans Journaux.

Distinguez une limite touchée ponctuellement, pendant une sauvegarde nocturne, d’une limite atteinte chaque jour aux mêmes heures : seule la seconde justifie un changement de palier. Les compteurs d’incidents (« faults ») le montrent mieux qu’une courbe.

PHP-FPM et back-office : les signes hors compteurs

• Le journal PHP-FPM contient server reached pm.max_children setting : toutes les places PHP sont prises, les visiteurs voient des 502 ou 504.
• La liste des commandes ou l’édition d’un produit variable met plus de cinq secondes : la base de données est le goulot, pas le processeur.
• Dans WooCommerce > État > Actions planifiées, les actions en retard se comptent par centaines et les e-mails de confirmation partent en retard : les tâches de fond ne suivent plus.

Réglages à vérifier sur un hébergement WooCommerce avant d’ajouter des ressources

Avant de changer de formule, contrôlez les réglages ci-dessous, dans Paramètres PHP du domaine sous Plesk ou dans wp-config.php, après une sauvegarde. Beaucoup de boutiques signalées comme sous-dimensionnées retrouvent de la marge avec ces seules corrections.

Remplacer WP-Cron par un cron serveur dans Plesk

WordPress exécute ses tâches planifiées au passage d’un visiteur : à 3 h du matin, les e-mails attendent ; à 11 h un jour de soldes, chaque visiteur peut déclencher un lot de traitements. La documentation développeur de WordPress décrit la bascule.

1. Ajoutez dans wp-config.php, avant la ligne « That's all, stop editing » :

   define( 'DISABLE_WP_CRON', true );
   define( 'WP_MEMORY_LIMIT', '256M' );

2. Dans Plesk, Sites web & domaines > Tâches planifiées > Ajouter une tâche, choisissez Exécuter un script PHP, indiquez httpdocs/wp-cron.php et une exécution toutes les cinq minutes (*/5 * * * *).
3. Vérifiez dans WooCommerce > État > Actions planifiées que les actions en retard redescendent dans l’heure.

La constante WP_MEMORY_LIMIT fixe la limite que WordPress s’autorise, indépendamment de celle de PHP : si WooCommerce > État affiche 40 Mo alors que Plesk indique 256M, c’est elle qui manque.

WooCommerce lent malgré des ressources suffisantes : regarder du côté du site

Si les compteurs LVE restent loin des limites et que la boutique est quand même lente, ajouter des ressources ne changera rien : le temps se perd dans le code ou à l’extérieur du serveur. Les causes les plus fréquentes :

• Une extension qui interroge une API externe à chaque page (taux de change, avis, transporteur) et attend sa réponse.
• Un thème ou un constructeur de pages qui charge tous ses modules partout.
• Des options chargées automatiquement dans wp_options qui dépassent plusieurs mégaoctets, lues à chaque requête.
• Une table de l’Action Scheduler jamais purgée, ou la recherche native sur plus de 5 000 produits sans extension d’indexation.

La méthode de tri, extension par extension et page statique contre page dynamique, est dans le guide pour diagnostiquer une boutique e-commerce lente. L’hébergement n’est en cause que si un simple fichier texte posé à la racine du site répond lui aussi lentement.

Quand passer d’un hébergement e-commerce à un VPS ou à un serveur dédié avec infogérance

Le passage à un serveur réservé se décide sur des faits mesurés. Il est justifié quand :

• les limites LVE de processeur ou de processus d’entrée sont atteintes chaque jour ouvré, après application des réglages ci-dessus ;
• la boutique dépasse 50 commandes par jour en régime courant, ou 300 pendant les campagnes, et le back-office devient inutilisable ;
• vous avez besoin d’un service absent du mutualisé : cache objet Redis, moteur de recherche dédié, base de données réglée pour votre volume ;
• vos campagnes multiplient le trafic par dix en quelques minutes.

VPS ou serveur dédié : ce qui change concrètement

Sur un serveur VPS, la boutique dispose de son propre PHP-FPM, de sa propre instance MariaDB et de la mémoire pour un cache objet : c’est le palier d’une boutique en croissance. Les VPS NovaHoster sont hébergés en Roumanie, en Moldavie ou en Russie : si la localisation des données de vos clients dans l’Union européenne est une exigence, vérifiez ce point avant de commander. Le serveur dédié NovaHoster est, lui, hébergé en France (Gravelines, Roubaix ou Strasbourg) avec des ressources matérielles exclusives ; c’est le palier des gros catalogues et des boutiques dont une heure d’arrêt coûte plus que l’abonnement annuel. Le guide pour choisir entre mutualisé, VPS et serveur dédié compare les trois modèles, coûts complets compris.

Dans les deux cas, quelqu’un doit administrer le système : mises à jour de sécurité, surveillance, sauvegardes, intervention de nuit en cas d’incident. C’est le rôle de l’infogérance serveur, incluse chaque année avec un serveur dédié NovaHoster et proposée en option sur VPS. Sans elle, le gain de performance se paie en heures d’administration et en risque de sécurité.

Liste de contrôle avant une campagne : soldes, newsletter, Black Friday

Une campagne ne crée pas de nouveaux problèmes : elle révèle ceux que le trafic habituel masquait. Cette liste se parcourt en deux heures, deux semaines avant la date, puis la veille.

Deux semaines avant

1. Relevez les compteurs LVE du dernier pic : si une limite a été touchée, traitez-la maintenant.
2. Vérifiez la version de PHP, OPcache, memory_limit et le cron serveur.
3. Activez HPOS, purgez les actions terminées de l’Action Scheduler, supprimez les extensions inactives.
4. Mesurez le temps de réponse des pages Panier et Commande avec curl, trois fois : ce sont vos références.
5. Passez une commande de test complète en mode test du prestataire, comme décrit dans le guide pour configurer WooCommerce.
6. Estimez le trafic attendu (base e-mail multipliée par le taux d’ouverture habituel, concentré sur la première heure) et comparez-le au palier de votre formule.

La veille

1. Confirmez qu’une sauvegarde complète et récente existe hors de l’hébergement, et que vous savez la restaurer.
2. Gelez les mises à jour de WordPress, du thème et des extensions jusqu’au lendemain ; déplacez imports et synchronisations hors des heures de la campagne.
3. Vérifiez que le cache de pages est actif sur l’accueil et les catégories, et exclu du panier et de la commande.
4. Prévenez le support 7j/7 depuis l’Espace client avec le domaine, l’heure et le trafic attendu.

Pendant et après

• La première heure, surveillez les compteurs LVE et la page Commande dans une fenêtre privée, toutes les dix minutes. En cas de 503 ou 508 répétés, désactivez d’abord le rafraîchissement wc-ajax du mini-panier si le thème le permet, puis les extensions non indispensables ; ne touchez pas au paiement.
• Le lendemain, comparez la page Panier à vos références et notez le trafic réel : c’est la donnée qui dimensionnera la campagne suivante et, le cas échéant, le changement de palier.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Héberger PrestaShop 9 : prérequis techniques, dimensionnement et migration depuis PrestaShop 1.7 ou 8 — Hébergement PrestaShop 9 : PHP 8.1 à 8.4, extensions, MySQL ou MariaDB, mémoire, Apache ou nginx, ressources selon la boutique et migration…
• Configurer PrestaShop, le paiement et le cache sans casser le panier — Guide NovaHoster pour installer et régler PrestaShop, connecter un paiement, gérer le cache et analyser les erreurs 500, paniers vides et…
• Configurer WooCommerce et sécuriser le parcours de paiement — Configurez WooCommerce, testez le paiement et diagnostiquez les erreurs de commande, de certificat, d’API et de retour après paiement sur…
• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase — Changer d’hébergeur WordPress sans perdre son référencement : préparation, copie, test, bascule DNS avec TTL abaissé, vérifications SEO et…

Sources techniques

[1] WooCommerce — Server Requirements [2] WooCommerce — Configuring Caching Plugins [3] WordPress Developer Resources — Hooking WP-Cron Into the System Task Scheduler [4] WordPress Developer Resources — Editing wp-config.php [5] Plesk — Customer’s Guide : PHP Settings