Test performance hébergement : comment tester la performance de son hébergement PrestaShop

Tester la performance d’un hébergement PrestaShop consiste à mesurer, sur des pages représentatives de votre boutique, ce qui relève du réseau (DNS/TCP/TLS), du temps de réponse serveur (TTFB) et du traitement applicatif (PHP, base de données, caches, modules). L’objectif n’est pas d’obtenir “un score”, mais de produire un diagnostic exploitable : quoi corriger, dans quel ordre, et à partir de quel seuil il faut changer de gamme ou d’architecture pour votre site e-commerce.

Si votre enjeu est aussi de choisir une offre adaptée (et donc de relier mesures et dimensionnement), cette page vous sera utile : hébergement PrestaShop ETHERSYS.

Dans la suite, vous allez mettre en place un protocole de test reproductible, comparer des résultats “à froid / à chaud”, isoler les causes (réseau vs serveur), puis traduire les symptômes en solutions concrètes. Vous pourrez ensuite piloter votre performance dans la durée, avec des seuils et des alertes cohérents avec un SLA.

Prérequis et préparation

Outils de mesure et accès serveur

Pour un test performance hébergement crédible, il vous faut à la fois des mesures côté client (navigateur/sonde) et une visibilité côté serveur. Sans la deuxième partie, vous verrez “que c’est lent” sans savoir pourquoi.

Outils côté client (simples et fiables) :

• Un test “boîte noire” depuis plusieurs zones : WebPageTest (utile pour décomposer DNS/TCP/TLS/TTFB et répéter les runs).
• Un test orienté bonnes pratiques et métriques perçues : PageSpeed Insights (utile pour croiser backend et chargement perçu).
• Un outil de vérification bas niveau : curl (idéal pour mesurer le TTFB hors navigateur et automatiser) accessible en ligne de commande.

Accès côté serveur (au minimum) :

• Accès aux logs web (Nginx/Apache) et aux logs PHP (erreurs, lenteurs si configurées).
• Accès à des métriques CPU/RAM/IO disque (SSD NVMe ou non, saturation, iowait).
• Accès aux paramètres PHP (OPcache, memory_limit, max_children / workers).

Temps estimé et niveau de difficulté

Comptez 60 à 120 minutes pour un premier passage sérieux (sans optimisation), puis 15 à 30 minutes pour rejouer le protocole après chaque changement. Niveau : intermédiaire si vous avez un accès d’administration (hébergeur/infogérance), avancé si vous devez instrumenter finement PHP et la base de données.

Checklist avant de mesurer (versions, caches, logs, sauvegarde)

Avant de lancer des tests, verrouillez le contexte. Sinon, vos résultats deviendront impossibles à interpréter, surtout sur une boutique avec des pics (campagnes, e-commerce B2B, ventes flash, etc.).

• Versions : version PrestaShop, version PHP, moteur de base de données, version HTTP (HTTP/2 ou HTTP/3).
• Caches : cache PrestaShop, OPcache, cache objet (Redis/Memcached si présent), cache HTTP (Varnish si présent), CDN éventuel.
• Logs : activer un niveau de logs suffisant pendant la fenêtre de test (sans noyer le disque).
• Sauvegarde : snapshot ou sauvegarde récente avant tout changement de configuration serveur (sécurité opérationnelle).
• Données : travaillez avec un catalogue représentatif (images, déclinaisons, règles promo) ; sinon, vous “optimisez” un cas fictif.

Transition utile : une fois le contexte stabilisé, vous pouvez choisir les pages à tester et définir des scénarios proches du réel (navigation, panier, paiement).

Lancer un test de performance d’hébergement (protocole reproductible)

Choisir des pages clés et des scénarios panier

Un bon protocole couvre les étapes qui font réellement du chiffre : découverte produit, ajout au panier, tunnel de commande, et une page dynamique liée au compte client. Sur PrestaShop, les écarts de performance viennent souvent de la combinaison “modules + base de données + sessions + panier”.

Jeu de pages recommandé :

• Accueil (cacheable partiellement, forte exposition).
• Catégorie chargée (tri, pagination, facettes).
• Fiche produit (images, prix, déclinaisons, cross-sell).
• Panier (calculs, transporteurs, promos).
• Commande et étape de paiement (pages critiques, sensibles aux latences et aux appels tiers).

Astuce de terrain : testez une fiche produit “simple” et une fiche produit “pire cas” (déclinaisons, règles de prix, modules marketing). Le différentiel aide à attribuer la lenteur à l’application plutôt qu’au serveur.

Répéter les tests à froid et à chaud

Réalisez systématiquement deux séries :

