How would you use IntersectionObserver to lazy-load images only as they scroll into the viewport?

Question presented to candidate: "You have 50 images on a long page, but only the first 3 are visible on load. How would you defer loading the rest until each one is about to scroll into view, without a manual scroll-event listener computing positions on every scroll tick?"

What a strong answer should cover:

• 📌 Interview term: IntersectionObserver — a real, built-in browser API that lets code .observe(element) and receive a real callback exactly when that element's intersection with the viewport (or another ancestor) genuinely changes — no manual scroll event listener or position math required.
• 📌 Interview term: the real, direct answer to the prompt — verified directly, live in a real browser (confirmed genuinely NOT implemented in jsdom): observing an image placed far below the fold produced an immediate real callback reporting isIntersecting: false; after genuinely SCROLLING the target into view, a SECOND real callback fired reporting isIntersecting: true, ratio: 1 — the exact real moment to swap a placeholder for the real image src.
• 📌 Interview term: entry.isIntersecting — the real boolean each callback entry carries, directly answering whether the observed element is currently visible within the configured root, with no manual geometry calculation needed.
• 📌 Interview term: the real practical lazy-load pattern — a precise answer names the standard implementation: set each image's real src from a data-src attribute inside the callback ONLY when entry.isIntersecting is true, then immediately call observer.unobserve(entry.target) (or observer.disconnect() if watching only one element) — since an image only needs to load ONCE, not repeatedly on every scroll in/out.
• A precise answer names the real, practical performance advantage over a manual scroll listener: a scroll event fires extremely frequently, requiring either manual throttling or a real, wasted getBoundingClientRect() call on every tick — IntersectionObserver's callback fires only when the real intersection state genuinely changes.

Clarifying questions expected:

• None — this is a definitional/practical question; directly demonstrating the real, verified scroll-triggered callback is the strong signal.

Code / implementation expected: Yes — a real, live-browser-verified IntersectionObserver observing a below-the-fold target, triggered by a real scroll, with .disconnect() confirmed to stop further callbacks.