A common performance mistake is loading everything a page might eventually show the instant it opens — every image, including the dozens below the fold that a visitor may never scroll to. This wastes bandwidth and delays the content people can actually see. Lazy loading is the simple idea of deferring off-screen resources until they are needed.
It is one of the easier meaningful wins in web performance.
The waste it removes
On a long page, most images sit far below the initial view, and many visitors leave before reaching them. Downloading all of them immediately competes for bandwidth with the content the user is looking at right now, slowing the first meaningful paint. You are paying to deliver things nobody has asked to see yet.
Images are usually the heaviest part of a page, so deferring the off-screen ones has an outsized effect.
How lazy loading works
Lazy loading holds back resources that are not yet visible and fetches them as the user approaches — typically as they scroll near. The result is a faster initial load, since the browser spends its early effort only on what is immediately needed, and reduced total data for anyone who does not scroll the whole way. Modern browsers support this for images with minimal effort.
The visible content arrives sooner; the rest streams in just in time, usually before the user notices any gap.
Using it thoughtfully
Lazy load what is off-screen, but not what is immediately visible — deferring the hero image the user sees first would slow the very thing you want fastest. Reserving space for images before they load also matters, so content does not jump around as they appear.
Applied with a little care, lazy loading trims wasted downloads and speeds up the experience for everyone, especially on long, image-heavy pages and slower connections.
The native `loading="lazy"` attribute versus a hand-rolled implementation
Modern browsers support a native `loading="lazy"` attribute directly on `<img>` tags, deferring that image's load until it is near the viewport without any JavaScript at all, which is simpler and more broadly compatible than the JavaScript-based approach lazy loading originally required — the trade-off is less fine-grained control over exactly how far in advance loading begins, or exactly what counts as 'near' the viewport, which is precisely the control a JavaScript-based Intersection Observer implementation still offers for cases where the native attribute's simpler, less tunable behavior is not quite sufficient.
Why the Intersection Observer API replaced scroll-event-based lazy loading entirely
Before Intersection Observer existed, detecting whether an image had scrolled into view required listening to the scroll event directly and manually calculating each image's position relative to the viewport on every single fired event — which, given how frequently scroll events fire, was itself a meaningful performance cost, precisely the kind of thing throttling and debouncing, discussed elsewhere in this library, exist to control. Intersection Observer moved this calculation into the browser's own optimized internals, notifying application code only when an element's visibility relative to the viewport actually crosses a defined threshold, which is both simpler to write correctly and considerably cheaper to run than the manual scroll-event approach it replaced.
Why the very first images should never be lazy loaded at all
Applying lazy loading uniformly to every image on a page, including ones already visible in the initial viewport, actively hurts performance rather than helping it — an above-the-fold image marked lazy is deferred from loading until the lazy-loading mechanism confirms it is visible, which, depending on implementation, can add a small but real delay compared to simply letting the browser start fetching it immediately the way it always has; lazy loading should be applied specifically and only to images below the fold, which is exactly the subset of a page it was designed to help.
Placeholder strategies: what fills the space before the real image arrives
An image that has not loaded yet still needs to reserve its final layout space to avoid contributing to the layout shift problem covered elsewhere in this library, and several distinct strategies exist for what fills that reserved space in the meantime — a plain solid color matching the image's dominant tone, a tiny, heavily blurred low-resolution version of the actual image (the 'blur-up' technique), or simply an empty, explicitly sized box — each trading a small amount of extra complexity or a tiny additional payload for a visually smoother transition once the real image actually finishes loading.
Lazy loading video and iframes, not just images
The same native `loading="lazy"` attribute and Intersection Observer techniques apply just as directly to `<iframe>` elements — an embedded video player or map widget below the fold is exactly as wasteful to load eagerly as an off-screen image would be, and often considerably heavier, since an embedded iframe frequently pulls in its own separate bundle of scripts and stylesheets the moment it loads regardless of whether the image inside it has rendered yet.
Why lazy loading interacts awkwardly with browser print and 'find in page' features
An image that has never scrolled into view, and is therefore never loaded, will not appear when a user prints the page or uses the browser's built-in find-in-page feature to search for text that happens to be near that image, which is a real, if easily overlooked, trade-off — some lazy-loading implementations specifically listen for the print event and eagerly load every remaining deferred image at that moment, closing this gap for the printing case specifically, though the find-in-page limitation is harder to fully eliminate since it depends on content, not just images, actually being present in the rendered page at the moment of the search.
Why responsive images and lazy loading solve two different, complementary problems
The `srcset` and `sizes` attributes let a browser choose an appropriately sized image variant for the current viewport and device pixel density, avoiding downloading a needlessly large image on a small screen, while lazy loading controls when an image downloads at all rather than which specific size it downloads — combining both is straightforward and common, since they address entirely independent dimensions of the same underlying image-loading cost, and applying only one while ignoring the other leaves real, easily captured savings on the table.
Why background images referenced only in CSS need their own lazy-loading approach
The native `loading="lazy"` attribute only applies to `<img>` and `<iframe>` elements, not to images referenced via CSS `background-image`, which means a design relying heavily on CSS background images for its off-screen content needs a JavaScript-based Intersection Observer approach instead — typically swapping a placeholder CSS class for one that sets the real background-image URL once the element scrolls into view, since there is currently no purely declarative, native equivalent covering this specific case.
Why a lazy-loaded image inside a carousel needs special handling
A carousel or slider that keeps several slides in the DOM simultaneously, only some of them visually shown at a time, complicates naive lazy loading, since a slide sitting just outside the visible viewport technically is not yet 'visible' by a simple Intersection Observer check even though a user could bring it into view within a fraction of a second by clicking a next-slide arrow — carousel implementations typically widen the loading threshold specifically for adjacent slides, loading the next slide slightly ahead of when it becomes strictly visible so it does not visibly pop in during the transition.
Why testing lazy loading requires simulating scroll behavior, not just checking initial load
A test suite that only verifies a page's initial, unscrolled state can pass completely while a broken lazy-loading implementation silently fails to ever load any off-screen image at all, since the bug only manifests once a user actually scrolls — automated visual or end-to-end tests for a lazy-loading feature need to explicitly simulate scrolling to the relevant point in the page and then assert the expected image has actually loaded, rather than only checking whatever is present in the very first rendered frame.
Why a lazy-loaded image's alt text still matters before it ever loads
A screen reader announces an image's alt text regardless of whether the image itself has actually finished loading, which means lazy loading does not excuse omitting or delaying meaningful alt text — accessibility depends on that text being present in the markup from the very first render, exactly as it would for an eagerly loaded image, since a user relying on assistive technology should never have a materially different experience of a page's content just because its images happen to load progressively rather than all at once.
Why a content management system's default image handling often needs explicit overriding
Many popular content management systems and page builders insert images without any lazy-loading attribute by default, leaving the responsibility entirely on whoever configures the site to add it explicitly, whether through a theme setting, a plugin, or manual template editing — auditing a CMS-driven site's actual rendered HTML for the presence of `loading="lazy"` on below-the-fold images is worth doing directly rather than assuming a modern platform handles this automatically simply because the underlying browser feature itself is now widely supported.
Why measuring the actual bandwidth savings validates the effort was worth it
Lazy loading's benefit is easy to assume but worth actually measuring directly — comparing total bytes transferred for a typical visit before and after adding lazy loading, using real field data rather than assuming the theoretical savings materialized exactly as expected, confirms the implementation is actually working as intended rather than silently loading everything eagerly anyway due to a misconfiguration nobody happened to notice.
Why a slow connection makes lazy loading's benefit disproportionately larger
The absolute time saved by deferring off-screen images scales with how slow the connection actually is, which means lazy loading's benefit is disproportionately larger for exactly the visitors on constrained mobile networks who need the improvement most — a fast broadband connection barely notices the difference lazy loading makes, while a slow mobile connection can see a first-paint improvement measured in seconds rather than milliseconds, which is worth keeping in mind when a lazy-loading change looks unremarkable when tested only on a fast development connection.
Why lazy loading is not a substitute for actually reducing total image weight
Deferring an image's load until it is needed does not make that image any smaller once it does load, and a page relying on lazy loading alone while still shipping oversized, uncompressed images below the fold has only delayed the cost rather than reduced it — lazy loading and image compression address genuinely separate problems, and treating either alone as a complete performance strategy leaves real, easily captured savings from the other one untouched.
Why the technique's name slightly undersells what it actually protects
"Lazy loading" sounds like a minor optimization for impatient developers, but its real effect is protecting the initial page load's limited bandwidth and processing budget for exactly the content a user is about to see, deferring everything else until it is actually needed — a more accurate, if less catchy, name might be something closer to prioritized loading, since that is the actual mechanism doing the work underneath the more familiar name.