Ce que le chargement paresseux fait réellement à votre Largest Contentful Paint

Le chargement paresseux est une décision d’ordonnancement, pas une formule magique de vitesse

Le chargement paresseux est souvent présenté comme une amélioration des performances, ce qui est vrai de la même manière que ne pas faire sa valise réduit son poids. Il aide parce que le navigateur fait moins de travail au départ.

Cette distinction est importante pour le Largest Contentful Paint, généralement abrégé en LCP. Le LCP mesure le moment où le plus grand élément significatif de la fenêtre d’affichage est rendu. Sur de nombreuses pages, cet élément est une image hero. Sur d’autres, c’est un grand titre, une image d’affiche, une photo de produit ou un bloc de contenu.

Le chargement paresseux modifie le moment où les ressources sont demandées. Il ne fait pas décoder une image plus vite, ne fait pas répondre un serveur plus vite et ne fait pas s’afficher une police plus tôt. Si vous chargez paresseusement le mauvais élément, en particulier celui qui devient le LCP, vous dites au navigateur d’attendre avant de récupérer précisément ce qu’il doit afficher pour réussir les Core Web Vitals.

C’est pourquoi le chargement paresseux est à la fois trop utilisé et trop mal compris.

Ce que fait le navigateur lorsque vous chargez une image paresseusement

Le chargement paresseux natif des images est généralement ajouté ainsi :

<img src='hero.jpg' loading='lazy' alt='...'>

Avec loading='lazy', le navigateur est autorisé à différer la récupération de l’image jusqu’à ce qu’il estime qu’elle sera probablement nécessaire. En pratique, les navigateurs utilisent la distance par rapport à la fenêtre d’affichage, les conditions réseau, les dimensions de l’image et d’autres heuristiques. Les règles exactes sont des détails d’implémentation et peuvent changer.

Avec loading='eager', ou sans attribut lazy dans la plupart des cas, le navigateur traite l’image comme faisant partie du processus de chargement normal. Il doit toujours établir des priorités entre CSS, JavaScript, polices, images et autres requêtes, mais l’image est découvrable immédiatement.

Cela signifie que le chargement paresseux affecte principalement trois phases :

• Découverte : le moment où le navigateur remarque la ressource.
• Début de la requête : le moment où la récupération réseau commence.
• Moment du rendu : le moment où la ressource peut enfin être décodée et peinte.

Pour le LCP, le point dangereux est le début de la requête. Si la requête de l’image LCP commence tard, tout ce qui suit est décalé aussi.

La règle simple : ne chargez jamais paresseusement le candidat LCP

Si une image est visible dans la fenêtre d’affichage initiale et qu’elle est susceptible d’être le plus grand élément contentful, ne la chargez pas paresseusement.

Cela inclut :

• les images hero
• les photos principales de produits au-dessus de la ligne de flottaison
• les grandes images d’introduction d’article
• les grandes images de type arrière-plan implémentées avec <img>
• les images d’affiche vidéo lorsque l’affiche est l’élément visuel principal

Le navigateur ne peut pas afficher l’image LCP tant qu’elle n’a pas été demandée, transférée, décodée et peinte. Le chargement paresseux introduit de l’incertitude avant la première étape. Même un petit délai peut suffire à faire passer le LCP d’acceptable à mauvais sur une connexion plus lente.

Un schéma d’échec courant ressemble à ceci :

1. Le serveur envoie le HTML.
2. Le navigateur analyse une image au-dessus de la ligne de flottaison.
3. L’image a loading='lazy'.
4. Le navigateur attend parce que l’heuristique de chargement paresseux indique qu’il le peut.
5. Le CSS et le JavaScript continuent de se charger.
6. La requête de l’image commence plus tard qu’elle ne le devrait.
7. Le LCP est en retard, même si le fichier image lui-même est raisonnablement optimisé.

C’est frustrant parce que la page peut sembler propre lors d’une revue de code. Le problème n’est pas seulement la taille du fichier. C’est la priorité.

Si vous lisez une sortie de laboratoire et essayez de déterminer si le LCP est réellement le problème, notre guide pour lire un rapport Lighthouse sans paniquer est volontairement pratique : séparez les données terrain, les indices de laboratoire et les correctifs avant de commencer à modifier le code. (Remarque : si votre routage est sensible à la casse, utilisez l’URL exacte de votre CMS.)

