Slow checkout sur Magento - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant de conclure « checkout lent », confirme que le problème est bien dans le tunnel et pas sur tout le site. Le réflexe : ouvre l'onglet Network de Chrome DevTools (Réseau), coche « Preserve log », parcours le checkout étape par étape et observe quelles requêtes XHR durent le plus longtemps.

• Plusieurs secondes de blocage entre deux étapes, loader (spinner) qui tourne après chaque clic « Continuer » ou « Suivant »
• Recalcul lent du panier (totaux/taxes) à chaque modification de quantité ou ajout de code promo
• Estimation des frais de port qui rame quand on saisit le pays ou le code postal
• Timeout ou écran figé au moment de valider le paiement
• Dégradation très marquée sur mobile (CPU plus faible = parsing JS plus long)
• Pic d'abandon panier visible dans GA4 / Adobe Analytics précisément sur le step shipping ou payment

Impact business immédiat

Le checkout est la dernière marche : l'utilisateur a déjà choisi son produit, sorti sa carte, et c'est là que la lenteur le fait fuir. Un tunnel lent transforme du trafic payant en perte sèche.

Le seuil de référence Google reste 3 secondes : au-delà, le taux d'abandon grimpe nettement. Sur un checkout Magento non optimisé qui atteint 10-20 s sur connexion lente, tu perds une partie significative des acheteurs déjà engagés.

• Fuite de revenu directe sur l'étape paiement, là où la marge est la plus élevée
• Baisse du ROI acquisition : tu paies l'acquisition (SEA/SEO) mais le tunnel détruit la conversion finale
• Hausse de la charge support (clients bloqués qui écrivent, double-commandes par re-clics)
• Dégradation des Core Web Vitals sur /checkout (INP > 200 ms, LCP > 2,5 s) qui peut aussi peser sur le SEO

Causes classées par probabilité

Dans l'ordre où on les rencontre en intervention sur un Magento 2 lent au checkout :

• 1. Sessions et cache mal configurés : sessions en fichiers au lieu de Redis, ou Varnish FPC absent/mal réglé. C'est la cause n°1 et la plus rentable à corriger.
• 2. Empilement d'extensions checkout : shipping custom, anti-fraude (Signifyd), fidélité, checkout multi-étape — chacune ajoute des appels réseau synchrones à chaque step.
• 3. API tierces lentes au moment de l'estimation des frais de port : chaque transporteur actif coûte 2-3 s ; trois transporteurs = 6-9 s ajoutées.
• 4. Trop de JS non bundlé/minifié : le checkout par défaut charge 270+ fichiers (~2,8 Mo), à parser sur le device client.
• 5. Indexers en retard ou en mode incorrect : catalog_product_price et cataloginventory_stock doivent être cohérents pour ne pas générer de latence au calcul des totaux.
• 6. Emails de commande synchrones : l'envoi du mail de confirmation dans le même process ajoute 1-3 s à la validation.
• 7. Infra sous-dimensionnée : PHP ancien sans OPcache prod, RAM/CPU insuffisants, MySQL sur disque lent.
• 8. Méthodes de livraison / pays / paiement inutiles laissés actifs, qui multiplient les calculs et les blocs JS chargés.

Diagnostic : les commandes à lancer

Personne ne montre comment isoler où part le temps — c'est pourtant l'étape qui évite d'optimiser à l'aveugle. L'objectif : savoir si la latence est côté serveur (TTFB), côté JS client, ou sur une API tierce.

D'abord, regarde les logs applicatifs et les rapports d'erreur, c'est le chemin le plus court vers la cause.

Lecture du résultat : si le TTFB des XHR /rest/.../totals-information est élevé dans Network, le problème est serveur (sessions/cache/DB). Si le TTFB est bon mais l'étape reste lente, regarde le temps « Scripting » dans l'onglet Performance — c'est le parsing JS. Si une seule requête (estimation de port) prend 2-3 s, c'est une API transporteur.

# Suivre les logs en direct pendant qu'on rejoue un checkout
tail -f var/log/system.log var/log/exception.log var/log/debug.log

# Lister les derniers rapports d'exception générés (loader figé = souvent une exception ici)
ls -lt var/report/ | head
cat var/report/$(ls -t var/report/ | head -1)

# Chercher les timeouts / erreurs cURL des API transporteurs ou paiement
grep -iE 'timeout|curl|cURL error|shipping|carrier' var/log/system.log | tail -50

php bin/magento --version
php -v   # vise PHP 8.3/8.4 pour 2.4.8

# Mode : 'developer' en prod tue le checkout (compilation à la volée)
php bin/magento deploy:mode:show

# Caches : full_page et config DOIVENT être enabled
php bin/magento cache:status

# Indexers : surveille tout statut 'invalid'
php bin/magento indexer:status

# Profiler natif Magento (génère un .csv par requête dans var/log/profiler/)
php bin/magento dev:profiler:enable html
# rejoue le checkout, puis désactive
php bin/magento dev:profiler:disable

# Vérifier la conf Redis sessions effective
grep -A15 "'session'" app/etc/env.php

-- Activer le slow query log le temps du diagnostic
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- Vérifier les requêtes en cours pendant un checkout lent (locks ?)
SHOW FULL PROCESSLIST;

-- Contrôler que les tables d'index prix/stock sont à jour
SELECT COUNT(*) FROM catalog_product_index_price;
SELECT COUNT(*) FROM cataloginventory_stock_status;

Solutions pas-à-pas

Applique dans cet ordre : server-side d'abord (gains les plus gros), app-level ensuite. Reproduis chaque changement en préprod, mesure, puis passe en prod.

