For deferring offscreen images and iframes, when is the browser's built-in lazy loading enough, and what does driving the loading yourself with IntersectionObserver buy you?

## Two ways to defer There are two mechanisms for holding back offscreen work, and the interview question is when each is the right tool. The first is the browser's own: mark an `<img>` or `<iframe>` as lazy and the browser takes over. It decides how close to the viewport the element must be, starts the fetch itself, and does all of it in the engine, before or without any of your JavaScript. The second is doing it yourself. You hold the real source somewhere the browser will not fetch — typically a `data-` attribute — observe the element with an `IntersectionObserver`, and when the callback says it is approaching the viewport, you assign the real source. ```javascript const io = new IntersectionObserver((entries, observer) => { for (const entry of entries) { if (!entry.isIntersecting) continue; entry.target.src = entry.target.dataset.src; observer.unobserve(entry.target); } }, { rootMargin: '600px 0px' }); ``` ## What the built-in path gives you **Zero cost and zero code.** No bytes shipped, no main-thread work, nothing to maintain or test. **It works when your JavaScript does not.** If the script fails, is blocked, or has simply not arrived yet, browser-native deferral still functions. Custom deferral in the same situation leaves you with elements whose real source lives in a `data-` attribute and never gets applied — a blank page section. That failure mode alone justifies preferring the native path for content. **Tuned trigger distances.** Browsers start these loads well before the element reaches the viewport, and adjust the distance based on the connection, so a slow connection gets a longer runway. You get that behaviour for free and it improves as browsers improve. **Correct interaction with the rest of loading.** The engine knows the element's position and the state of the page. Your script only knows what the observer told it, after layout, after your bundle arrived. ## What it cannot do The attribute applies to specific elements. That leaves real gaps: - A CSS `background-image` on an offscreen section — the attribute has nowhere to live. Deferring it means toggling a class when the section approaches. - `<video>` — the lever there is `preload="none"` plus a `poster` image, which is a different mechanism with different behaviour. - Anything that is not a resource at all: a component's data fetch, an analytics beacon, initialising a heavy widget, rendering a long section's contents. - The trigger distance itself. You accept the browser's choice; you cannot say "start loading 1200 pixels early because our scroll is unusually fast". - Presentation while loading. A shimmer placeholder, a blur-up preview, a fade-in on arrival, a retry after a failed fetch — all of this needs a callback you control. - Knowing what happened. If you want to record which items were actually seen, you need the observer regardless. ## What the observer costs It is JavaScript: bytes to download, parse and run, on the same main thread as everything else. It cannot act until your bundle has arrived, so the deferral itself is deferred — on a slow connection, images can begin loading noticeably later than the native path would have started them. It has to be cleaned up: stop observing an element once it has loaded, or the callback keeps firing for the life of the page. And the pattern of putting the real URL in `data-src` means anything that does not run your script — some crawlers, a JavaScript error, a stale cached bundle — sees no image at all. ## How to choose Use the built-in mechanism for content media. Reach for the observer when you need something it structurally cannot provide: a different trigger distance, a placeholder lifecycle, deferral of non-media work, or instrumentation. The two also combine — the observer is the right tool for deferring a section's *data* while the images inside that section still use the browser's own deferral once they exist. The answer an interviewer is listening for is the framing, not a list: native is the default because it is free and fails safe; custom is a deliberate purchase of control, paid for in code, main-thread time and a worse failure mode. If a candidate reaches for the observer first for ordinary images, they have paid that price without noticing there was one.