Votre plus grande image se charge en dernier ? Le lazy loading est sans doute le coupable
Le lazy loading est l'optimisation la plus recommandée du web et l'une des plus mal appliquées. Posé partout sans réfléchir, il fait exactement l'inverse de ce qu'on attend de lui : il retarde l'image que Google chronomètre pour calculer votre LCP. Résultat, un site plus léger sur le papier, mais plus lent là où ça compte.
Dans cet article, vous allez découvrir :
- •Ce que fait vraiment l'attribut
loading="lazy"natif, et les cas qu'il ne couvre pas - •L'erreur la plus fréquente en audit de performance : l'image principale chargée en différé
- •La règle en une phrase pour décider quelle image différer et laquelle charger en priorité
- •Ce que next/image gère automatiquement (dimensions, formats, priorité) et pourquoi ça change tout
- •L'effet mesurable sur les Core Web Vitals, et comment le vérifier en cinq minutes
Une image différée est une image que le navigateur découvre tard. Si c'est votre image principale, vous avez ajouté du délai exactement là où Google mesure.
Le lazy loading, c'est quoi exactement ?
Le lazy loading (ou chargement différé) consiste à ne télécharger une ressource qu'au moment où elle devient nécessaire, généralement quand elle approche de la zone visible de l'écran. Appliqué aux images, il évite de charger au démarrage de la page des visuels que le visiteur ne verra peut-être jamais.
Le raisonnement est simple. Une page web type embarque une dizaine, parfois une cinquantaine d'images. Au premier affichage, le visiteur n'en voit que deux ou trois : celles situées « au-dessus de la ligne de flottaison ». Les autres attendent plus bas et n'ont aucune raison de concurrencer les ressources critiques pour la bande passante.
Ce que le navigateur fait concrètement
Sans lazy loading, le navigateur analyse le HTML, découvre chaque balise <img> et lance immédiatement toutes les requêtes. Les images se partagent la connexion avec les polices, le CSS et le JavaScript. Tout arrive un peu plus tard.
Avec lazy loading, le navigateur ne demande une image que lorsqu'elle approche du viewport. Les ressources du haut de page arrivent plus vite, la page devient utilisable plus tôt et la consommation de données baisse, ce qui compte sur mobile.
Les trois façons de le mettre en place
| Méthode | Comment | Points forts | Limites |
|---|---|---|---|
Attribut natif loading="lazy" | Un attribut HTML sur <img> ou <iframe> | Zéro JavaScript, supporté par tous les navigateurs modernes | Pas de contrôle fin du seuil, ne gère pas les fonds CSS |
| Bibliothèque JavaScript (Intersection Observer) | Script qui remplace data-src par src au scroll | Seuils et animations personnalisables | Dépendance, risque pour l'indexation si mal fait |
| Composant de framework (next/image) | Composant qui génère la balise optimale | Lazy par défaut, formats, dimensions et priorité gérés | Lié à la stack Next.js |
L'attribut loading natif : ce qu'il couvre et ce qu'il ignore
L'attribut loading accepte deux valeurs : lazy pour différer le chargement, eager pour forcer le chargement immédiat. En l'absence d'attribut, le comportement par défaut est eager.
<img src="/img/atelier-marseille.webp" alt="Atelier ONDEV à Marseille" width="1200" height="800" loading="lazy">Il est supporté nativement par Chrome depuis la version 77 (2019), Firefox depuis la 75 (2020) et Safari depuis la 15.4 (2022). Autrement dit, aucun polyfill n'est nécessaire aujourd'hui, et un navigateur qui ne le connaît pas charge simplement l'image normalement. C'est une amélioration progressive sans risque.
Le seuil de déclenchement n'est pas le bord de l'écran
Le navigateur n'attend pas que l'image soit visible pour la demander : il anticipe. Chrome déclenche le chargement quand l'image arrive à environ 1 250 px du viewport sur une connexion rapide, et jusqu'à 2 500 px sur une connexion lente, selon la documentation de Chrome sur le lazy loading natif. Ce seuil explique pourquoi, sur une page courte, presque toutes les images se chargent quand même immédiatement : elles sont toutes dans la zone d'anticipation.
Ce que l'attribut ne fait pas
C'est le point que beaucoup oublient. loading="lazy" répond à une seule question : quand télécharger. Il ne répond pas aux autres :
- •Il ne redimensionne rien. Une image de 4 000 px affichée dans un bloc de 400 px reste une image de 4 000 px, chargée tard mais lourde quand même.
- •Il ne convertit rien. Un JPEG reste un JPEG. Le passage en WebP ou AVIF est un chantier distinct, que nous détaillons dans notre guide pour optimiser les images de votre site web.
- •Il ignore les images de fond CSS. Un
background-imagen'est pas une balise<img>, l'attribut n'a aucune prise dessus. - •Il ne réserve pas d'espace. Sans
widthetheight, l'image différée provoque un saut de mise en page à son arrivée, donc du CLS.
L'erreur classique : mettre l'image principale en lazy
C'est l'erreur que nous rencontrons le plus souvent en audit, et elle est presque toujours involontaire. Un thème, un plugin ou un réglage global applique loading="lazy" à toutes les images du site. L'image héro, celle qui occupe l'écran à l'arrivée, est traitée comme les autres. Elle est différée.
Pourquoi ça dégrade le LCP
Le LCP (Largest Contentful Paint) mesure le moment où le plus grand élément visible de la page est affiché. Dans l'immense majorité des cas, cet élément est une image. Google en fait l'un de ses trois Core Web Vitals, avec un seuil de bonne expérience fixé à 2,5 secondes.
Quand l'image LCP porte loading="lazy", la chaîne d'événements change :
- 1.Le navigateur lit le HTML et repère l'image, mais la marque comme différée.
- 2.Il attend d'avoir calculé la mise en page pour savoir si elle se trouve dans le viewport.
- 3.Il constate qu'elle y est, et seulement alors lance la requête.
Les étapes 2 et 3 représentent plusieurs centaines de millisecondes perdues sur une image qui aurait dû partir dans la toute première vague de requêtes. Lighthouse signale d'ailleurs ce cas avec un avertissement explicite : l'image LCP a été chargée en différé. Si vous voyez ce message dans un rapport, vous avez trouvé votre premier chantier.
La correction en trois lignes
<img src="/img/hero.webp" alt="Vitrage automobile à Marseille" width="1600" height="900" loading="eager" fetchpriority="high">- •
loading="eager"(ou pas d'attribut du tout) remet l'image dans la vague initiale. - •
fetchpriority="high"indique au navigateur qu'elle passe avant les autres ressources de même type. - •Pour aller plus loin, une balise
<link rel="preload" as="image">dans le<head>lance la requête avant même que le HTML soit entièrement analysé.
Le lazy loading est un outil pour le bas de page. Appliqué au haut de page, il travaille contre vous. Notre guide Core Web Vitals détaille les autres leviers du LCP (serveur, polices, rendu) si l'image n'est pas votre seul problème.
La règle simple pour décider quelle image différer
La règle que nous appliquons tient en une phrase : si l'image est visible sans scroller sur un écran de mobile, elle se charge en eager ; sinon, elle se charge en lazy.
Pourquoi le mobile comme référence ? Parce que c'est là que Google mesure vos Core Web Vitals en priorité, et parce que la ligne de flottaison y est la plus haute. Une image qui est au-dessus du pli sur mobile le sera aussi sur desktop.
Le tri image par image
| Élément | Décision | Pourquoi |
|---|---|---|
| Image héro, bannière d'accueil | eager + fetchpriority="high" | Candidate LCP quasi certaine |
| Logo dans l'en-tête | eager | Visible immédiatement, très léger |
| Première image d'un article | eager | Souvent l'élément LCP sur une page de blog |
| Première slide d'un carrousel | eager | Les slides suivantes passent en lazy |
| Vignettes d'une grille de produits ou de réalisations | lazy à partir de la deuxième rangée | La première rangée est souvent visible |
| Images dans le corps du texte | lazy | Sous le pli dans la quasi-totalité des cas |
| Avatars, logos partenaires en pied de page | lazy | Jamais visibles à l'arrivée |
| Iframes (vidéos, cartes) | lazy | Les plus lourdes de la page, presque toujours sous le pli |
La précaution qui évite le CLS
Toujours renseigner width et height. Le navigateur réserve ainsi la place exacte avant l'arrivée de l'image, différée ou non. Ces attributs ne figent pas la taille affichée (le CSS garde la main), ils donnent simplement le ratio.
Ce que next/image fait automatiquement
Tout ce qui précède est faisable à la main. Mais sur un site de deux cents pages maintenu par plusieurs personnes, l'application rigoureuse de la règle est illusoire : quelqu'un finira par poser une image héro sans fetchpriority ou oublier les dimensions. C'est précisément ce que le composant next/image corrige.
import Image from "next/image";
<Image
src="/img/hero.webp"
alt="Vitrage automobile à Marseille"
width={1600}
height={900}
priority
sizes="100vw"
/>Les cinq décisions prises à votre place
- •Lazy loading par défaut. Toute image sans la prop
priorityreçoitloading="lazy". Vous n'avez rien à écrire pour le bas de page. - •Priorité explicite pour le haut de page. La prop
priorityajoutefetchpriority="high", retire le lazy et génère un preload. Une seule prop, les trois bonnes pratiques. - •Dimensions obligatoires. Le composant refuse de compiler sans
widthetheight(oufill). Le CLS lié aux images disparaît par construction. - •Formats modernes et srcset. Next.js sert du WebP ou de l'AVIF selon le navigateur, et génère plusieurs tailles. Le mobile reçoit une image de 640 px, le desktop une de 1 920 px, à partir du même fichier source.
- •Placeholder flou. La prop
placeholder="blur"affiche une version minuscule de l'image pendant le chargement, ce qui améliore la perception de vitesse.
C'est l'une des raisons pour lesquelles nous considérons Next.js comme le meilleur framework pour un site en 2026 : les bonnes pratiques de performance ne reposent pas sur la discipline de l'équipe, elles sont dans l'outil.
En pratique : Sudparebrise
Sur la refonte du site de Sudparebrise, spécialiste du vitrage automobile, chaque page de service embarque une image principale en priority et une galerie différée. Combiné au rendu statique et aux formats modernes, le site atteint un score Lighthouse de 100. Pas 92, pas 97 : 100, sur un site vitrine riche en visuels. Le lazy loading bien placé n'est pas le seul facteur, mais sans lui l'image héro aurait plafonné le LCP.
Si votre site actuel ne vous laisse pas cette maîtrise, c'est le genre de fondation que nous posons dès le départ dans notre service de création de sites internet à Marseille : la performance n'est pas une phase d'optimisation après livraison, c'est une propriété de l'architecture.
À lire aussi : Optimiser les images de votre site web - formats, compression et dimensions : les trois chantiers qui accompagnent le lazy loading pour une page vraiment légère.
L'effet mesurable sur les Core Web Vitals
Le lazy loading touche surtout deux métriques, et pas de la même façon.
LCP : l'effet le plus direct
Bien appliqué (image héro en eager, le reste en lazy), le lazy loading libère la bande passante pour l'image LCP, qui arrive plus tôt. Mal appliqué (héro en lazy), il ajoute le délai décrit plus haut. C'est la métrique où l'on voit la différence le plus vite dans Lighthouse.
CLS : neutre si les dimensions sont là, négatif sinon
Une image différée qui arrive sans espace réservé pousse le contenu vers le bas. Avec width et height, l'espace est réservé dès le rendu initial et le CLS n'est pas affecté. Sans eux, chaque image lazy devient un décalage potentiel.
Comment vérifier en cinq minutes
- 1.Lancez PageSpeed Insights sur votre page d'accueil en mode mobile.
- 2.Dans la section Diagnostics, cherchez l'avertissement concernant une image LCP chargée en différé.
- 3.Ouvrez l'onglet Réseau des outils de développement, rechargez la page et regardez l'ordre des requêtes : l'image héro doit figurer dans les premières lignes.
- 4.Scrollez et confirmez que les images du bas ne partent qu'à l'approche du viewport.
- 5.Comparez avec les données réelles de la Search Console (rapport Signaux Web essentiels) : c'est ce que Google utilise, pas le score de laboratoire.
Lazy loading et SEO : ce que Google indexe
Google indexe sans difficulté les images portant l'attribut natif loading="lazy", parce que la balise <img> et son src sont dans le HTML. Le risque concerne les anciennes bibliothèques JavaScript qui stockent l'URL dans un data-src et ne la déplacent dans src qu'au scroll : Googlebot ne scrolle pas, et ces images peuvent ne jamais être découvertes. Si vous héritez d'un site avec ce type de script, migrez vers l'attribut natif : c'est à la fois plus simple et plus sûr.
Questions fréquentes sur le lazy loading
Le rapport Signaux Web essentiels est l'un des premiers tableaux que nous ouvrons dans notre accompagnement en référencement naturel : un LCP dégradé par une image différée se corrige en quelques lignes, encore faut-il le voir.
Faut-il mettre loading="lazy" sur toutes les images ?
eager, idéalement avec fetchpriority="high". Le lazy loading est réservé aux images situées sous la ligne de flottaison.Le lazy loading est-il mauvais pour le SEO ?
<img> et son src directement dans le HTML, le chargement différé ne change rien à l'indexation. Le risque existe seulement avec des scripts qui cachent l'URL dans un data-src jusqu'au scroll, car Googlebot ne scrolle pas.Quelle différence entre loading="lazy" et un plugin de lazy loading ?
Le lazy loading suffit-il à rendre une page rapide ?
Comment savoir si mon image LCP est en lazy ?
loading="lazy".Que fait la prop priority dans next/image ?
fetchpriority="high" et insère une balise de preload dans le <head>. C'est la prop à poser sur l'image héro de chaque page, et sur elle seulement : plusieurs images en priority se font concurrence et annulent le bénéfice.En résumé : différer les bonnes images, jamais la principale
Le lazy loading est une optimisation à double tranchant. Posé sur les images du bas de page, il allège le démarrage et libère la bande passante pour ce qui compte. Posé sur l'image principale, il retarde précisément l'élément que Google chronomètre. La règle est simple : visible sans scroller sur mobile, eager ; sinon, lazy. Et pour que cette règle survive à la vie d'un site, mieux vaut un outil comme next/image qui l'applique à votre place.
Si vos Core Web Vitals sont dans l'orange et que vous ne savez pas par où commencer, l'ordre de chargement des images est souvent le premier levier, et le moins coûteux.
Vous voulez un diagnostic clair de la performance de votre site et un plan d'action concret ? Parlons de votre projet : nous regardons vos images, votre LCP et votre stack, et nous vous disons ce qui pèse vraiment.
