Lazy loading PrestaShop : pages plus rapides et meilleur LCP

Le lazy loading des images PrestaShop (chargement différé) consiste à ne télécharger une image que lorsque le visiteur fait défiler la page jusqu’à elle. Bien mis en place, il peut réduire de moitié les données d’images chargées avec une page, sans ralentir l’image principale. Mal mis en place, il fait l’inverse : il retarde la photo du produit en haut de la page et dégrade le Largest Contentful Paint (LCP). Voici les chiffres sur ce que le lazy loading apporte, les erreurs les plus fréquentes et les raisons pour lesquelles il est difficile de l’appliquer à toutes les images d’une boutique PrestaShop.

Qu’est-ce que le lazy loading ?

Le lazy loading est une technique par laquelle le navigateur ne télécharge pas tout de suite les images situées sous la partie visible de la page. Il les récupère au fil du défilement, quand l’image approche de l’écran. Il existe deux façons de l’obtenir :

• L’attribut natif loading="lazy" — un seul mot dans une balise <img> ou <iframe>. C’est le navigateur qui décide quand charger l’image. Il est pris en charge par Chrome 77+, Edge 79+, Firefox 75+ et Safari 15.4+ (iframes : Firefox 121+, Safari 16.4+). Les navigateurs qui ne le connaissent pas l’ignorent simplement.
• Un script JavaScript — src contient une image d’attente légère et la vraie adresse patiente dans data-src. Un script basé sur IntersectionObserver échange l’adresse quand l’image approche de l’écran. Plus de contrôle (distance de chargement, apparition en fondu), mais il faut JavaScript et du soin.

Chrome charge les images en loading="lazy" en avance : environ 1 250 px avant l’écran sur une connexion rapide et 2 500 px sur une connexion lente. Selon l’équipe Chrome, sur Android en 4G, 97,5 % de ces images sont prêtes moins de 10 ms après être devenues visibles : le client ne voit pas de cases vides.

Pourquoi le lazy loading compte pour une boutique en ligne

Les images sont la plus grosse partie d’une page web. D’après le Web Almanac 2025 de HTTP Archive, la page d’accueil médiane pèse 2,56 Mo sur mobile, dont 911 Ko d’images réparties en 15 requêtes. Une boutique en ligne en compte généralement davantage : une catégorie avec 24 miniatures, un diaporama, des bannières, les logos de paiement, les photos de la description produit et les produits associés en dessous.

Un client qui ouvre une catégorie sur son téléphone ne voit que les premiers produits. Sans lazy loading, son navigateur télécharge toutes les miniatures d’un coup : il consomme ses données, dispute la bande passante à l’image réellement visible et occupe plus longtemps un processeur plus faible. Dans un test de l’équipe Chrome sur un site WordPress, différer les images sous la ligne de flottaison a réduit de 51 à 70 % les données d’images du premier chargement ; une fois les premières images chargées normalement, le LCP était égal ou meilleur que sans lazy loading.

La vitesse se traduit en ventes. Dans l’étude « Milliseconds Make Millions » de Deloitte (2020, commandée par Google, 37 marques, 30 millions de sessions), un site mobile plus rapide de 0,1 s était associé à 8,4 % de conversions en plus dans le commerce de détail et à un panier moyen supérieur de 9,2 %. Lors d’un test A/B, Vodafone a amélioré son LCP de 31 % et réalisé 8 % de ventes en plus. Le lazy loading n’est pas le seul levier — le serveur (voir notre comparatif VPS ou hébergement mutualisé pour PrestaShop), le cache et le poids des images comptent aussi — mais c’est l’un des moins coûteux.

Lazy loading, LCP et Core Web Vitals

Google mesure la vitesse d’une page avec trois Core Web Vitals. Pour les images, le plus important est le LCP (Largest Contentful Paint) : le temps d’affichage du plus grand élément à l’écran ; un bon score est de 2,5 s ou moins pour 75 % des visites. Google recommande vivement d’obtenir de bons Core Web Vitals, car ils correspondent à ce que ses systèmes de classement cherchent à récompenser. Un deuxième indicateur, le CLS (décalages de mise en page, bon en dessous de 0,1), dépend lui aussi des images.

