Some teams apply lazy loading to every image, iframe and offscreen section on a page by default. What does that blanket policy cost, and how do you decide what is genuinely safe to defer?

## Why "lazy-load everything" is a real failure mode Deferral has an inherent asymmetry. When you defer something the user never sees, you save its full cost. When you defer something the user *does* see immediately, you do not save anything — you add latency, because the request now starts after layout has determined the element's position instead of when the parser first saw it. The upside is bounded by the file's size; the downside is a visible delay on the content that forms the user's first impression. The blanket policy is attractive because it is easy to enforce and it makes the initial request count in a network waterfall look excellent. That metric is exactly the one that improves for the wrong reason: fewer initial requests with a slower first paint is a worse page, not a better one. ## The line: probability of being seen The useful question is not "is this below the fold?" but "how likely is this user to need this, and how soon?" That gives three bands. **Band 1 — renders in the first viewport.** Always eager. This is the strongest rule in the whole topic. A resource that is deferred is, by construction, discovered late: the browser must build layout, decide the element is near the viewport, and only then start the fetch. For something already on screen you have inserted an avoidable serial step into the path to first paint. Anything in the initial screenful — the header art, the first row of a listing, the opening media of an article — loads normally. **Band 2 — the grey band just past the fold.** Judgment. The fold is not a fixed line: it varies with device, orientation, font size and zoom. A short mobile viewport means content "below the fold" on the design mock is on screen for many real users, and a single flick scroll moves several screens in a few hundred milliseconds. The safe default is to keep roughly the first screen *past* the fold eager too, and let deferral start after that. **Band 3 — deep offscreen content.** Defer freely. Gallery tails, comment threads, footers, embedded maps and players, long lists. This is where the entire benefit lives, and it is worth being systematic about it. ## Choosing the trigger distance Deferral only feels invisible if the load begins early enough to finish before the element reaches the eye. That means the trigger distance is a real design parameter, not an implementation detail: too small and users see empty boxes while scrolling; too large and you have effectively re-enabled eager loading. Scroll velocity is the driver — flick-scrolling on a phone covers far more distance per second than a mouse wheel, so mobile generally deserves a *larger* buffer, not a smaller one. Browsers using their built-in deferral already pick a distance for you, and it is deliberately generous for this reason. ## The second failure mode: deferral at scale Deferring one image is a saving. Deferring a hundred sections that each trigger their own data fetch turns a fast scroll into a burst of concurrent requests, all competing with each other and with whatever the user is actually looking at. The symptoms are stalled requests, a busy main thread, and content that appears in the wrong order. Fixes are throttling, batching, or coarser deferral units — defer a whole section instead of each item inside it — and stopping observation once an item has loaded so the work does not repeat. ## What it does not apply to A blanket "lazy" attribute policy is often applied by a template helper or a lint rule with no knowledge of position. If you enforce it mechanically, enforce the exception mechanically too: the components that render above the fold need an explicit eager escape hatch, and someone needs to own it. A rule that cannot express "this one is first-screen" will eventually be applied to the first screen. ## The workable default Eager for the first viewport and roughly one screen beyond it; deferred after that, with a trigger distance sized for flick scrolling; deferral units coarse enough that a fast scroll does not detonate a hundred parallel requests; and a review habit of checking the real page on a small viewport rather than trusting the design mock's fold. Then verify: load the page, look at what was requested before first paint, and confirm nothing on the opening screen is waiting on a deferred fetch.