Intersection Observer Lazy Loading
Intersection observer lazy loading defers the load or render of an element until it approaches the viewport, so off-screen images and widgets do not cost bandwidth or render time until needed.
Definition
Intersection observer lazy loading uses the Intersection Observer API to watch an element and trigger a callback — to set src, to render a component — only when the element enters the viewport (or a root margin before it), so that off-screen content is not fetched or rendered until the user approaches it.
Context and scope
Applied in image lists, embedded widgets, and any content below the fold that should not be loaded until the user scrolls near it.
Common misconceptions
- Intersection observer replaces scroll listeners — it replaces scroll listeners with a browser primitive that does not jank; the scroll listener is the thing to remove
- rootMargin is just padding — it is the pre-load distance; setting it preloads before the element is visible, which is the point for smooth scrolling
Anti-patterns
- Lazy-loading the LCP image, so the largest contentful paint waits for the scroll that never comes
- Setting the root margin so large that every element loads immediately, defeating the lazy intent
Related concepts
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
What it is
Intersection observer lazy loading uses the Intersection Observer API to watch an element and trigger a callback — to set src, to render a component — only when the element enters the viewport (or a root margin before it), so that off-screen content is not fetched or rendered until the user approaches it. Applied in image lists, embedded widgets, and any content below the fold that should not be loaded until the user scrolls near it. The browser is a hostile, shared, single-threaded (for JS) environment where every millisecond of main-thread work is a millisecond the user cannot interact.
How it works
The rendering pipeline — style, layout, paint, composite — is incremental and can be invalidated by any DOM change. Performance work targets avoiding the expensive phases (layout, paint) and scheduling the rest in idle callbacks or off the main thread. Loading work orders resources by their impact on the critical path: render-blocking scripts are deferred, images get fetch priority, and the server pushes what the client will need next.
When to apply and pitfalls
Apply when user interaction latency or load performance has a measured business impact. The pitfall is micro-optimizing a function while the page ships a megabyte of render-blocking JavaScript — the dominant cost is structural, not algorithmic. Another is measuring in the ideal lab profile and missing the long-tail devices and networks where most users actually live.