Chrome widens lazy loading to media

Google has expanded Chrome’s native lazy-loading system to cover audio and video elements, extending a browser feature once centred on images and iframes into richer media formats that often consume far more data and trigger earlier connections to outside servers. The change allows developers to use the loading=”lazy” attribute on ` and so that files outside the visible viewport can be deferred until a user is closer to them on the page. Chrome Platform Status lists the feature as stable, while MDN now documents the corresponding HTMLMediaElement. loading property as an experimental, limited-availability feature.

For publishers, streaming platforms and site operators, the practical effect is straightforward: pages carrying multiple embedded clips, podcasts or promotional reels no longer need to start pulling those assets immediately on page load if they sit farther down the screen. MDN’s documentation for says lazy-loaded media will only begin applying preload behaviour once the element is near or within the viewport, and that poster images for video are also deferred. Its documentation for says bandwidth and storage use can be avoided until playback is more likely, improving performance in typical use cases.

That matters because media files are often among the heaviest objects on a web page. Even when developers use preload=”metadata” rather than full preloading, browsers may still establish connections, fetch headers or download poster images long before a reader decides to press play. By letting Chrome postpone those steps, Google is giving developers a native option to reduce initial page weight without relying on JavaScript workarounds or custom lazy-load libraries. MDN’s broader performance guidance continues to frame lazy loading as a standard way to defer non-critical resources and improve page speed.

Security and privacy specialists are also likely to note the narrower, but still meaningful, side effect of delaying contact with third-party hosts. Many media embeds call resources from content delivery networks, analytics systems or outside platforms the moment a page opens. Deferring off-screen audio and video can therefore postpone those requests until the user scrolls near the content. Chrome and MDN material stop short of presenting this as a broad security fix, but the documentation does make clear that deferred loading alters when external requests are made, and that JavaScript must be enabled for the feature to work because browsers treat lazy loading as a potential anti-tracking issue.

There are limits. The new attribute is a hint, not a command. MDN notes that browser behaviour is not absolutely mandated by specification, and autoplay still takes precedence over preload settings. For video, a lazy-loaded element set to autoplay will still need data when playback is required. For audio, the feature is more constrained: MDN says lazy loading depends on visible controls, meaning an off-screen audio element without the controls attribute will not load lazily at all. Developers trying to treat the change as a universal optimisation will need to test carefully across use cases.

Another caveat is cross-browser support. MDN labels the HTMLMediaElement. loading` property as not yet part of its Baseline set because it does not work in some widely used browsers. That means developers building for a mixed browser environment may still need fallbacks or selective deployment strategies, especially on sites where media delivery is central to revenue or audience retention. Chrome may have moved the feature into stable territory, but the wider web platform has not fully caught up.

The move fits a broader Chrome pattern. Google has spent years turning performance techniques that once required scripts or specialist tooling into native browser attributes. Images and iframes received lazy-loading support earlier; media files are the next logical target because they combine high transfer costs with uneven user engagement. Pages with multiple clips, tutorial libraries, long-form articles with supporting video, education portals and audio-heavy product pages stand to benefit most, particularly on slower connections and mobile hardware where every deferred request can improve perceived speed. MDN’s guidance on multimedia optimisation reinforces that oversized media remains a persistent drag on load quality, and Chrome’s new implementation gives developers a simpler way to address that at the markup level.