• À froid : cache navigateur vide + purge ciblée (si c’est votre protocole) + première requête après inactivité.
• À chaud : même page, même scénario, après plusieurs hits (cache applicatif/OPcache “chauffés”).

Pourquoi c’est critique : un hébergement peut paraître “rapide” à chaud mais s’effondrer à froid (OPcache mal dimensionné, cache HTTP absent, I/O disque au démarrage), ce qui pénalise vos utilisateurs et vos robots.

Gabarit simple pour mesurer DNS, TCP, TLS, TTFB

Pour éviter les interprétations approximatives, isolez les composantes réseau et serveur. Avec curl, vous obtenez une mesure “propre” hors rendu navigateur.

curl -o /dev/null -s -w "DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" https://votre-boutique.exemple/

Lecture rapide :

• DNS : résolution (peut varier selon le resolver, la zone, la configuration).
• TCP : établissement de connexion.
• TLS : négociation HTTPS.
• TTFB : premier octet reçu (inclut réseau + temps serveur avant réponse).

Mesurer le TTFB et la latence réseau (et séparer les causes)

Comparer plusieurs zones de test

Testez au minimum depuis :

• France (proche de votre serveur si hébergé en France).
• Europe (ex. Allemagne/Pays-Bas).
• Amérique du Nord si vous avez du trafic international.

Interprétation : si la latence réseau explose seulement depuis certaines zones mais que le TTFB “serveur” semble stable, vous avez un enjeu de distance, de peering, de CDN ou de stratégie DNS. Si tout est lent partout, vous êtes probablement sur un goulot serveur/PHP/base de données.

Isoler réseau versus traitement serveur

Une règle opérationnelle utile : si DNS + TCP + TLS sont raisonnables mais que le TTFB est élevé, la lenteur se joue souvent sur le serveur (PHP, requêtes SQL, cache, verrouillage, files d’attente). À l’inverse, si TCP/TLS sont anormalement hauts, vous avez un problème de réseau, de saturation, ou de configuration TLS.

Pour approfondir les mécanismes côté serveur (PHP et OPcache), la documentation officielle reste une référence : manuel PHP OPcache.

Schéma de lecture d’une requête (du client au PHP)

Chaîne typique impactant le temps de réponse et le chargement

1. Client → demande l’URL
2. DNS → résout le nom de domaine
3. TCP → ouvre la connexion
4. TLS → sécurise la session HTTPS
5. Serveur web (Nginx/Apache) → route la requête
6. PHP → exécute PrestaShop + modules
7. Base de données → requêtes sur vos données
8. Réponse → premier octet (TTFB), puis corps HTML/JSON

À ce stade, vous savez “où” se situe le problème. La section suivante vous aide à prouver “quoi” sature, surtout lors des pics (campagnes, annonces, newsletters, retours de stock).

Analyser la charge serveur et PHP (CPU, RAM, disque, workers)

Suivre CPU, RAM et disque pendant les pics

Sur un serveur, la lenteur ne vient pas uniquement du CPU. Une boutique peut être pénalisée par :

• RAM insuffisante (swap, évictions de cache, OPcache inefficace).
• Disque saturé (I/O, iowait, logs, sessions, images, index SQL).
• CPU à 100% (calculs, compression, requêtes complexes, pics concurrentiels).

Ce diagnostic est indispensable si vous comparez des offres et tarifs : une offre “moins chère” peut coûter plus cher au final si elle introduit des saturations en production (perte de conversion, paniers abandonnés, erreurs au paiement).

Vérifier OPcache et limites PHP

Sur PrestaShop, OPcache est souvent un levier majeur : il réduit le coût de compilation des scripts PHP. Points de contrôle concrets :

• OPcache actif et dimensionné (mémoire, nombre de fichiers, fréquence de revalidation).
• Limites PHP cohérentes : memory_limit (éviter les erreurs en back-office), max_execution_time (éviter les timeouts), limites d’upload si catalogue/exports.
• Sessions : stockage et latence (fichiers vs stockage en mémoire), surtout sur panier/commande.

Erreur fréquente : augmenter uniquement la mémoire PHP sans traiter la cause (requête SQL lente, module bavard, cache absent). Vous masquez le symptôme sans améliorer durablement la performance.

Contrôler les workers web et les files d’attente

Une boutique peut être “rapide” en test unitaire et “lente” en trafic réel si elle manque de capacité concurrentielle :

• Workers PHP (FPM) ou processus : trop peu → files d’attente et TTFB qui grimpe ; trop → saturation RAM/CPU.
• Limites serveur web (connexions, keep-alive, buffers) : impact sur les pics.
• Services annexes : indexation, recherche (ex. moteur externe), cache objet, file de messages si vous en utilisez.