1. Sessions en Redis. Édite app/etc/env.php pour sortir les sessions des fichiers (bloc ci-dessous), puis vide le cache. C'est le gain n°1 sur la latence inter-étapes.
2. Active et configure Varnish FPC. Stores > Configuration > Advanced > System > Full Page Cache : passe en Varnish Caching. Le checkout reste privé (non caché) mais le reste du parcours décharge PHP, libérant des ressources pour le tunnel.
3. PHP 8.3/8.4 + OPcache en mode production. Règle opcache.validate_timestamps=0 en prod (recharge requise après déploiement) et passe le store en mode production : php bin/magento deploy:mode:set production.
4. Bundle + minifie le JS. Stores > Configuration > Advanced > Developer > JavaScript Settings : active Merge, Bundle et Minify (en mode production uniquement). Redéploie le contenu statique : php bin/magento setup:static-content:deploy fr_FR.
5. Passe les emails de commande en asynchrone. Stores > Configuration > Sales > Sales Emails : Asynchronous sending = Enable. La validation rend la main sans attendre l'envoi du mail (-1 à -3 s).
6. Coupe le superflu. Désactive les transporteurs, pays et moyens de paiement non utilisés (Stores > Configuration > Sales > Shipping Methods / General > Country Options / Sales > Payment Methods). Purge les Cart/Catalog Price Rules obsolètes (Marketing > Promotions).
7. Allège le tunnel : One-Step Checkout. Si le multi-étape natif empile les recalculs, un module OSC (ou Hyvä Checkout, voir plus bas) réduit le nombre d'appels API et de re-render Knockout.
8. Vérifie les indexers et le cron. catalog_product_price et cataloginventory_stock cohérents avec ta charge ; assure-toi que le cron Magento tourne (crontab + php bin/magento cron:run).

'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
        'max_concurrency' => '20',
        'break_after_frontend' => '5',
        'disable_locking' => '0',
    ],
],

opcache.enable=1
opcache.memory_consumption=512
opcache.max_accelerated_files=60000
opcache.validate_timestamps=0

Spécificités par version

Le comportement du checkout et les leviers disponibles changent selon ta branche Magento :

• 2.3.x : pas de lazy loading natif des images. Le bundling JS natif est lourd et peut empirer le checkout sur certains thèmes — privilégie un build r.js custom ou Baler. PHP 7.x en fin de vie : migre.
• 2.3.4 et + : ajout du Image Lazy Loading natif (Stores > Configuration > Advanced > Developer > Image Lazy Loading). Active-le pour soulager le rendu.
• 2.4.x : OpenSearch/Elasticsearch obligatoire, Redis recommandé par défaut. Le checkout reste Knockout.js mais la stack est plus saine (PHP 8.x supporté).
• 2.4.8 (avril 2025) : compatible PHP 8.3/8.4, MySQL 8.4 / MariaDB 11.4, OpenSearch 2.19, Redis 7.2, Varnish 7.6, Composer 2.9.3+. Mets à jour pour bénéficier des optimisations front et des correctifs de performance.
• Adobe Commerce (vs Open Source) : tu disposes en plus de modules comme Signifyd qui, mal réglés, ajoutent de la latence au checkout — désactive-les si non utilisés.

Contexte France / UE : transporteurs, paiement, RGPD

Un point qu'aucun guide concurrent ne traite : sur une boutique FR, la lenteur du checkout vient souvent des intégrations locales.

Transporteurs (Colissimo, Mondial Relay, Chronopost) : chaque module qui interroge une API de point relais ou de tarification en temps réel ajoute 2-3 s par appel. Mets en cache les grilles tarifaires quand c'est possible et limite les transporteurs réellement actifs au calcul des frais de port.

Paiement (Stripe, PayPlug, Lyra/PayZen) : chacun charge son propre JS/iframe sur l'étape paiement. Vérifie dans Network le poids et le temps de chargement de ces scripts ; n'active que les moyens de paiement utilisés.

RGPD / consentement : les bannières de consentement et tags tiers (analytics, pixels) qui bloquent l'exécution du JS retardent l'interactivité du tunnel. Charge ces scripts en defer/async et exclus-les des pages de checkout quand ils n'y servent à rien.

Option 2025/2026 : OSC natif vs checkout headless

Quand l'optimisation classique ne suffit plus, deux directions — à choisir selon tes contraintes.

Reste sur un module One-Step Checkout si ton problème est surtout le nombre d'étapes et de recalculs, et que ton thème reste sur le front Luma. C'est rapide à déployer, peu risqué.

Passe à Hyvä Checkout (ou PWA Studio en headless) si le poids du Knockout.js est ton goulot principal. Hyvä remplace la couche front lourde par du JS minimal (Alpine.js), ce qui réduit drastiquement le nombre de fichiers et le temps d'interactivité du tunnel. Le compromis : refonte front + coût de migration. C'est l'angle que la plupart des guides ne couvrent pas encore en 2026.

Quand appeler un expert

Tu as profilé, isolé le temps (serveur / JS / API) et appliqué les correctifs server-side, mais le checkout reste lent ? C'est souvent le signe d'un conflit d'extension subtil, d'un lock MySQL récurrent sous charge ou d'une dette technique sur la couche front qui demande un audit ciblé.

Si tu perds des commandes chaque jour et que le diagnostic dépasse ce que tu peux corriger seul, BugRescue intervient sur ce type d'incident Magento 2 : audit du tunnel, profiling sous charge réelle et plan de correction priorité par impact conversion.

FAQ