Correction : utilisez l’URL interne réelle

La bonne URL de l’article Wux est Comment lire un rapport Lighthouse sans paniquer. Le point reste le même : identifiez l’élément LCP avant de modifier le comportement de chargement.

Quand le chargement paresseux peut améliorer le LCP

Le chargement paresseux peut améliorer le LCP indirectement lorsqu’il écarte les ressources non critiques du chemin du navigateur.

Imaginez une page produit avec une image hero du produit en haut et un carrousel de douze images de recommandations sous la ligne de flottaison. Si les treize images se chargent immédiatement, le navigateur peut consacrer de la bande passante et des connexions à des images que l’utilisateur ne peut pas encore voir. Sur un réseau contraint, cela peut entrer en concurrence avec l’image hero, le CSS ou les fichiers de police.

Charger paresseusement les images du carrousel sous la ligne de flottaison peut aider l’image LCP à se charger plus tôt, car moins de requêtes non critiques se disputent les ressources pendant le chargement initial de la page.

C’est le cas de performance légitime du chargement paresseux :

• charger immédiatement le candidat LCP au-dessus de la ligne de flottaison
• charger paresseusement les images sous la fenêtre d’affichage initiale
• éviter les scripts lourds qui injectent tardivement des images importantes
• conserver les dimensions d’image dans le HTML pour éviter les décalages de mise en page

Le chargement paresseux n’est pas une optimisation LCP en soi. C’est un outil de priorisation des ressources. Il aide lorsqu’il protège le chemin critique.

Le meilleur modèle pour les images LCP

Pour une image LCP au-dessus de la ligne de flottaison, l’objectif est de permettre au navigateur de la découvrir tôt, de la demander tôt et de la rendre sans instabilité de mise en page.

Une base solide ressemble à ceci :

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Les parties importantes ne sont pas décoratives :

• loading='eager' empêche le délai du chargement paresseux.
• fetchpriority='high' indique au navigateur que cette image compte.
• width et height réservent de l’espace et réduisent les décalages de mise en page.
• srcset et sizes évitent les téléchargements surdimensionnés.
• Un format moderne peut réduire le temps de transfert lorsqu’il est utilisé avec soin.

Si vous servez encore un grand JPEG unique à tous les écrans, le format d’image et le dimensionnement responsive peuvent compter davantage que l’attribut de chargement paresseux. Pour un arbre de décision pratique, consultez quand AVIF bat WebP et quand ce n’est pas le cas.

Les images d’arrière-plan exigent une attention particulière

Les images d’arrière-plan CSS ne sont pas découvertes aussi tôt que les images HTML normales. Le navigateur doit récupérer et analyser le CSS avant de les connaître. Si votre élément LCP est une image d’arrière-plan CSS, vous avez déjà rendu la découverte plus difficile.

Cela ne signifie pas que les images d’arrière-plan sont interdites. Cela signifie que vous devez être intentionnel.

Pour les images décoratives, les arrière-plans CSS conviennent. Pour une image hero significative, un élément <img> ou <picture> est généralement préférable, car il est visible pour l’analyseur HTML, prend en charge le texte alternatif et fonctionne bien avec les attributs d’image responsive.

Si vous devez utiliser un arrière-plan CSS pour une image LCP, envisagez de la précharger :

<link rel='preload' as='image' href='/images/hero.avif'>

Le préchargement n’est pas non plus une baguette magique. Précharger trop d’images crée le même problème de priorité sous un autre déguisement. Utilisez-le pour l’unique image qui compte vraiment, pas pour chaque image du design system.

Le chargement paresseux JavaScript aggrave souvent les choses

Avant que le chargement paresseux natif soit largement pris en charge, de nombreux sites utilisaient des bibliothèques JavaScript qui remplaçaient data-src par src après le chargement de la page ou après le déclenchement d’un observateur d’intersection. Certains le font encore.

Cela peut être raisonnable pour de longues pages d’articles ou des galeries riches en images. C’est un mauvais choix pour le contenu au-dessus de la ligne de flottaison.

