On a récupéré une boutique PrestaShop 8 qui vend du matériel nautique. Le checkout prenait 3,8 secondes à s’afficher pour un client depuis La Réunion, contre 1,2 seconde en métropole. Le responsable croyait que le serveur était loin. En réalité, le goulet d’étranglement venait du paramétrage de livraison DOM-TOM, plus précisément de ce que ce paramétrage autorisait les modules à exécuter avant même que le navigateur ne puisse afficher le récapitulatif de commande. Ce qu’on a fait pour faire descendre le LCP à moins de 2 secondes sur l’Océan Indien tient en trois nettoyages et un changement de logique d’exécution.
Le diagnostic : pas un problème de latence serveur, un problème d’exécution conditionnelle
Quand un visiteur guyanais arrive sur le checkout, le moteur de PrestaShop doit déterminer les transporteurs éligibles en fonction de son adresse, du poids total, de la zone géographique et des règles de prix. Ce travail est normal. Ce qui l’est moins, c’est la façon dont les modules de livraison (Mondial Relay, Colissimo, Boxtal, Chronopost, etc.) se greffent sur cette étape.
La plupart déclenchent des appels HTTP synchrones vers leur propre API pour vérifier un point relais ou un créneau. Si le hook de calcul de frais est mal isolé, ces appels s’exécutent pendant la phase de rendu serveur et le navigateur du client attend. C’est encore plus sensible quand le module charge une bibliothèque de carte ou un script de géolocalisation pour « aider » l’internaute. Sur une box à Saint-Pierre-et-Miquelon avec un ping à 180 ms, chaque requête supplémentaire alourdit le TTFB et retarde l’affichage du bouton de paiement.
On a posé la question suivante dans WebPageTest : quel pourcentage du temps total est passé à attendre la réponse du serveur sur une page de commande simulée depuis l’outre-mer ? On a obtenu 2,1 secondes de TTFB, dont 800 millisecondes passées dans le calcul des transporteurs. En désactivant temporairement chaque module, on a isolé le coupable : un module de livraison avec un appel cURL non mis en cache qui vérifiait la couverture de chaque DOM-TOM un par un, à chaque chargement.
Ce que signifie « paramétrer la livraison DOM-TOM » en 2026
Paramétrer la livraison ultramarine dans PrestaShop ne se limite plus à cocher une zone « Outre-mer » dans la fiche transporteur. Ça implique de réduire l’empreinte réseau du checkout à l’endroit où la latence devient significative pour les Core Web Vitals. On sort du commerce purement fonctionnel pour entrer dans l’optimisation d’expérience utilisateur locale, un signal que les systèmes de classement observent indirectement via le pogo-sticking si la page est trop lente.
Concrètement, il faut segmenter les zones DOM-TOM par transporteur de façon pertinente. La France d’outre-mer, c’est une multitude de codes postaux et de statuts : les DROM (971, 972, 973, 974, 976) et les COM (987, 988, etc.), sans parler des statuts fiscaux différents. Si vous créez une seule zone fourre-tout « DOM », vous forcez PrestaShop à évaluer l’ensemble des règles pour chaque commande. Si vous créez quinze zones précises, vous multipliez les comparaisons côté backend et vous augmentez la probabilité qu’un module effectue quinze vérifications au lieu d’une. Le point d’équilibre dépend du nombre de transporteurs, mais la logique à retenir est simple : ce qui est évalué dynamiquement à chaque chargement devient un coût mesurable quand la connexion client est fragile.
On a souvent tendance à croire que la configuration de livraison est un sujet « logistique », pas « performance web ». C’est une erreur de cloisonnement qui a un impact direct sur le taux de conversion mobile dans les territoires ultramarins, où le parc mobile domine et où la 4G n’a pas la même stabilité qu’à Lille ou Lyon.
⚠️ Attention : Une zone DOM-TOM mal rattachée à un pays peut générer une redirection automatique vers une page « Nous ne livrons pas dans votre pays » si le module détecte une incohérence entre l’adresse et le pays enregistré. Cette redirection, invisible dans les DevTools quand on teste depuis la métropole, casse le TTFB et le LCP pour les visiteurs concernés.
Découpler l’estimation du transporteur du chargement de la page
La solution la plus radicale qu’on a mise en place consiste à déplacer le calcul de disponibilité transporteur dans une requête asynchrone déclenchée après le premier affichage du checkout. Au lieu de laisser PrestaShop déterminer la liste complète des transporteurs pendant la génération du HTML, on injecte un squelette HTML statique et on peuple les options via un appel fetch après le chargement.
Pour ça, on a surchargé le contrôleur de commande pour qu’il retourne immédiatement la page avec une section « transporteurs » vide, puis on a ajouté un endpoint REST via un module sur mesure qui retourne la liste des transporteurs au format JSON. Résultat : le LCP de la page checkout ne dépend plus du temps de réponse des API de transport. On mesure un affichage stable sous 1,4 seconde depuis La Réunion, y compris avec trois modules de livraison actifs.
Ce genre de refonte légère est possible à condition de gérer la transition sans casser les modules de paiement qui lisent l’id_carrier sélectionné. On a simplement retardé le binding JavaScript du sélecteur de transporteur après l’arrivée de la réponse asynchrone. C’est un exemple concret de ce qu’on pourrait appeler du « rendu hybride appliqué au checkout » : la page est fonctionnelle rapidement, les données lourdes arrivent après. Ce n’est pas un hack, c’est du déplacement de dépendances serveur vers le client, mesuré et validé au Lighthouse.
💡 Conseil : Si vous préférez une approche sans développement personnalisé, commencez par auditer la méthode
getPackageShippingCostde chaque module. Beaucoup effectuent des appels réseau dans cette méthode sans aucun cache. Ajouter un cache fichier de 60 secondes sur les résultats des API externes réduit déjà de 40 à 60 % le temps de calcul transporteur sur des boutiques à fort catalogue.
La traque aux assets inutiles injectés par les modules de livraison
Un module de livraison, ce n’est pas seulement une classe PHP. C’est souvent un paquet de CSS, de JavaScript et de polices qui se chargent sur toutes les pages du front-office parce que le développeur du module n’a pas restreint l’exécution au seul checkout. Un coup de Coverage tab dans Chrome DevTools sur le tunnel de commande d’un PrestaShop avec cinq transporteurs révélera des fichiers de carte, des librairies d’autocomplétion d’adresse, parfois du jQuery supplémentaire.
Pour un visiteur en Guadeloupe qui achète un article à 30 €, la différence entre un checkout à 800 ko et un checkout à 2,3 Mo se traduit par un abandon de panier. On a systématiquement désactivé les assets des modules de livraison sur toutes les pages sauf le checkout. Sur le checkout même, on a déplacé leur chargement en defer et, pour les plus lourds, en async avec un fallback visuel.
Le bénéfice immédiat sur le LCP ne vient pas toujours de l’image héroïque de la boutique. Il peut venir de la suppression d’un fichier .js de 180 ko qui s’intercale entre le parse HTML et le rendu de l’ordre de récapitulatif. C’est valable pour les DOM-TOM, mais aussi pour n’importe quel client mobile.
Pourquoi vos pages de livraison sont un angle mort de votre SEO technique
Les pages d’information sur la livraison DOM-TOM (CGV, page « Livraison », FAQ logistique) sont souvent des contenus lourds en texte, rarement mis en cache, avec des dizaines de tableaux de tarifs non compressés. Quand Googlebot les crawl avec un budget limité, il peut consommer une part significative de son temps de crawl sur ces pages statiques, au détriment des fiches produits. On a vu un site perdre 30 % de son crawl des fiches produits après avoir généré automatiquement des pages de tarifs par département d’outre-mer sans balise noindex ni canonicalisation correcte.
Le lien entre livraison DOM-TOM et SEO technique est là : une mauvaise configuration des transporteurs peut entraîner une explosion d’URLs paramétrées (calculateur de frais en GET, pages de points relais, redirections de devis) que Google explore. Avant même de parler d’optimisation d’images du checkout, il faut s’assurer que ces pages ne sont pas indexables et ne consomment pas le fameux budget de crawl. Une règle simple : toute page qui liste des tarifs de livraison en fonction d’un code postal en paramètre doit être bloquée par le fichier robots.txt ou munie d’un meta robots noindex, follow.
Tester depuis l’outre-mer sans billet d’avion
Impossible d’évaluer la performance d’un checkout DOM-TOM si on teste uniquement depuis une box Free à Paris. On utilise deux outils : WebPageTest avec un emplacement de test à Tokyo ou Singapour pour simuler une latence comparable à celle de l’océan Indien (souvent plus proche de la réalité réseau que des nœuds Cloudflare européens). On configure le throttling en 3G pour représenter un usager mobile moyen à Mayotte.
Le deuxième outil, c’est un petit script Python qui appelle l’URL du checkout avec un header X-Forwarded-For pointant vers une IP réunionnaise (via un proxy qu’on loue pour l’occasion). Ça permet de déclencher la logique de zone géographique côté serveur et de mesurer le temps de réponse réel quand PrestaShop exécute les règles DOM-TOM. Cette approche nous a permis de découvrir que certains modules de transporteur activent une vérification fiscale supplémentaire pour les DOM, ajoutant 200 ms au temps de traitement.
Quand on combine un TTFB maîtrisé et un chargement asynchrone des transporteurs, le LCP du checkout passe sous les 2,5 secondes même en conditions dégradées. Ce seuil est un objectif de terrain : au-dessus, le taux de conversion sur mobile chute de façon mesurable. En dessous, on récupère les clients qui, autrement, auraient quitté avant d’avoir vu le bouton « Payer ».
Questions fréquentes
Comment gérer les différences de TVA entre DOM et métropole sans alourdir le checkout ? La TVA applicable est une logique métier qui ne nécessite aucun appel réseau supplémentaire si elle est servie depuis une table en cache. On évite absolument les modules qui interrogent un web-service externe à chaque étape du tunnel. La règle de TVA est stockée localement et appliquée en mémoire pendant la construction du panier, ce qui n’impacte pas le LCP.
Faut-il désactiver les transporteurs pour les DOM-TOM s’ils ne couvrent pas toutes les îles ? Ne pas couvrir un territoire n’est pas un problème technique, mais ne pas le filtrer correctement en amont force PrestaShop à évaluer des règles qui échouent, injectant du temps de calcul inutile. On préfère restreindre les transporteurs par zones spécifiques et garder un transporteur générique de secours pour éviter les impasses de livraison sans multiplier les tests.
Est-ce que l’approche asynchrone fonctionne avec le module de paiement « one-page checkout » officiel ?
Elle demande une surcharge du template et du JavaScript du module. L’effort est modéré si vous maîtrisez les hooks displayCarrierList et actionCarrierProcess. On ne recommande pas de le faire sans un environnement de staging isolé, parce qu’une erreur de liaison entre le transporteur asynchrone et le module de paiement peut rendre la commande impossible.
