Intersection Observer : Lazy Loading et Scroll Infini

Un listener scroll sur window peut se déclencher des centaines de fois pendant un seul swipe. Si vous exécutez getBoundingClientRect() sur chaque carte d’un feed à chacun de ces événements, cinquante images suffisent à faire ralentir la page. L’Intersection Observer API retire cette vérification du scroll : vous enregistrez les éléments à observer, et le navigateur vous prévient quand leur visibilité change réellement.

Comment fonctionne IntersectionObserver

Un observer surveille un ou plusieurs éléments target par rapport à un root (le viewport, par défaut) et appelle une callback chaque fois qu’un target franchit un seuil de visibilité.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const observer = new IntersectionObserver((entries) => {
  for (const entry of entries) {
    console.log(entry.target, entry.isIntersecting, entry.intersectionRatio);
  }
}, {
  root: null,         // null = le viewport du navigateur
  rootMargin: "0px",  // agrandit ou réduit la boîte du root avant le test
  threshold: 0,       // se déclenche dès qu'1px est visible
});

document.querySelectorAll(".card").forEach((el) => observer.observe(el));

Chaque entry contient isIntersecting (un booléen), intersectionRatio (la part du target à l’intérieur du root, de 0 à 1) et le boundingClientRect du target lui-même. La callback est asynchrone. Le navigateur calcule les intersections une fois par frame, dans le cadre de son propre travail de rendu, donc votre code ne force jamais un recalcul de layout pendant que l’utilisateur fait défiler la page.

threshold accepte aussi un tableau. [0, 0.5, 1] déclenche la callback séparément à 0 %, 50 % et 100 % de visibilité : c’est ainsi que vous envoyez un événement « marqué comme lu à mi-scroll » sans créer trois observers.

Comment faire du lazy loading d’images avec IntersectionObserver

Le cas d’usage classique : ne pas télécharger une image avant qu’elle ne soit sur le point d’entrer dans le viewport.

1

<img class="lazy" data-src="/media/hero-photo.jpg" alt="Crête de montagne au coucher du soleil" width="1200" height="800">

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const imgObserver = new IntersectionObserver((entries, obs) => {
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;
    const img = entry.target;
    img.src = img.dataset.src;
    img.classList.remove("lazy");
    obs.unobserve(img); // terminé pour celle-ci
  }
}, { rootMargin: "200px 0px" }); // commence à charger 200px avant la visibilité

document.querySelectorAll("img.lazy").forEach((img) => imgObserver.observe(img));

rootMargin est ce qui rend tout cela instantané. Une valeur positive agrandit la boîte effective du root, donc la callback se déclenche pendant que l’image est encore 200px sous le pli, au lieu d’attendre son premier pixel visible. Gardez aussi width et height explicites sur la balise : ils réservent l’espace pour que le layout ne saute pas à l’arrivée de l’image réelle, une cause distincte de layout shift que la plupart des démos de lazy loading ignorent.

Avant d’écrire tout cela, vérifiez si <img loading="lazy"> suffit. Tous les navigateurs actuels le supportent nativement, sans JavaScript. La version avec observer se justifie quand vous avez besoin de ce que l’attribut ne peut pas faire : un swap de placeholder personnalisé, de la vidéo ou des iframes en lazy, ou des images d’arrière-plan posées en CSS.

Comment construire un scroll infini avec un élément sentinelle

Le scroll infini ne surveille pas le contenu déjà chargé. Il surveille un élément vide sous la liste et charge la suite quand cette sentinelle devient visible.

1
2

<ul id="results"></ul>
<div id="sentinel"></div>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const sentinel = document.querySelector("#sentinel");
let page = 1;

const scrollObserver = new IntersectionObserver(async (entries) => {
  if (!entries[0].isIntersecting) return;
  scrollObserver.unobserve(sentinel); // pause pendant le chargement de cette page
  await loadNextPage(page++);
  scrollObserver.observe(sentinel);   // reprend la surveillance pour la suite
}, { rootMargin: "400px" });

scrollObserver.observe(sentinel);

La paire unobserve/observe est là pour les réseaux lents. Sans elle, un utilisateur qui fait défiler assez vite peut redéclencher la callback avant que la première requête ne soit résolue, et deux pages de résultats arrivent dans le désordre.

loadNextPage est un appel fetch ordinaire, qui a donc besoin du même contrôle response.ok que n’importe quelle autre requête. Le guide sur la gestion des erreurs de la Fetch API couvre ce qu’il faut faire quand cette requête renvoie une 404 ou que le réseau coupe en plein scroll. En cas d’échec, laissez la sentinelle non observée et affichez un bouton de nouvelle tentative. La réobserver tout de suite vous enferme dans une boucle de requêtes qui échouent.

L’ancienne façon de faire était un handler scroll avec throttle ou debounce appelant getBoundingClientRect() sur la sentinelle. Comme le montre la comparaison entre debounce et throttle, les deux techniques continuent de faire du polling, juste moins souvent. Un observer ne fait aucun polling. Le navigateur se charge de la vérification, et votre code réagit au résultat.

Quand se déclenche la callback d’IntersectionObserver

Pas sur la microtask queue. Si vous avez lu comment async/await interagit avec l’event loop, ne supposez pas que la callback se comporte comme la continuation d’une promise. Le navigateur la planifie depuis son pipeline de rendu, autour du paint. C’est pour cela qu’elle est assez légère pour une page qui défile, et aussi pour cela qu’elle n’est pas l’outil adapté à une logique qui doit s’exécuter avant le prochain repaint.

Pièges courants d’IntersectionObserver

Il teste une bounding box, pas des pixels. Un élément signalé comme intersectant à 100 % peut rester complètement caché derrière une modale opaque ou un header sticky peint par-dessus. L’API répond à « cette boîte est dans cette autre boîte », pas à « l’utilisateur peut voir ceci ».

Un observer par élément, ça s’accumule. Appeler new IntersectionObserver() pour chacune de deux cents cartes crée deux cents observers distincts. Créez-en un par comportement (un pour toutes les images lazy, un pour la sentinelle) et appelez .observe() sur chaque target qui en a besoin. La callback reçoit déjà les entries des targets qui ont changé.

jsdom ne l’implémente pas. Dans une suite Jest ou Vitest qui tourne sur jsdom, IntersectionObserver est undefined sauf si vous le mockez ou installez un polyfill. Mockez le constructeur et appelez vous-même la callback avec de fausses entries pour tester la logique de lazy loading isolément. N’essayez pas de simuler un vrai scroll dans un test unitaire.

Observer avant que l’élément existe. Dans un framework qui fait un rendu asynchrone, appeler observer.observe(el) sur une ref encore null échoue silencieusement : aucune erreur, aucun warning, l’élément n’est jamais observé. Observez à l’intérieur du hook qui s’exécute après le montage du nœud DOM (useEffect en React, mounted en Vue).

Quand utiliser IntersectionObserver plutôt que loading=“lazy”

Pour les balises <img> simples, ajoutez loading="lazy" et n’écrivez pas de JavaScript. Utilisez IntersectionObserver pour ce qu’un attribut ne peut pas exprimer : déclencheurs de pagination, autoplay vidéo à l’apparition, événements « vu » pour l’analytics, swaps placeholder vers image. Un bon premier réflexe : repérer dans votre code le listener scroll qui appelle getBoundingClientRect() et le remplacer par un unique observer partagé.

Articles associés

• Gestion des Erreurs avec la Fetch API en JavaScript
• Debounce vs Throttle en JavaScript : Quand Utiliser Chacun
• Async/Await et l’Event Loop de JavaScript Expliqués