Mon PrestaShop est lent : est-ce la faute de l'hébergement ?

Une page lente fait partir des visiteurs : 53 % des visiteurs mobiles quittent un site qui met plus de 3 s à charger (Google, 2017). Quand une boutique PrestaShop ralentit, c'est souvent l'hébergement que l'on accuse en premier, parfois à raison, parfois à tort. Avant d'en changer, vous pouvez mesurer vous-même où part le temps, et savoir si le serveur est en cause.

Où part le temps d'une page#

Quand un visiteur ouvre une page de votre boutique, son attente se fait en deux temps (pour simplifier) : d'abord, le serveur fabrique la page et commence à l'envoyer ; ensuite, le navigateur la télécharge et l'affiche, avec ce qu'elle contient (images, styles, scripts).

Côté serveur, PrestaShop reconstruit chaque page à chaque visite. Il lit des dizaines de fichiers PHP, le langage dans lequel il est écrit. Il envoie aussi des centaines de requêtes SQL à la base de données, où sont rangés les produits, les clients et les commandes. Une requête SQL est une question posée à cette base : le prix d'un produit, son stock, les catégories où il apparaît.

Si la base de données est installée sur un autre serveur que la boutique, chaque requête fait un aller-retour par le réseau. Un seul aller-retour passe inaperçu ; des centaines par page s'additionnent.

Le TTFB, pour « Time To First Byte », est le temps qui s'écoule avant que le serveur envoie le premier octet de la page. Il dépend de l'hébergement : la puissance du serveur, ses réglages, l'emplacement de la base de données. Il dépend aussi du code de la boutique : le thème et chaque module ajoutent leurs calculs et leurs requêtes.

Côté navigateur, le temps d'affichage dépend surtout du poids de la page. Google le mesure avec le LCP, pour « Largest Contentful Paint » : le moment où le plus grand élément visible de la page s'affiche, souvent une image.

Les deux temps comptent pour vos ventes : 0,1 s de chargement en moins, c'est +8,4 % de conversions en e-commerce (Deloitte et Google, « Milliseconds Make Millions », 2020). Une conversion, c'est un visiteur qui passe commande. Mais un hébergement agit surtout sur le premier, celui du serveur.

Mesurer soi-même, en cinq minutes#

Le TTFB se lit dans votre navigateur, sans rien installer : Chrome, Edge et Firefox ont des outils de développement qui détaillent le temps de chaque chargement.

1. Ouvrez une fenêtre de navigation privée. Vous arrivez sur la boutique comme un nouveau visiteur : sans compte client connecté, sans panier.
2. Ouvrez les outils de développement, avec la touche F12 (ou Cmd + Option + I sur Mac), et choisissez l'onglet Réseau.
3. Chargez la page d'accueil de votre boutique. La première ligne de la liste est la page elle-même : cliquez dessus, puis ouvrez l'onglet qui détaille ses temps (« Minutage » ou « Timing », selon la langue et la version). La ligne d'attente de la réponse du serveur, libellée TTFB ou « Waiting for server response » dans certaines versions, donne le TTFB.
4. Recommencez sur une page de catégorie, puis sur une fiche produit.

La première mesure prend cinq minutes ; refaites-la plusieurs fois dans la journée : le matin, à midi, le soir.

Le TTFB mesuré ainsi inclut le réseau : le trajet entre votre ordinateur et le serveur, et le passage par Cloudflare si votre boutique l'utilise. Cloudflare est un service par lequel passent les visiteurs avant d'arriver à la boutique : il la protège contre le spam des robots abusifs et renforce sa sécurité.

Votre mesure vaut pour votre connexion, au moment où vous la prenez. Google publie aussi des données de terrain, mesurées chez les vrais visiteurs de votre boutique qui utilisent Chrome. Pour les lire, ouvrez PageSpeed Insights, l'outil de Google, entrez l'adresse de votre boutique et regardez la section « Découvrez ce que vivent vos utilisateurs ». Elle reste vide si la boutique reçoit trop peu de visites.

Le TTFB y est donné au 75e centile, noté p75 : 75 % des visites ont eu un TTFB égal ou plus court que ce chiffre. Google recommande à la plupart des sites de viser 0,8 s au plus (web.dev, un site de Google). Le TTFB de Google compte aussi l'ouverture de la connexion (redirections, recherche de l'adresse du serveur, chiffrement) : la ligne d'attente de votre mesure est donc un peu plus basse. La même section donne le LCP : si le TTFB est bon mais que le LCP ne l'est pas, le serveur n'est pas le premier en cause.

Les signes qui accusent l'hébergement#

Un TTFB élevé ne suffit pas à accuser l'hébergement, car un module lent le fait monter aussi. Plusieurs signes, pris ensemble, désignent l'hébergement plus sûrement.