À retenir : ne différez jamais une image visible tout de suite. Sur une page sur six, l’image principale est en lazy loading : le navigateur attend la mise en page pour la récupérer, et le LCP augmente. Dans les données de terrain de Chrome, les pages avec lazy loading natif avaient un LCP médian de 3 546 ms contre 2 922 ms sans (une corrélation, pas une preuve). L’équipe Chrome l’a vérifié sur WordPress, qui depuis la version 5.5 ajoute loading="lazy" même aux images du premier écran : une fois les premières images chargées normalement, le LCP de la page d’archive sur mobile a baissé de 18 %, et les économies de données sont restées.

Pour la première grande image, allez plus loin et ajoutez fetchpriority="high" : le navigateur la téléchargera avant les autres fichiers. En avril 2025, Google a retiré de Lighthouse l’audit « Defer offscreen images », car les navigateurs donnent déjà une priorité basse aux images hors écran. C’est important : le lazy loading n’est pas une astuce pour gonfler le score PageSpeed. Il économise les données et la bande passante de vos clients, tandis que le LCP dépend du chargement immédiat des premières images.

Le lazy loading dans PrestaShop : ce que fait le thème et ce qui manque

Nous avons analysé les thèmes par défaut de PrestaShop 1.7.8, 8.2 et 9.2 ainsi que 105 thèmes de boutiques sur lesquels nous avons travaillé (novembre 2026). Résultats :

• Classic et Hummingbird mettent loading="lazy" sur environ 90 % de leurs images — y compris l’image principale du produit (product-cover-thumbnails.tpl), qui est l’élément LCP de la page produit. Le thème par défaut diffère donc justement l’image qu’il ne faudrait pas différer.
• Les modules n’utilisent presque pas le lazy loading : dans les gabarits des modules de PrestaShop 1.7.8, aucune des 214 images ne l’a, dans la 9.2, trois sur 225. Diaporama, bannières et blocs d’icônes se chargent immédiatement.
• Le contenu de l’éditeur — photos des descriptions de produits et des pages CMS — n’a jamais de lazy loading, car il ne vient pas des gabarits.
• Dans les thèmes de boutiques, seulement 29 % des images ont un attribut loading, 9 % sont différées par un script du thème et 62 % n’indiquent pas de largeur, ce qui provoque des décalages de mise en page avec les scripts à image d’attente.

Pourquoi un lazy loading complet est difficile

Ajouter loading="lazy" à un gabarit prend une minute. Couvrir toute la boutique sans rien casser est un tout autre travail :

1. Des dizaines de gabarits. Un thème compte des dizaines de gabarits avec des images, et chaque module a les siens. Les modifications des fichiers d’un module disparaissent à sa mise à jour, et les surcharges dans le thème doivent être maintenues à chaque nouvelle version.
2. Le contenu de l’éditeur. Les descriptions de produits et les pages CMS ne se corrigent pas dans un gabarit : il faudrait modifier chaque entrée en base, et l’éditeur n’ajoute de toute façon pas l’attribut aux nouvelles images.
3. Le contenu chargé en AJAX. La liste de produits après un filtrage ou un tri, l’aperçu rapide et la fenêtre du panier sont construits sans recharger la page. Le script de lazy loading doit repérer les nouvelles images.
4. Les premières images de la page. Les images visibles sans défilement dépendent de la page : logo et diaporama sur l’accueil, photo du produit sur une fiche produit. « Tout en lazy » casse le LCP, « rien en lazy » n’économise rien.
5. Les scripts du thème et des modules. Galeries, zooms et diaporamas échangent eux-mêmes les adresses des images, et certains modules transforment les icônes SVG en code en lisant src. Une image d’attente au mauvais endroit donne une photo vide ou une icône disparue.
6. SEO et absence de JavaScript. Google recommande que les images se chargent quand elles entrent dans la fenêtre, et non après un clic ou un défilement, et que leur adresse figure dans src après le rendu. Un script qui ne le garantit pas peut cacher des photos aux moteurs de recherche.
7. Les arrière-plans CSS ne gèrent pas l’attribut loading : les bannières avec un fond dans l’attribut style demandent un script.

