In web performance, what does deferring the download of a page's offscreen images and iframes until the user scrolls near them actually save, and what does it not make faster?
answer
- a scheduling change, not a compression one
- the bytes still exist
- biggest win: pages nobody scrolls to the end of
- the deferred thing arrives later, not sooner
basics
~20 sDeferring offscreen images and iframes saves bytes, requests and connection capacity for content the user never scrolls to, leaving more bandwidth for what is on screen first. It does not make the deferred content itself arrive faster — it arrives later, on demand.
solid answer
~50 sDeferring offscreen media is a *reallocation*, not a compression trick. The bytes are the same size; you are choosing when they are spent. Two things improve: for users who never reach the bottom of the page, those requests never happen at all, so you save their data and their battery; and for every user, the resources competing with the initial view drop away, so the connection and the browser's request queue are freed for the things that paint first. What it does not do is speed up the deferred item — when the user scrolls there, the download starts then, so it can appear blank for a moment. It also does not reduce total bytes for a user who reads the whole page; it may even add a little overhead in extra round trips. The win is concentrated on long pages with a lot of media that most people never see.
go deeper
Be ready to say plainly that deferring moves a download later rather than shrinking it, and that the saving is real only for content the user never scrolls to.
Explain the second-order win: removing offscreen requests frees bandwidth and connections for the resources that paint the first screen, which helps even users who eventually read everything.
Show you can quantify it — estimate how far down a typical session actually scrolls before promising a saving, and note that deferring is scheduling, not a fix for oversized assets.
Frame it as a bandwidth-allocation policy: what fraction of requests are speculative, who pays for them on metered mobile connections, and what you accept in exchange in scroll-time latency.
## What "lazy" actually means here By default, when the browser parses your HTML it discovers every `<img>` and `<iframe>` in the document and queues a request for each one, whether the element sits in the first screenful or ten screens down. Lazy loading changes *when* that request is made: the browser (or your own code) holds the request back until the element is close to entering the viewport, and only then fetches it. Nothing about the file changes — same format, same bytes, same server. The only thing you moved is the moment of spending. That framing is the whole answer to the question, and it is what an interviewer is checking. Candidates often describe lazy loading as if it made a page "lighter". It does not make anything lighter; it makes the *start* of the page cheaper and defers the rest. ## What you genuinely save **Requests that never happen.** On a long article, a product listing, or an infinite feed, most visitors never reach the bottom. Every image below their stopping point is a download you avoided entirely: less mobile data, less battery, less origin and CDN traffic, and less decode work on the device. This is the single biggest and most reliable win, and it grows with how long the page is and how early people leave. **Contention relief for the initial view.** A browser only opens so many connections and only has so much bandwidth. If twenty offscreen images are queued alongside the stylesheet, the first-screen banner, and the fonts, they all compete. Removing them from the initial queue means the resources that actually paint the first screen get the pipe to themselves, so the first meaningful paint arrives sooner. This benefits *every* user, including the ones who eventually scroll all the way down. **Less early main-thread and memory work.** Every image that arrives has to be decoded and rasterised. Fewer concurrent decodes during load means fewer chances of a stutter while the page is still settling, and a smaller peak memory footprint on cheap devices. ## What it does not do **It does not make the deferred content appear faster.** By definition the request starts later, so when the user scrolls there, they may see an empty box while the file downloads. Whether they notice depends on how far ahead of the viewport the load is triggered and how fast their connection is. Deferring too aggressively converts a load-time cost into a visible scrolling cost, which users often perceive as worse. **It does not reduce total bytes for a reader who sees everything.** Someone who reads the whole page downloads exactly the same images, just spread over time, plus a little extra overhead from the additional round trips. **It does not fix a heavy page.** If your images are 2 MB PNGs, deferring them postpones the problem; it does not solve it. Correct formats, correct dimensions and compression do. Lazy loading is a scheduling decision layered on top of assets that should already be the right size. **It is not free of risk.** Content that is deferred is content that is not there yet. If you defer something that is visible immediately, you have simply added a delay in front of the user's first impression, which is the classic way teams make a page slower while believing they optimised it. ```html <!-- deferred: far below the fold, most readers never reach it --> <img src="/gallery/photo-31.jpg" loading="lazy" width="800" height="600" alt="Gallery photo"> ``` ## Where the payoff is biggest Rank candidates by two questions: how likely is the user to see this, and how expensive is it? A comment thread's avatars, a gallery's tail, a footer map, an embedded player far down the page — high cost, low probability of being seen — are the best returns. A small icon two hundred pixels below the fold is a rounding error and is not worth the machinery. ## How to say it in an interview "It shifts the cost rather than removing it. Users who do not scroll never pay it at all, and every user gets less competition for bandwidth during the initial load. The deferred item itself is not faster — it starts downloading later, so if you defer the wrong thing, or trigger the load too late, you have moved the delay onto the user instead of removing it." That answer shows you understand both directions of the tradeoff, which is what separates a memorised definition from a working mental model.
- If a user does read the entire page, has lazy loading helped them at all?Yes, but less. They download the same total bytes, plus a little round-trip overhead. What they still gain is that the initial view had the network to itself, so the first screen painted sooner. The tail of the page then loads progressively as they read, which is usually invisible if the trigger distance is generous.
- Does deferring images below the fold reduce a page's JavaScript execution cost?No. Deferring media affects network requests, image decoding and memory, not script parsing or execution. If the main thread is busy, that is a script problem, addressed by shipping less JavaScript or splitting it — deferring images will not move it, though it does remove some decode work that was competing for the same thread during load.
- Someone says lazy loading 'reduced our page weight by 60%'. What would you ask them?Which page weight — the bytes transferred during initial load, or the total for a user who scrolls the whole page? The first genuinely drops; the second does not change. It is worth confirming that the measurement was not simply a tool loading the page without scrolling, which makes any deferral look like a large reduction by construction.
saying these in an interview costs you the question
- Says lazy loading makes images smaller or compresses them
- Claims deferred images load faster than eager ones
- Applies it to every image including the first screen
- Thinks it reduces JavaScript parse and execute cost
- Treats it as a substitute for correct image sizing and format