Chargement différé des images et des éléments <iframe>

Les images et les éléments <iframe> consomment souvent plus de bande passante que les autres types de ressources. Dans le cas des éléments <iframe>, le chargement et le rendu des pages qu'ils contiennent peuvent nécessiter un temps de traitement supplémentaire important.

Dans le cas du chargement paresseux des images, le report du chargement des images situées en dehors de la fenêtre d'affichage initiale peut être utile pour réduire les conflits de bande passante pour les ressources plus critiques dans la fenêtre d'affichage initiale. Cela peut améliorer le LCP (Largest Contentful Paint) d'une page dans certains cas où les connexions réseau sont médiocres, et la bande passante réallouée peut aider les candidats au LCP à se charger et à peindre plus rapidement.

Pour les éléments <iframe>, l'interaction jusqu'au prochain rendu (INP) d'une page peut être améliorée au démarrage en les chargeant de manière différée. En effet, un <iframe> est un document HTML complètement distinct avec ses propres sous-ressources. Bien que les éléments <iframe> puissent être exécutés dans un processus distinct, il n'est pas rare qu'ils partagent un processus avec d'autres threads, ce qui peut créer des conditions dans lesquelles les pages deviennent moins réactives aux entrées utilisateur.

Par conséquent, le report du chargement des images hors écran et des éléments <iframe> est une technique à privilégier. Elle nécessite un effort relativement faible pour un retour raisonnable en termes de performances. Ce module explique comment charger de manière différée ces deux types d'éléments pour une expérience utilisateur plus rapide et meilleure pendant la période de démarrage critique de la page.

Charger des images de manière différée avec l'attribut loading

L'attribut loading peut être ajouté aux éléments <img> pour indiquer aux navigateurs comment ils doivent être chargés:

  • "eager" informe le navigateur que l'image doit être chargée immédiatement, même si elle se trouve en dehors du viewport initial. Il s'agit également de la valeur par défaut de l'attribut loading.
  • "lazy" diffère le chargement d'une image jusqu'à ce qu'elle se trouve à une distance définie de la fenêtre d'affichage visible. Cette distance varie selon le navigateur, mais elle est souvent définie de manière à être suffisamment importante pour que l'image se charge au moment où l'utilisateur y accède.

Notez également que si vous utilisez l'élément <picture>, l'attribut loading doit toujours être appliqué à son élément enfant <img>, et non à l'élément <picture> lui-même. En effet, l'élément <picture> est un conteneur qui contient des éléments <source> supplémentaires pointant vers différentes images candidates, et l'image candidate choisie par le navigateur est appliquée directement à son élément <img> enfant.

Ne pas charger les images de manière différée dans la fenêtre d'affichage initiale

Vous ne devez ajouter l'attribut loading="lazy" qu'aux éléments <img> situés en dehors de la fenêtre d'affichage initiale. Toutefois, il peut être complexe de connaître la position exacte d'un élément par rapport au viewport avant l'affichage de la page. Vous devez tenir compte des différentes tailles, proportions et appareils de la fenêtre d'affichage.

Par exemple, une fenêtre d'affichage sur ordinateur de bureau peut être très différente d'une fenêtre d'affichage sur un téléphone mobile, car elle affiche plus d'espace vertical, ce qui peut permettre d'afficher des images dans la fenêtre d'affichage initiale qui n'apparaîtraient pas dans celle d'un appareil physiquement plus petit. Les tablettes utilisées en mode portrait affichent également une quantité considérable d'espace vertical, peut-être même plus que certains appareils de bureau.

Toutefois, dans certains cas, il est assez clair que vous devez éviter d'appliquer loading="lazy". Par exemple, vous devez impérativement omettre l'attribut loading="lazy" des éléments <img> dans le cas d'images hero ou d'autres cas d'utilisation d'images où les éléments <img> sont susceptibles d'apparaître au-dessus de la ligne de flottaison ou en haut de la mise en page sur n'importe quel appareil. Cela est encore plus important pour les images susceptibles d'être des candidates à la LCP.

Les images chargées de manière paresseuse doivent attendre que le navigateur termine la mise en page pour savoir si leur position finale se trouve dans le viewport. Cela signifie que si un élément <img> dans le viewport visible possède un attribut loading="lazy", il n'est demandé qu'après le téléchargement, l'analyse et l'application de tous les fichiers CSS à la page, au lieu d'être extrait dès qu'il est détecté par le scanner de précharge dans le balisage brut.