Astuce : vérifiez votre boutique en quelques secondes. Ouvrez une fiche produit, faites un clic droit sur la photo principale et choisissez « Inspecter ». Si elle porte loading="lazy", votre thème diffère l’élément LCP. Descendez ensuite jusqu’à la description : les images sans loading s’y chargent immédiatement, même si le client n’y arrive jamais.

Le lazy loading automatique dans PrestaShop

C’est pour ces raisons que nous avons créé le module Lazy loading automatique. Il ne modifie aucun fichier du thème ni des modules : il ajoute le lazy loading au HTML affiché par les gabarits de la boutique, et couvre donc le thème, les modules, les descriptions de produits, les pages CMS et le contenu chargé en AJAX. Les premières images de chaque page (quatre par défaut) se chargent tout de suite, même si le thème les avait différées, et la première grande image reçoit fetchpriority="high".

Deux techniques au choix : native (loading="lazy", sans JavaScript, sans risque pour les moteurs de recherche) ou un script avec une image d’attente qui garde les proportions de l’image, une distance de chargement réglable, l’apparition en fondu et la prise en charge des arrière-plans CSS en ligne. Le module laisse de côté les images déjà gérées par un script de lazy loading du thème et ne touche jamais aux e-mails, aux factures PDF ni au back-office. Vous pouvez exclure des gabarits, ou désactiver une seule image avec la classe no-lazy. Le tableau « Gabarits avec images » montre ce que le module a fait dans chaque gabarit et pourquoi il a laissé le reste. Il fonctionne avec PrestaShop 1.7.8, 8 et 9, multiboutique compris.

Si votre thème a des galeries particulières, ou si vous souhaitez de l’aide pour optimiser la vitesse dans son ensemble, vous pouvez aussi commander du développement PrestaShop.

Comment vérifier le résultat ?

• PageSpeed Insights : la partie consacrée aux données des utilisateurs réels (Chrome UX Report) donne le LCP et le CLS des 28 derniers jours. Dans les diagnostics, regardez la découverte de la requête LCP : c’est là que Lighthouse signale une image LCP différée et l’absence de priorité haute.
• Google Search Console : le rapport « Signaux Web essentiels » regroupe les URL au LCP lent. Les changements y apparaissent au bout de quelques semaines.
• Outils du navigateur : l’onglet « Réseau » filtré sur les images ; quelques fichiers doivent se charger avec la page, les suivants au fil du défilement.

Le lazy loading est l’une des 15 étapes de notre guide pour accélérer PrestaShop, qui traite aussi du cache, de PHP, du WebP et du ménage dans les modules.

Sources

• HTTP Archive, Web Almanac 2025 : Performance — images comme LCP, lazy loading et fetchpriority de l’image LCP, part des pages avec un bon LCP.
• HTTP Archive, Web Almanac 2025 : Page Weight — poids des pages et des images.
• web.dev, The performance effects of too much lazy loading (F. Arntz, R. Viscomi) — LCP et données du test WordPress.
• web.dev, Browser-level image lazy loading — prise en charge par les navigateurs, seuils de distance, arrière-plans CSS.
• Google Search Central : corriger le contenu en chargement différé — lazy loading et indexation.
• Google Search Central : Core Web Vitals — seuils et rôle dans la recherche.
• Chrome for Developers : Lighthouse is moving to performance insight audits (28 avril 2025) — retrait de l’audit des images hors écran.
• Deloitte, Milliseconds Make Millions (2020) — vitesse et conversion.
• web.dev, Vodafone : +31 % de LCP, +8 % de ventes (2021).

Questions fréquentes

Vous voulez le lazy loading dans toute la boutique sans modifier le thème ? Découvrez le module Lazy loading automatique ou contactez-nous pour toute question sur votre boutique.

Produits de cet article

Lazy loading automatique

39,00 € 19,50 €

• -50%
• Neuf

Note sur 5 étoiles d'après () avis

Ajouter au panier

Retour : Blog