R3.07.4viewport-aware media loadingdesign

Off-viewport media is deferred; in-viewport media is prioritized

Aliases: lazy loading · viewport priority · hero bandwidth · deferred decode

What it is

Bandwidth and decode slots are finite. Media the viewport is looking at should occupy them first; media outside should wait. Viewport-aware loading uses loading="lazy", Intersection Observer, or priority hints to schedule fetch and decode against visibility. It is scheduling, not file size and not whether to play. A hero marked lazy while a footer image requests immediately is priority inversion.

Why it happens

A document has a cap on connections, bandwidth, and the image-decode queue. If every <img> is eager, first-screen and below-the-fold images share one pipe, and the first screen’s first byte slips. Lazy loading holds the request until the element approaches a root margin; fetchpriority="high" or preload inserts the in-viewport LCP candidate at the front. The right schedule is: media in the current viewport plus a short overscroll margin first, the rest later. Too small a margin shows empty boxes while scrolling; too large a margin fetches distant images early and undoes laziness.

Decode needs the same queue. Bytes can already be on disk while the decoder still only finishes so many frames at once. Off-viewport images that decode first delay the in-viewport one. “Defer” therefore means defer request and decode, not merely writing src late.

Where it stops holding

Print, share cards, and crawler screenshots often have no “current viewport”; lazy loading omits images on those channels and they need forced eager. Mail HTML is inconsistent about lazy. Infinite lists with a tiny margin go blank during fast flicks. Prerender or back-forward cache restore may open mid-document; prioritize the restored viewport, not the page head. A video poster may be lazy; a poster already in view that will be LCP must not.

Applying it

  • Make the first-screen hero and main poster eager with raised priority; default below-the-fold to lazy, with a one-to-two-screen overscroll margin rather than the whole page.
  • Inspect framework defaults: some mark every image lazy, including the LCP candidate—override that slot.
  • Point priority hints or preload at the single in-viewport LCP image, not at a row of thumbnails.
  • Verify on a cold-load waterfall: first-screen requests precede below-the-fold. Fast-scroll to mid-page and the target should start before it enters view, without making first-screen LCP worse.

Related

  • Same group: R3.07.1 Size and format must be generated per use case · R3.07.2 Undeclared dimensions cause layout jump · R3.07.3 Autoplay consumes bandwidth and attention · R3.07.5 Placeholder color close to the final image reduces pop · R3.07.6 Media fallback chains must cover decode failure and unsupported formats
  • Adjacent: I2.07 Perceived performance · R3.15 First-paint metrics and interaction readiness
  • Search terms: lazy loading · fetchpriority · LCP image

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R3.07.4