• Un TTFB élevé (au-delà de 0,8 s, soit 800 millisecondes), surtout sur une page de catégorie. Une page de catégorie affiche de nombreux produits : elle envoie beaucoup de requêtes à la base de données, et c'est là qu'un serveur lent se fait le plus sentir.
• Un temps qui varie selon l'heure. Sur un hébergement mutualisé, c'est-à-dire un serveur partagé entre de nombreux sites, votre boutique peut ralentir quand les sites voisins sont très visités.
• Un back-office lent. Le back-office n'est pas servi par un cache de pages, qui garde des pages toutes prêtes pour les visiteurs suivants : chaque écran est calculé pour vous. Un back-office lent est souvent le signe d'un serveur trop faible, mal configuré, ou les deux.
• Des imports qui s'arrêtent en route. Un import de produits demande du temps et de la mémoire. Si l'hébergement les limite trop, l'import s'interrompt avant la fin.
• Des tâches planifiées limitées. Les tâches planifiées sont les opérations automatiques de la boutique. Un hébergement qui en limite le nombre ou la fréquence bride ce que la boutique peut faire seule.
• Pas de copie de la boutique pour tester. Sans copie, chaque réglage se teste sur le site en ligne, devant vos clients.
• Un support qui ne connaît pas PrestaShop. Quand la seule réponse à une lenteur est « avez-vous vidé le cache ? », la cause a peu de chances d'être trouvée.
• Une configuration générique. Les mêmes réglages valent pour tous les sites du serveur. La plupart des hébergements s'arrêtent à « le site s'affiche, donc ça marche », et certains limitent même volontairement leurs clients.
• Un matériel bas de gamme. Certains hébergements à petit prix utilisent du matériel bas de gamme : PrestaShop y met plus de temps à fabriquer chaque page.

Les signes qui accusent autre chose#

Un hébergement plus puissant ne règle pas tout. Si seules certaines pages sont lentes, ou si le TTFB est bon mais que l'affichage traîne, cherchez d'abord ailleurs.

• Un module trop gourmand, ou des requêtes mal écrites. Un seul module mal écrit, qui envoie trop de requêtes ou des requêtes mal construites, peut ralentir toute la boutique. Pour le trouver, désactivez les modules un par un sur une copie de la boutique, en mesurant le TTFB à chaque fois.
• Le mode debug resté actif. Le mode debug affiche les erreurs de PrestaShop pendant un développement. Resté actif sur la boutique en ligne, il la ralentit. Il se désactive dans le back-office, sous Paramètres avancés > Performances.
• Des images lourdes. Une photo trop lourde met du temps à arriver, quel que soit le serveur. C'est le LCP qui le montre, côté navigateur, alors que le TTFB peut rester bon. La même photo pèse aussi sur la bande passante, c'est-à-dire sur la quantité de données que le serveur envoie à vos visiteurs. Des images redimensionnées et compressées corrigent ces deux défauts sans toucher à l'hébergement.
• Les robots des moteurs de recherche et des IA. Ils parcourent les pages de la boutique pour les référencer ou pour en recueillir le contenu, et saturent souvent les boutiques : le serveur passe son temps à leur fabriquer des pages, au détriment de vos clients. Un cache de pages absorbe ces visites (étape 4), et Cloudflare, placé devant le serveur, filtre les robots abusifs.

Un exemple réel#

Francopieces vend en ligne des pièces détachées d'électroménager. C'est le premier client d'Orbit, mon offre d'hébergement pour PrestaShop. Le temps que met son serveur à envoyer ses pages a été mesuré à trois moments. Ce temps se compte en millisecondes (ms), c'est-à-dire en millièmes de seconde.

• Avant : 900 ms, sur un hébergement mutualisé grand public très connu.
• Avec Orbit : 320 ms, sur un serveur dédié virtualisé, réglé pour PrestaShop.
• Avec Orbit + Orbit Cache : 7 ms, la page part directement du cache.

Avant : temps mesuré par Google chez les visiteurs de francopieces.com (avril à juillet 2025), moins 100 ms de trajet réseau. Avec Orbit et Orbit Cache : temps serveur médian (la valeur du milieu des mesures) sur toutes les pages, septembre 2026.

Avec Orbit, la boutique tourne sur un serveur dédié virtualisé : une machine virtuelle réservée à elle seule. La configuration du serveur est réglée pour PrestaShop, pas pour tous les sites à la fois.

Orbit Cache est le module de cache de pages que j'ai développé pour PrestaShop. Il fabrique chaque page une fois, puis la sert telle quelle aux visiteurs suivants. Le cache ne sert pas tout : le panier, la commande, le compte client et le back-office sont calculés pour chaque personne. Ces pages-là, c'est l'hébergement qui les accélère.

Le détail est dans la réalisation de Francopieces.

Par où commencer#

Dans cet ordre :

1. Mesurer. Vous relevez le TTFB de l'accueil, d'une catégorie et d'une fiche produit, à plusieurs heures, puis les données de terrain de PageSpeed Insights. Sans ce point de départ, vous ne pouvez pas savoir si un changement a servi.
2. Corriger ce qui vient du code et des modules. Vous coupez le mode debug, allégez les images, remplacez ou corrigez les modules gourmands. Un nouveau serveur ne rattrape pas un module mal écrit.
3. Choisir un hébergement dimensionné pour PrestaShop. Vous cherchez un serveur assez puissant, sur du matériel de qualité, réglé pour PrestaShop et pas seulement pour que le site s'affiche.
4. Mettre en cache les pages publiques. Les pages que tout le monde voit à l'identique, comme l'accueil, les catégories et les fiches produit, n'ont pas besoin d'être reconstruites à chaque visite : un cache de pages les garde prêtes à servir.

Le cache vient en dernier, parce qu'il masque une lenteur sans la corriger : le panier, la commande et le back-office restent aussi rapides, ou aussi lents, que le serveur.

Les étapes 1 et 2 ne demandent pas de changer d'hébergement. Pour l'étape 3, je propose l'hébergement PrestaShop infogéré Orbit : un serveur dédié virtualisé, réglé pour PrestaShop. Pour l'étape 4, Orbit Cache est offert aux clients d'Orbit, et fonctionne aussi sur d'autres hébergements, mutualisés compris, si le serveur remplit les prérequis du module. J'explique ce qu'est un cache de pages dans un article dédié.