Le verdict en trois phrases
Sur une connexion 3G à ~400 ms de RTT, une page de paiement lourde (2,5 Mo, LCP à 8 s) perd des clients avant même l'affichage du bouton payer. Chaque seconde ajoutée coûte environ 7 % de conversion, et 35 à 50 % du trafic en Afrique de l'Ouest reste sur 3G. L'objectif 2026 : < 500 Ko, LCP < 2,5 s et INP < 200 ms sur la page de checkout.
Page lourde vs page optimisée
La différence ne se voit pas sur le wifi du bureau ; elle se voit sur le téléphone d'un client à Kaolack en heure de pointe.
| Critère | Checkout lourd | Checkout optimisé |
|---|---|---|
| Poids total | 2,5 Mo | < 500 Ko |
| LCP en 3G | ~8 s | < 2,5 s |
| LCP en 4G | ~2,5 s | < 1 s |
| INP | > 400 ms | < 200 ms |
| Requêtes réseau | 40+ | < 15 |
| Scripts tiers | nombreux | minimal |
Le poids étape par étape
Un checkout se décompose en écrans ; chacun doit rester léger, surtout l'écran de paiement.
| Étape | Poids typique non optimisé | Cible optimisée |
|---|---|---|
| Panier | 900 Ko | 200 Ko |
| Adresse / livraison | 600 Ko | 120 Ko |
| Écran paiement | 1 000 Ko | 180 Ko |
| Confirmation | 400 Ko | 80 Ko |
| Scripts analytics/tiers | 500 Ko+ | différés |
Redirection PSP vs SDK inline
Le choix d'intégration paiement pèse sur la latence. Une redirection vers une page PSP externe ajoute un aller-retour réseau complet ; un SDK inline bien optimisé garde le client sur votre page mais doit rester léger.
1. Budget de performance. Fixez un plafond dur : la page de paiement ne dépasse jamais 500 Ko. Chaque nouveau script doit « payer son ticket ».
2. Chargement différé. Analytics, chat, pixels : chargés après l'interaction, jamais avant le bouton payer.
Besoin d'un site web professionnel ?
Kolonell crée des sites web qui attirent des clients, optimisés pour le marché sénégalais. Devis gratuit en 2 minutes.
3. Images et polices. Formats modernes (WebP/AVIF), polices système ou sous-ensembles ; une police custom lourde peut à elle seule ajouter 1 s au LCP.
4. Mesurer sur 3G réelle. Testez avec un throttling 3G (400 ms RTT, ~400 Kb/s), pas sur la fibre. Ciblez LCP < 2,5 s et INP < 200 ms.
Mini cas pratique
Moussa gère un site de livraison de repas à Thiès, 3 000 checkouts/mois, panier moyen 8 500 FCFA. Son écran de paiement pesait 2,3 Mo (LCP ~7 s en 3G). En passant sous 500 Ko (LCP ~2,3 s), il gagne ~4,5 s. À ~7 % de conversion perdue par seconde, cela représente un potentiel de récupération important : même une amélioration prudente de +8 points de conversion checkout sur 40 % de trafic 3G rend ~96 commandes/mois x 8 500 = 816 000 FCFA/mois de CA additionnel, pour ~3 jours d'optimisation.
FAQ
Combien coûte une seconde de latence ? Un ordre de grandeur d'environ 7 % de conversion perdue par seconde ajoutée sur la page de paiement.
Quelle part du trafic est en 3G en AOF ? Une estimation de 35 à 50 % selon les pays et les zones, avec des pics en périphérie et heures de pointe. On ne peut pas l'ignorer.
Quel poids viser pour l'écran de paiement ? Moins de 500 Ko au total, scripts tiers différés, pour tenir un LCP < 2,5 s en 3G.
Redirection PSP ou SDK inline ? Le SDK inline garde le client sur votre page mais doit rester léger ; la redirection ajoute un aller-retour réseau complet. Choisir selon le budget de performance.
Quels objectifs Core Web Vitals ? LCP < 2,5 s et INP < 200 ms sur mobile, mesurés en throttling 3G réel et non sur fibre.
Discutons de votre projet. Nous optimisons votre checkout pour la 3G africaine et visons des Core Web Vitals au vert. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionné par le digital et l'entrepreneuriat en Afrique, Mohamed accompagne les entreprises sénégalaises dans leur transformation digitale depuis 2020. Fondateur de Kolonell, il croit que chaque PME mérite une présence en ligne professionnelle et accessible.
