On a vu un site PrestaShop perdre 18 % de ses conversions sur mobile depuis l’outre-mer. Le panier était plein, le trafic là, mais le checkout était une passoire à Core Web Vitals. Le responsable ? Ni le thème, ni l’hébergement : les règles de livraison DOM-TOM. Derrière chaque code postal de Guadeloupe ou de Guyane, PrestaShop mobilisait une cascade de calculs de poids, de zones, de surtaxes, le tout exécuté pendant le chargement de la page. Résultat, un LCP qui tutoyait les 8,4 secondes sur une simple fiche produit avec estimateur de frais. Voici ce qu’on a trouvé dans les logs, et comment on a corrigé le tir sans toucher aux transporteurs historiques.
La plomberie obscure du calculateur de livraison PrestaShop
PrestaShop détermine les frais de port en croisant quatre paramètres : la zone géographique, la tranche de poids, le transporteur sélectionné, et les éventuelles surcharges définies dans le back-office. Pour les DOM-TOM, les boutiques multiplient souvent les transporteurs locaux (Colissimo Outre-Mer, transporteurs maritimes, points relais spécifiques), chacun avec ses propres grilles tarifaires par tranche de 100 grammes. Une commande type vers Saint-Pierre-et-Miquelon peut déclencher jusqu’à 200 requêtes SQL si le cache des transporteurs n’est pas finement configuré.
Le problème ne vient pas du moteur de PrestaShop lui-même, mais de la manière dont il est souvent déployé. Par défaut, l’affichage du bloc de livraison sur la fiche produit ou le panier appelle la classe Carrier pour chaque transporteur actif, recalcule les coûts en fonction du panier, et agrège le tout avant de renvoyer le HTML. Si votre boutique a 15 transporteurs et que 10 sont zonés DOM-TOM, le temps de réponse serveur (TTFB) pour ce seul fragment peut dépasser 1,8 seconde. Multiplié par le nombre de visiteurs simultanés, l’effet sur le LCP est dévastateur, surtout lorsque l’appel au transporteur est synchrone et bloque le rendu du reste de la page.
On ne parle pas ici d’un problème d’hébergement bas de gamme. Même sur un VPS correctement dimensionné, la complexité combinatoire explose quand les transporteurs partagent des zones mais pas les mêmes bornes de poids, ou quand des promotions conditionnelles (gratuité à partir de 200 €) introduisent des boucles d’évaluation supplémentaires.
Le cas concret d’un checkout DOM-TOM : LCP à 8,4 secondes
Prenez une boutique de produits alimentaires expédiant depuis la métropole vers la Martinique et la Réunion. Elle propose Colissimo, Chronopost Outre-Mer et un transporteur maritime économique. Sur la page produit, un module affiche une estimation des frais avant ajout au panier. Ce bloc appelle le contrôleur Cart pour chaque transporteur via une requête AJAX… mais le thème, lui, attend la réponse pour terminer le chargement de la page, bloquant le LCP.
Banc d’essai : un PrestaShop 8.1 sur un serveur OVH, testé depuis un point de présence WebPageTest à La Réunion. Le LCP, mesuré sur l’image principale du produit, atteignait 8,4 secondes en 4G lente. En désactivant simplement le bloc d’estimation, le LCP tombait à 3,1 secondes. Ce chiffre seul indique que le goulot ne se situait pas dans le chargement des ressources statiques, mais dans l’attente d’une réponse serveur longue.
Ce cas illustre à quel point une fonctionnalité perçue comme un service client peut saborder les signaux techniques que Google remonte dans la Search Console. Quand Googlebot crawle une page dont le LCP dépasse les 6 secondes, la probabilité que l’URL soit rétrogradée dans les résultats depuis un mobile augmente, comme on l’a documenté dans notre analyse détaillée des optimisations Core Web Vitals.
Les modules « miracle » qui transforment le TBT en désastre
Une tentation courante consiste à installer un module de livraison avancé promettant la gestion de toutes les zones en un clic. Ces modules se branchent sur des API externes : Mondial Relay, Boxtal, Sendcloud, ou des agrégateurs propres aux DOM-TOM. Problème : chaque appel à une API externe augmente le Total Blocking Time (TBT). Pire, certains modules déclenchent ces appels de manière synchrone au moment où l’internaute saisit son code postal, ce qui fige complètement le thread principal jusqu’à la réponse.
On a diagnostiqué un site dont le TBT dépassait les 900 ms sur mobile. La cause ? Un module qui interrogeait trois transporteurs différents pour chaque code postal, avec un timeout de 5 secondes chacun. Quand une API ne répondait pas, le module restait en attente, et l’utilisateur se retrouvait face à un checkout gelé. Le pire, c’est que ces appels avaient lieu pour des visiteurs qui n’étaient même pas concernés par l’outre-mer, simplement parce que le module chargeait toutes les règles sans filtre préalable.
On entend parfois « le SEO n’a rien à voir avec le choix du transporteur ». C’est faux. Si un module alourdit le JavaScript et retarde l’interactivité au point de faire chuter l’INP au-dessus de 200 ms sur mobile, Google le mesure, et la page perd en visibilité. Le lien entre performance et indexation n’est plus à démontrer.
Comment j’ai divisé le LCP par deux avec un fragment de cache
Le déclic est venu d’un constat : 95 % des visiteurs d’une même zone voient les mêmes tarifs pour un produit donné. Recalculer la matrice à chaque chargement est du gaspillage pur. Nous avons mis en place un cache applicatif spécifique aux fragments de livraison, stocké côté serveur et rafraîchi uniquement quand un transporteur ou une règle de prix change dans le back-office.
Techniquement, cela passe par un override de la méthode getDeliveryOptionList() pour y ajouter un mécanisme de cache fichier ou Redis. Les combinaisons id_cart + id_zone sont hashées, et le résultat est servi en moins de 40 millisecondes. Pour les boutiques qui ne peuvent pas toucher au code, une architecture avec un reverse proxy capable de servir des blocs différenciés (Edge Side Includes) fait aussi l’affaire, à condition de purger le cache lors des mises à jour de transporteurs.
Après ce changement sur la boutique alimentaire, le TTFB du bloc transporteur est passé de 1,9 seconde à 87 ms, et le LCP global est descendu sous les 4 secondes. Sans toucher au thème, sans changer d’hébergeur. Juste en traitant le calculateur comme ce qu’il est : un composant dont la fraîcheur des données n’a pas besoin d’être absolue à chaque requête.
💡 Conseil : Si vous utilisez un CDN devant PrestaShop, activez le cache des réponses JSON des contrôleurs de transport et indexez-les par zone. Un simple Vary: X-Country-Code dans l’en-tête HTTP suffit souvent à éviter les invalidations intempestives.
PrestaShop n’est pas une SPA, mais vous pouvez tricher
L’approche radicale consiste à extraire totalement le bloc transporteur de la cascade de chargement critique. Plutôt que d’attendre la réponse serveur pour afficher le prix de livraison, on charge d’abord un squelette statique, puis on injecte le résultat en asynchrone.
On peut par exemple intégrer un petit module JavaScript qui écoute la présence du panier et déclenche un fetch vers une route dédiée. Le rendu initial de la page ne dépend plus du calcul des transporteurs : le LCP est donc libéré. Le coût est minime : un léger décalage dans l’apparition du montant des frais, que la plupart des utilisateurs interprètent comme une mise à jour dynamique normale.
Cette logique rappelle ce qu’on fait naturellement avec un state manager comme Zustand sur une application React : on découple le chargement des données de l’affichage initial, pour que l’utilisateur voie quelque chose immédiatement. Dans notre article sur le state management React avec Zustand, nous montrions comment un état local bien structuré évite les re-rendus inutiles. Le principe est le même ici, à l’échelle d’un bloc PHP : retardez ce qui n’est pas indispensable au premier rendu, et hydratez ensuite.
Mesurer depuis les DOM-TOM : les outils qui ne mentent pas
Un audit Lighthouse lancé depuis Paris ne reflète pas l’expérience d’un acheteur à Mamoudzou. La latence réseau, les routeurs sous-dimensionnés, les aléas de peering : tout pousse le TTFB vers le haut. Pour obtenir des métriques fiables, il faut tester depuis des points de présence proches des utilisateurs réels.
WebPageTest propose des agents en Amérique du Sud et en Afrique du Sud qui simulent des conditions proches de celles des DOM-TOM. L’API CrUX de Google, de son côté, permet de remonter les données de terrain (champ data) par pays et par type de connexion. Croiser ces deux sources donne une image précise du LCP, de l’INP et du CLS vécus, et non simulés.
📌 À retenir : Ne vous fiez jamais au score Lighthouse généré depuis votre connexion fibre métropolitaine pour évaluer les performances d’un site à destination de la Guyane ou de Mayotte.
Pour les développeurs qui veulent automatiser le diagnostic, des outils comme Cursor ou Claude Code commencent à intégrer des assistants de performance capables d’analyser un waterfall et de suggérer des corrections en contexte. Nous avons comparé les approches dans notre test Claude Code vs Cursor IDE : l’avantage se joue surtout sur la capacité à lire un fichier de log et à proposer un correctif directement dans le code source, ce qui peut faire gagner un temps précieux quand on traque des appels AJAX fantômes insérés par un module.
Questions fréquentes
Le mode de livraison DOM-TOM impacte-t-il directement le référencement ?
Indirectement, oui. Ce n’est pas le mode de livraison en lui-même qui modifie les classements, mais les signaux de performance que le moteur de calcul dégrade. Un LCP dépassant 6 secondes, un INP au-dessus de 500 ms sur le checkout, des crawls ralentis : tout cela affecte les Core Web Vitals, un signal documenté pour le classement mobile. Si votre checkout est lent depuis l’outre-mer, vos positions sur les requêtes ciblant ces régions s’en ressentiront.
Faut-il un CDN spécifique pour les départements et régions d’outre-mer ?
Pas nécessairement un CDN « spécial DOM-TOM », mais un CDN disposant de points de présence dans les zones concernées ou à proximité (Amérique du Sud, Afrique de l’Est, Océan Indien). Cloudflare, Fastly et BunnyCDN couvrent une grande partie de ces géographies. L’essentiel est de servir les assets statiques (CSS, JS, images) depuis un edge proche de l’utilisateur, surtout pour des connexions à bande passante limitée. La livraison intelligente du HTML restera dépendante du temps de réponse de votre serveur d’origine, d’où l’importance des caches de fragments vus plus haut.
PrestaShop 8 a-t-il corrigé ces problèmes de performances sur le checkout ?
PrestaShop 8 a amélioré le chargement des assets et le moteur de template, mais la mécanique de calcul des transporteurs reste fondamentalement la même. Les gains viennent surtout de la possibilité d’utiliser Symfony pour créer des contrôleurs plus fins et des caches HTTP natifs. Sans optimisation manuelle des modules de livraison, une boutique sous PrestaShop 8 rencontrera les mêmes goulots sur un checkout multi-zones DOM-TOM. La version du CMS ne fait pas le travail à votre place.