Étant donné que l'attribut loading de l'élément <img> est compatible avec tous les principaux navigateurs, il n'est pas nécessaire d'utiliser JavaScript pour charger les images de manière différée, car l'ajout de JavaScript supplémentaire à une page pour fournir des fonctionnalités que le navigateur fournit déjà affecte d'autres aspects des performances de la page, tels que l'INP.

Démonstration du chargement différé des images

Charger différé des éléments <iframe>

Le chargement paresseux des éléments <iframe> jusqu'à ce qu'ils soient visibles dans le viewport peut économiser des données importantes et améliorer le chargement des ressources critiques requises pour le chargement de la page de premier niveau. De plus, comme les éléments <iframe> sont essentiellement des documents HTML entiers chargés dans un document de niveau supérieur, ils peuvent inclure un nombre important de sous-ressources, en particulier JavaScript, ce qui peut affecter considérablement l'INP d'une page si les tâches de ces cadres nécessitent un temps de traitement important.

Les éléments <iframe> sont souvent utilisés pour intégrer des éléments tiers. Par exemple, les lecteurs vidéo intégrés ou les posts sur les réseaux sociaux utilisent souvent des éléments <iframe>. Ils nécessitent souvent un nombre important de sous-ressources, ce qui peut également entraîner des conflits de bande passante pour les ressources de la page de premier niveau. Par exemple, le chargement différé de l'intégration d'une vidéo YouTube permet d'économiser plus de 500 ko lors du chargement initial de la page, tandis que le chargement différé du plug-in du bouton "J'aime" de Facebook permet d'économiser plus de 200 ko, dont la plupart sont des fichiers JavaScript.

Dans tous les cas, chaque fois que vous avez un <iframe> en dessous de la ligne de flottaison sur une page, vous devez envisager sérieusement de le charger de manière différée s'il n'est pas essentiel de le charger au préalable, car cela peut améliorer considérablement l'expérience utilisateur.

Attribut loading pour les éléments <iframe>

L'attribut loading sur les éléments <iframe> est également compatible avec tous les principaux navigateurs. Les valeurs de l'attribut loading et leurs comportements sont les mêmes que pour les éléments <img> qui utilisent l'attribut loading:

  • "eager" est la valeur par défaut. Il indique au navigateur de charger immédiatement le code HTML de l'élément <iframe> et ses sous-ressources.
  • "lazy" diffère le chargement du code HTML de l'élément <iframe> et de ses sous-ressources jusqu'à ce qu'il se trouve à une distance prédéfinie de la fenêtre d'affichage.

Démonstration du chargement différé des iFrames

Façades

Au lieu de charger un élément intégré immédiatement lors du chargement de la page, vous pouvez le charger à la demande en réponse à une interaction de l'utilisateur. Pour ce faire, affichez une image ou un autre élément HTML approprié jusqu'à ce que l'utilisateur interagisse avec lui. Une fois que l'utilisateur interagit avec l'élément, vous pouvez le remplacer par l'intégration tierce. Cette technique est appelée façade.

Les façades sont souvent utilisées pour intégrer des vidéos à partir de services tiers, où l'intégration peut impliquer le chargement de nombreuses sous-ressources supplémentaires et potentiellement coûteuses (telles que JavaScript) en plus du contenu vidéo lui-même. Dans ce cas, sauf si la lecture automatique d'une vidéo est nécessaire, les vidéos intégrées nécessitent que l'utilisateur interagisse avec elles avant la lecture en cliquant sur le bouton de lecture.

Il s'agit d'une excellente opportunité de présenter une image statique visuellement semblable à l'intégration vidéo et d'économiser une bande passante importante. Une fois que l'utilisateur a cliqué sur l'image, elle est remplacée par l'intégration <iframe> réelle, qui déclenche le téléchargement de l'élément <iframe> tiers et de ses sous-ressources.

En plus d'améliorer le chargement initial de la page, cette approche présente un autre avantage majeur : si l'utilisateur ne lit jamais la vidéo, les ressources nécessaires à sa diffusion ne sont jamais téléchargées. Il s'agit d'un bon modèle, car il garantit que l'utilisateur ne télécharge que ce qu'il veut réellement, sans faire d'hypothèses potentiellement erronées sur ses besoins.

Les widgets de chat sont un autre excellent cas d'utilisation de la technique de façade. La plupart des widgets de chat téléchargent des quantités importantes de code JavaScript qui peuvent avoir un impact négatif sur le chargement de la page et la réactivité aux entrées utilisateur. Comme pour le chargement de tout élément à l'avance, le coût est engagé au moment du chargement, mais dans le cas d'un widget de chat, tous les utilisateurs n'ont pas l'intention d'interagir avec lui.