Le scanner de préchargement du navigateur est rapide, mais il ne peut pas demander une image dont l’URL est cachée dans un attribut personnalisé tant que JavaScript ne s’exécute pas. Si votre image hero commence par data-src='hero.jpg', vous avez retardé sa découverte derrière le téléchargement du script, son analyse, son exécution et l’hydratation du framework.

C’est un mauvais compromis pour le LCP. Placez les URL d’images critiques dans du vrai HTML. Laissez le navigateur faire son travail.

Le LCP n’est pas toujours un problème d’image

Sur certaines pages, l’élément LCP est du texte. Dans ce cas, le chargement paresseux des images peut avoir peu d’effet direct. Votre goulot d’étranglement peut être le CSS bloquant le rendu, une réponse serveur lente, le rendu côté client ou les polices web.

Les polices méritent d’être mentionnées, car elles sont une cause cachée fréquente de rendu tardif du texte. Un grand titre peut devenir le LCP, et le comportement de chargement des polices peut retarder ou modifier le moment où ce titre est peint. Si votre travail sur les images ne fait pas bouger la métrique, inspectez directement l’élément LCP plutôt que de supposer. Notre article sur les polices web comme gain de performance couvre les correctifs ennuyeux qui fonctionnent souvent : moins de graisses, des formats modernes, des fallbacks sensés.

Comment tester les changements de chargement paresseux sans vous tromper vous-même

Ne testez pas en fixant votre page sur le Wi-Fi du bureau. Vous devez voir le moment des requêtes.

Utilisez ce flux de travail :

1. Ouvrez Chrome DevTools et enregistrez une trace Performance.
2. Activez la limitation réseau, par exemple Fast 4G ou Slow 4G.
3. Rechargez la page avec le cache désactivé.
4. Trouvez le marqueur LCP.
5. Identifiez l’élément LCP.
6. Dans le panneau Network, vérifiez quand cette ressource a commencé à se charger.

Si la ressource LCP commence tard, demandez-vous pourquoi :

• A-t-elle été chargée paresseusement ?
• A-t-elle été injectée par JavaScript ?
• Était-elle cachée dans le CSS ?
• A-t-elle été dépriorisée derrière d’autres images ?
• Le serveur a-t-il répondu lentement ?

Ensuite, faites un seul changement et retestez. Le travail de performance devient confus lorsque les équipes modifient le format d’image, le chargement paresseux, le préchargement, les bundles JavaScript et les paramètres CDN dans le même déploiement. Vous pouvez améliorer la page, mais vous ne saurez pas quel changement a compté.

Les données terrain comptent aussi. Les outils de laboratoire sont utiles pour le diagnostic, mais le LCP varie selon l’appareil, le réseau, la fenêtre d’affichage, l’état du cache et la géographie. Utilisez la surveillance des utilisateurs réels ou les données Chrome User Experience Report lorsque vous le pouvez.

<!-- tool-cta:start -->

💡 Essayez ceci : Gardez votre image LCP petite et chargée en priorité en la passant dans Image Compressor, afin qu’elle s’affiche rapidement sans nécessiter de lazy loading.

<!-- tool-cta:end -->

Une politique pratique pour la plupart des sites web

Pour la plupart des sites marketing, pages ecommerce, sites de documentation et pages d’éditeurs, cette politique suffit :

• Image principale au-dessus de la ligne de flottaison : chargement immédiat, envisager une priorité de récupération élevée.
• Images de contenu sous la ligne de flottaison : chargement paresseux.
• Icônes et petits éléments d’interface : généralement pas la peine d’y penser individuellement.
• Hero en arrière-plan CSS : reconsidérer comme image HTML ou précharger avec soin.
• Image hero injectée par JavaScript : corriger l’architecture de rendu si possible.
• Carrousels : charger immédiatement uniquement la première diapositive visible ; charger paresseusement le reste.

Il existe des cas limites. Les heuristiques des navigateurs s’améliorent. Les frameworks ajoutent des composants d’image automatiques. Certaines plateformes évitent désormais de charger paresseusement les images détectées près de la fenêtre d’affichage. Pourtant, le principe ne change pas : les ressources critiques doivent être précoces et évidentes ; les ressources non critiques doivent attendre.

Le chargement paresseux est précieux lorsqu’il exprime cette distinction. Il est nuisible lorsqu’il cache au navigateur le contenu le plus important jusqu’à ce que la page ait déjà commencé à perdre la course au LCP.