Google a publié les chiffres en 2018 et ils n'ont pas changé depuis : une page mobile qui passe de 1 à 3 secondes de chargement voit sa probabilité de rebond augmenter de 32%. De 1 à 5 secondes, c'est 90%. Pour un site e-commerce, chaque seconde de retard se traduit directement en paniers abandonnés et en chiffre d'affaires perdu.
Mais "optimiser le temps de chargement" est un conseil trop vague pour être actionnable. Cet article détaille les deux métriques à surveiller et comment diagnostiquer ce qui ralentit votre boutique.
Les deux métriques qui comptent
TTFB — Time to First Byte
Le TTFB mesure le temps entre la requête du navigateur et la réception du premier octet de la réponse serveur. Il reflète la performance de votre infrastructure : hébergement, base de données, cache applicatif, réseau.
Les seuils de référence :
- < 200 ms : excellent. Typique d'un site statique ou d'un CDN bien configuré.
- 200-800 ms : acceptable. La plupart des sites e-commerce avec un hébergement correct tombent ici.
- 800 ms - 1,5 s : lent. L'hébergement ou la base de données est probablement sous-dimensionné.
- > 1,5 s : problématique. Le serveur met trop de temps à générer la page avant même de l'envoyer.
Un TTFB supérieur à 800 ms signifie que votre page part avec un handicap avant même d'avoir envoyé le moindre pixel au navigateur. Même avec des images parfaitement optimisées et un JavaScript minimal, vous ne pouvez pas avoir un temps de chargement total correct si votre serveur met plus d'une seconde à répondre.
Temps de chargement total
Le temps de chargement total inclut le TTFB, le téléchargement de toutes les ressources (HTML, CSS, JS, images, fonts), et l'exécution du JavaScript nécessaire au rendu de la page.
Les seuils PurpleScan :
- ≤ 2 secondes : excellent. L'utilisateur perçoit la page comme quasi-instantanée.
- ≤ 3 secondes : bon. Conforme aux attentes de la majorité des utilisateurs.
- ≤ 5 secondes : lent. Vous perdez une partie significative de vos visiteurs mobiles.
- > 5 secondes : très lent. Selon Google, 53% des visiteurs mobiles quittent une page qui met plus de 3 secondes à charger. À 5 secondes, la majorité est partie.
Diagnostiquer un TTFB lent
Quand le TTFB dépasse 800 ms, le problème se situe côté serveur. Quatre causes reviennent systématiquement :
Hébergement sous-dimensionné
Un hébergement mutualisé à 5 €/mois ne peut pas servir un catalogue Magento de 10 000 produits avec des requêtes de recherche facettée. Vérifiez les ressources CPU et mémoire disponibles. Sur un hébergement cloud (AWS, GCP, OVH), un manque de RAM est souvent la première cause : le serveur swap sur disque et les temps de réponse explosent.
Requêtes base de données non optimisées
Une page catégorie qui affiche 40 produits avec leurs prix, stocks, images et variantes peut facilement générer 50+ requêtes SQL si le code n'est pas optimisé. Des index manquants sur les tables produit, des jointures non nécessaires, ou un ORM qui génère du N+1 sont les causes classiques. Activez le profiling SQL de votre framework (Symfony Profiler, Magento Debug Toolbar) pour identifier les requêtes lentes.
Absence de cache
Sans cache, chaque visiteur déclenche la regénération complète de la page. Les couches de cache à vérifier :
- Cache HTTP (Varnish, Fastly, Cloudflare) : sert la page directement sans toucher au serveur applicatif
- Cache applicatif (Redis, Memcached) : stocke les résultats de requêtes fréquentes en mémoire
- Cache de page complète (Full Page Cache) : natif sur Magento 2, disponible via plugins sur PrestaShop et WooCommerce
Absence de CDN
Si votre serveur est hébergé à Paris et qu'un client visite depuis Marseille, la latence réseau est négligeable. Depuis le Japon, c'est 200-300 ms de latence incompressible. Un CDN (Cloudflare, Fastly, AWS CloudFront) rapproche le contenu du visiteur. Pour un site avec une audience internationale, l'impact sur le TTFB est immédiat.
Diagnostiquer un chargement lent (malgré un TTFB correct)
Votre serveur répond en 300 ms mais la page met 4 secondes à s'afficher. Le problème est côté client — dans ce que le navigateur doit télécharger et exécuter.
Images non optimisées
C'est le coupable numéro un. Une photo produit en JPEG de 2 Mo multipliée par 20 produits sur une page catégorie = 40 Mo de téléchargement. PurpleScan signale les images dépassant 200 Ko (warning) et 500 Ko (erreur). La conversion en WebP réduit le poids de 25 à 35% sans perte visible, et quasiment tous les navigateurs la supportent (95%+ selon Can I Use).
Scripts tiers
Chaque script tiers est une requête HTTP supplémentaire, du JavaScript à parser et à exécuter, et souvent d'autres requêtes en cascade. Un seul widget de chat (Intercom, Zendesk, Crisp) peut ajouter 300 à 800 Ko de JavaScript. Un pixel de remarketing en déclenche souvent 5 à 10 autres. Selon une analyse HTTP Archive de 2024, les scripts tiers représentent en moyenne 35% du JavaScript total chargé sur les sites e-commerce.
PurpleScan catalogue chaque requête réseau par domaine source. Ça permet d'identifier immédiatement quel service tiers pèse le plus lourd dans le chargement.
Fonts web
Charger 4 variantes d'une police Google Fonts (regular, bold, italic, bold italic) ajoute 200 à 400 Ko et peut bloquer l'affichage du texte pendant le téléchargement. Les bonnes pratiques : limiter à 2 variantes maximum, utiliser font-display: swap pour afficher un texte immédiatement, et précharger les fonts critiques avec <link rel="preload">.
Le breakdown par domaine : trouver le coupable
PurpleScan décompose toutes les requêtes réseau capturées pendant le crawl par domaine source. Pour chaque domaine, vous voyez :
- Le nombre de requêtes
- Le poids total transféré
- Le temps de chargement cumulé
C'est souvent révélateur. Sur un site qu'on a scanné récemment, le domaine principal représentait 1,2 Mo de transfert. Le domaine cdn.shopify.com ajoutait 800 Ko (images). Jusque-là, rien d'anormal. Mais un domaine de session replay (static.hotjar.com + script.hotjar.com) ajoutait à lui seul 650 Ko de JavaScript et 12 requêtes supplémentaires.
Sans ce breakdown par domaine, le marchand voyait juste "ma page est lente". Avec, il a pu prendre une décision concrète : remplacer Hotjar par une solution plus légère ou le charger uniquement sur les pages où il en avait vraiment besoin.
Optimisations par plateforme
Shopify
Shopify gère l'hébergement et le CDN. Vous n'avez pas la main sur le TTFB. En revanche, vous contrôlez le thème et les apps installées. Chaque app Shopify peut injecter du JavaScript dans votre storefront. Faites le tri : désinstallez les apps inactives (elles laissent parfois leur script derrière), utilisez les sections Liquid natives plutôt que des apps pour les fonctionnalités simples, et activez le lazy loading sur les images de collection.
Magento / Adobe Commerce
Activez le Full Page Cache avec Varnish (pas le cache fichier, trop lent pour un catalogue volumineux). Configurez Redis pour le cache applicatif et les sessions. Activez la minification et le bundling JS/CSS natifs. Vérifiez que le mode production est actif (le mode développeur désactive le cache et ajoute du logging). Pour les images, le module natif de redimensionnement fonctionne, mais un CDN d'images comme Cloudinary ou imgix offre la conversion WebP automatique.
PrestaShop
Activez le cache Smarty (Paramètres avancés > Performances). Activez la combinaison et minification CSS/JS (attention : testez, certains modules ne supportent pas la combinaison JS). Installez un module de cache de page complète si votre hébergement ne fournit pas Varnish. Pour les images, PrestaShop régénère les miniatures à l'import mais ne convertit pas automatiquement en WebP. Le module "WebP Converter" de la communauté fait le travail.
Par où commencer
Ne cherchez pas à tout optimiser en même temps. Commencez par mesurer, puis traitez dans cet ordre :
- Vérifiez le TTFB. S'il dépasse 800 ms, rien d'autre ne compte tant que vous n'avez pas réglé le problème serveur. Tout le reste est de l'optimisation sur un terrain instable.
- Identifiez les scripts tiers les plus lourds. Le breakdown par domaine de PurpleScan montre immédiatement les coupables. Un seul script retiré peut faire gagner une seconde complète.
- Optimisez les images. Conversion WebP, compression, lazy loading sur les images hors écran. C'est le levier avec le meilleur ratio effort/impact.
PurpleScan mesure le TTFB et le temps de chargement total à chaque scan. Si vous optimisez par étapes, vous pouvez voir l'impact de chaque action sur les scans suivants et vérifier que la performance ne régresse pas quand de nouveaux éléments sont ajoutés au site.