En revanche, avec une façade, vous pouvez remplacer le bouton tiers "Démarrer la discussion" par un faux bouton. Une fois que l'utilisateur interagit avec lui de manière significative (par exemple, en maintenant un pointeur dessus pendant une durée raisonnable ou en cliquant dessus), le widget de chat fonctionnel est inséré à sa place lorsque l'utilisateur en a besoin.

Bien qu'il soit possible de créer vos propres façades, des options Open Source sont disponibles pour les tiers les plus populaires, comme lite-youtube-embed pour les vidéos YouTube, lite-vimeo-embed pour les vidéos Vimeo et React Live Chat Loader pour les widgets de chat.

Bibliothèques de chargement différé JavaScript

Si vous devez charger de manière différée des éléments <video>, des images poster d'éléments <video>, des images chargées par la propriété CSS background-image ou d'autres éléments non compatibles, vous pouvez le faire avec une solution de chargement différé basée sur JavaScript, telle que lazysizes ou yall.js, car le chargement différé de ces types de ressources n'est pas une fonctionnalité au niveau du navigateur.

En particulier, la lecture automatique et la mise en boucle des éléments <video> sans piste audio constituent une alternative beaucoup plus efficace que l'utilisation de GIF animés, qui peuvent souvent être plusieurs fois plus volumineux qu'une ressource vidéo de qualité visuelle équivalente. Toutefois, ces vidéos peuvent toujours être importantes en termes de bande passante. Le chargement différé est donc une optimisation supplémentaire qui peut contribuer à réduire considérablement le gaspillage de bande passante.

La plupart de ces bibliothèques fonctionnent à l'aide de l'API Intersection Observer (et de l'API Mutation Observer si le code HTML d'une page change après le chargement initial) pour détecter quand un élément entre dans le champ de vision de l'utilisateur. Si l'image est visible ou approche du viewport, la bibliothèque JavaScript remplace l'attribut non standard (souvent data-src ou un attribut similaire) par l'attribut approprié, tel que src.

Imaginons que vous ayez une vidéo qui remplace un GIF animé, mais que vous souhaitiez la charger de manière différée avec une solution JavaScript. C'est possible avec yall.js avec le modèle de balisage suivant:

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

Par défaut, yall.js observe tous les éléments HTML éligibles avec une classe "lazy". Une fois yall.js chargé et exécuté sur la page, la vidéo n'est pas chargée tant que l'utilisateur ne la fait pas défiler dans la fenêtre d'affichage. À ce stade, les attributs data-src des éléments <source> enfants de l'élément <video> sont remplacés par des attributs src, qui envoient une requête pour télécharger la vidéo et commencer automatiquement à la lire.

Tester vos connaissances

Quelle est la valeur par défaut de l'attribut loading pour les éléments <img> et <iframe> ?

"eager"
Bonne réponse !
"lazy"
Réessayez.

Dans quels cas est-il raisonnable d'utiliser des solutions de chargement différé basées sur JavaScript ?

Pour toute ressource pouvant être chargée de manière différée.
Réessayez.
Pour les ressources pour lesquelles l'attribut loading n'est pas compatible, comme dans le cas des vidéos en lecture automatique destinées à remplacer les images animées ou à charger de manière différée l'image de l'affiche d'un élément <video>.
Bonne réponse !

Dans quel cas une façade est-elle une technique utile ?

Pour tout élément intégré tiers qui consomme des données importantes, quels que soient les besoins de l'utilisateur.
Réessayez.
Pour tout élément intégré tiers dont les ressources requises pour le chargement ne sont pas seulement importantes, mais dont il est probable que tous les utilisateurs ne puissent pas interagir avec elles.
Bonne réponse !

À suivre: Préchargement et prérendu

Maintenant que vous savez comment charger des images et des éléments <iframe> de manière différée, vous êtes en mesure de vous assurer que les pages peuvent se charger plus rapidement tout en respectant les besoins de vos utilisateurs. Toutefois, dans certains cas, le chargement spéculatif de ressources peut être souhaitable. Dans le module suivant, vous découvrirez le préchargement et le prérendu, et comment ces techniques, lorsqu'elles sont utilisées avec précaution, peuvent considérablement accélérer la navigation vers les pages suivantes en les chargeant à l'avance.