Lazy Loading

Back when everything a page needed arrived up front, the heavier the page, the later the first screen appeared. On a list of 60 products, all 60 images had to land before the top three showed up.

The question is how many of those 60 a person actually looks at. Few people scroll a list to the end; most read three or four items at the top and then click one or leave. The 50-odd images below the fold are downloaded and discarded, and the price of that is paid by the three at the top arriving late.

On a slow connection the gap turns directly into abandonment. A screen that renders in one second on office wifi takes six on a subway train, and not many people wait out those six seconds. The nastiest part is that the problem is invisible from a developer's desk, where the images are already cached and the network is fast, so the page under test never behaves like the page a customer meets.

Lazy loading is the answer that moves the fetch later to strip that cost out. Whatever is visible now goes first, and the rest arrives when it's needed. It changes the order rather than the total, which is what separates it from image optimization, the work of shrinking file size while keeping quality.

Choose what to defer, attach the mechanism, decide what the deferred slot shows in the meantime, and then measure whether anything actually got faster.

1. Separate what's on the first screen from what isn't. The line is the fold — the area visible before any scrolling. Nothing inside it ever gets deferred.
2. Attach the mechanism. For images, one extra attribute on the tag hands the job to the browser. For code, the pieces a bundler — the tool that packs many files into deployable groups — has already separated get requested at the moment they're needed.
3. Reserve the space first. Without width and height declared on the slot the image will occupy, everything below shifts down when the image finally lands. That's how a sentence someone is reading suddenly jumps off the screen.
4. Decide what shows before arrival. A gray rectangle, or a tiny blurred version of the image. Leave it blank and people read it as broken.
5. Measure. Compare first-screen time and how much the layout moved, before and after, on a setting that simulates a slow connection. If the numbers don't move, what you deferred wasn't heavy to begin with, so revert it.

On the code side, run tree shaking — which strips unused code out of the output entirely — before deferring what's left. Reverse the order and you spend real effort arranging for unnecessary code to arrive later.

The good fits are clear enough: long scrolling lists, articles with many images below the text, and code for screens only some people open. There's no reason for every user to download the admin screen on first load.

Apply it to the first screen and it only costs you. Lazy-load the large banner at the top and the browser demotes it in priority, so the thing that most needs to appear fast appears last. It's a common reason performance scores drop after someone "optimizes" a page.

The other limit is that waiting time moves rather than disappears. Scroll a list quickly and a gray rectangle flashes at each position the scroll reaches. Which is why list screens start fetching a few hundred pixels before an item enters the viewport — enough margin that the image usually lands before the slot is on screen, without pulling back so much that the whole list arrives anyway.

Content that search engines need to read calls for caution too. Make article text or product details arrive only on scroll and crawlers may never see them. What gets deferred belongs to the resources that fill a screen; the content itself is safer sitting in the document from the start.

It's also worth checking the size of the prize. If off-screen resources are a small share of the total, deferring them changes nothing anyone can feel. Holding back 34 of 40 cards to save two megabytes is visible; deferring 50 kilobytes on a 300-kilobyte page just adds complexity. Look at what weighs what before attaching anything.

"Can we lazy-load the list images? First paint is taking over three seconds."

Too much is arriving at once, so send only what's visible first.

"Don't put it on the hero image. That makes it slower."

Resources visible on the first screen must never be deferred.

"The layout jumps since we added lazy loading — I think the dimensions are missing."

A diagnosis: the deferred slot wasn't reserved in advance.

Pagedeck's document list puts 40 cards on one screen, and once each card carried a preview image the first screen slowed noticeably. Theo changed it to fetch the six visible cards first and pull the rest in as the user scrolls, and first-screen time dropped by more than half.

Right after the change, though, Noa caught cards shuffling downward unevenly. Card height wasn't fixed, so every arriving image pushed the cards below it down. Declaring the slot size fixed it, and since then the two changes get made together whenever a new list screen is built. Mia added the layout-shift number to the dashboard the team checks after each release, since the symptom is easy to miss in review and obvious to anyone using the product.

Many people assume lazy loading makes a page lighter. The first screen gets faster, so it feels that way. But the total stays exactly the same, and a user who scrolls to the end downloads all of it anyway — only the order changed. Miss that and a size problem stays papered over while the work of actually shrinking images keeps getting postponed, which helps nobody who regularly scrolls a list to the bottom.

Assuming it's safe to apply everywhere is the other one. There seems to be no downside to attaching it, so the judgment comes naturally. In practice the images on the first screen get deferred along with everything else, the most important resource arrives late, and gray rectangles blink across the page. Choosing where to apply it is half of the technique.