Point de vigilance : cron, tâches planifiées et modules

Les tâches cron et certains modules (synchronisation, exports, recommandations, tracking, e-mails) peuvent déclencher des pics CPU/IO qui dégradent le front. Si votre lenteur apparaît “à heure fixe”, commencez par corréler :

• heure du ralentissement
• lancement cron / tâches planifiées
• augmentation CPU/RAM/IO
• pics d’erreurs dans les logs

Dans un contexte e-commerce, c’est un point clé : une tâche back-office mal planifiée peut dégrader le tunnel et impacter directement le paiement.

Valider, comparer et mettre sous surveillance (SLA, seuils, alertes)

Définir des seuils réalistes (SLA et alertes continues)

Un bon seuil est un seuil actionnable. Pour PrestaShop, vous pouvez définir des objectifs par type de page (accueil, fiche produit, panier, commande) et des alertes sur des indicateurs simples :

• TTFB (par page clé, par zone)
• Taux d’erreurs (5xx, timeouts)
• Saturation (CPU, RAM, iowait, files d’attente)

Ajoutez une nuance utile : le “bon” seuil dépend de votre catalogue, de vos modules, de votre trafic et des appels tiers (paiement, anti-fraude, transporteurs). L’important est de surveiller la dérive et de détecter les régressions après mise à jour.

Comparer avant/après sur des pages identiques

Pour que la comparaison soit crédible :

• Gardez le même protocole (mêmes pages, mêmes zones, même nombre de répétitions).
• Notez chaque changement (config, version, activation/désactivation de cache, mise à jour de modules).
• Comparez “à froid” et “à chaud”.

Astuce : dans votre compte-rendu, séparez mesures réseau (DNS/TCP/TLS) et mesures serveur (TTFB, saturation). Cela accélère la prise de décision côté gestion (budget, offre, priorisation des actions).

Matrice de diagnostic : symptômes lents → correctifs typiques

Angle “pilotage moderne” utile : au-delà du SEO classique, surveillez aussi la capacité de vos pages clés à être résumées correctement (pages stables, réponses produits claires, données structurées cohérentes). Un serveur instable (latence, erreurs, timeouts) réduit la récupération fiable des contenus par des systèmes d’indexation et de réponses synthétiques.

Diagnostic temps de réponse : questions fréquentes

Quels seuils viser pour le TTFB sur PrestaShop ?

Comme repère opérationnel, visez un TTFB faible et stable sur les pages critiques (fiche produit, panier, commande) et surtout sans dérive en période de trafic. Si votre TTFB fluctue fortement, traitez d’abord la cause (files d’attente, saturation, cache) avant de chercher un “chiffre parfait”. L’important est de fixer un seuil interne (SLA) et d’alerter avant l’impact business.

Comment distinguer un module lent d’un hébergeur en cause ?

Comparez : (1) une page “simple” vs une page “pire cas”, (2) une mesure à froid vs à chaud, et (3) la charge serveur pendant le test. Si le CPU/RAM/IO sature dès que vous activez certains modules ou scénarios (panier, règles de prix, recherche), la cause est souvent applicative. Si la saturation apparaît même sur des pages simples, ou si vous observez une file d’attente (workers), le dimensionnement et la configuration serveur sont plus probablement en cause.

Quels caches serveur aident le plus PrestaShop ?

En pratique, les gains les plus fréquents viennent de l’OPcache (PHP), d’un cache HTTP quand il est applicable (pages publiques), et d’un cache objet si votre stack le supporte et si votre boutique en tire profit. Attention : sur panier/commande (sessions, personnalisation), il faut un cache finement contrôlé pour éviter des incohérences de données.

Quand passer d’un mutualisé à une solution plus adaptée (VPS ou managé) ?

Dès que vous ne contrôlez plus les goulots (workers, RAM, I/O) et que les pics de trafic dégradent panier/commande, vous avez besoin d’une solution où la capacité et l’exploitation sont maîtrisées. Le vrai signal n’est pas “le nombre de visites” seul, mais la combinaison : complexité des modules, poids du catalogue, exigences de disponibilité, et sensibilité au paiement. Si votre activité dépend d’un tunnel stable, privilégiez une offre managée/infogérée avec SLA, supervision et délais d’intervention clairs.

Prochaine action recommandée : choisissez 5 pages clés, exécutez vos tests à froid et à chaud depuis 2 à 3 zones, puis classez vos résultats dans la matrice ci-dessus pour décider si vous devez optimiser (cache, PHP, modules) ou redimensionner votre hébergement.