I2.05.1lazy load cuts first-screen costdesign

Lazy loading cuts the cost of the first screen

Aliases: defer below-fold · first-paint diet · on-demand fetch

What it is

Lazy loading leaves resources that are not yet in demand — images outside the viewport, unopened disclosures, inactive tabs — until they are about to be seen or used. What it cuts is first-screen cost: bandwidth, decode and main-thread work that the first glance has to fight for, no longer diluted by three screens of images and scripts below. Prefetch pulls the next hop earlier; lazy loading pushes things that need not appear now later. Opposite directions, both moving where the wait lands.

Why it happens

The first screen’s wait is set by bytes and compute on the critical path. Every unseen large image, every payload inside a still-closed panel, races the title and main column for the same pipe and the same layout turn. People have not scrolled to them; they have already slowed the first glance. Lazy loading lifts those objects off the critical path. The first screen shortens; objects below re-enter the path as demand approaches. Total work may not fall — extra requests later can even raise it. What falls is the stretch that competes with “starting to use”.

It depends on a boundary: what counts as needed now. Commonly the viewport plus a little warmup distance, or the user opening a panel. Drawn right, the first screen thins and what follows still arrives in time. Drawn wrong, the failure is not this leaf’s gain — it is the next two leaves’ blank holes and search blind spots.

Where it stops holding

When the first screen is itself long (a marketing page that stretches “first glance” across two viewports), lazy loading only helps what is outside; media still crowding inside should be ordered by importance, not lazily deferred. A short page with everything in the first screen has nothing to push later; adding lazy loading only adds an observer and a request. Resources the first screen needs in order to lay out correctly (a font that sets height, a hero background) if lazy-loaded make the first screen wrong and then correct it — cost not cut, a jump added. Preloading a critical font for this page is not lazy loading; do not push the critical path later in the name of loading less.

Applying it

  • Take off-viewport media, hidden panels and inactive tabs out of first-screen requests. Keep what orientation and the main task need.
  • Decide lazy-or-not by “does it participate in the first glance”, not by “is it an image”. The hero is not lazy; off-screen thumbs are.
  • Measure first-glance bytes and decode with lazy loading on and off. Success is a cheaper first screen, not the same bill moved to an unobserved interval.
  • How to check: open the page on a throttled network and, when the first screen is done, see whether large resources that are not near the viewport have already finished downloading. If they have, first-screen cost is still being diluted by non-first-screen work.

Related

  • Same group: I2.05.2 A trigger that fires too late leaves a visible hole · I2.05.3 Lazy-loaded content must be findable by in-page search
  • Nearby: I2.04 Prefetch and preload · I2.03 Chunked loading · I2.07 Perceived performance
  • Search terms: lazy loading · first-screen cost · below-the-fold defer

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I2.05.1