Google is preparing to bring lazy loading to audio and video elements in Chrome — a deceptively simple change that could meaningfully reduce bandwidth consumption across the web. The feature, already applied to images since 2019, would let browsers defer the downloading of media files until users actually scroll near them. For a browser commanding roughly 65% of the global market, the implications ripple far beyond a single code commit.
The change was first spotted by Android Authority, which flagged a new Chromium code commit indicating Google’s intent to support native lazy loading for and HTML elements. Right now, when a webpage includes a video — even one buried far below the fold — Chrome begins fetching that media as soon as the page loads. Every autoplay carousel, every embedded tutorial, every ambient background clip. All of it starts downloading whether you see it or not.
That’s a lot of wasted data.
Lazy loading for images became part of the HTML specification years ago, and Chrome adopted it with enthusiasm. The loading="lazy" attribute on or elements. The omission has been a persistent frustration for web developers who build media-heavy pages.
Google appears ready to close that gap unilaterally, at least within Chrome. The Chromium commit suggests the browser will support the loading="lazy" attribute on video and audio tags, giving developers explicit control over when those resources begin downloading. The behavior would mirror what already exists for images: media outside the viewport stays dormant until the user scrolls close enough to trigger a fetch.
The technical details matter here. Video files are dramatically larger than images. A single embedded 1080p video can easily exceed 50 megabytes. Multiply that across a news article with three embedded clips, a product page with demo videos, or a social feed with dozens of autoplay previews, and the bandwidth overhead becomes staggering. On mobile connections — particularly in markets where data caps are tight and cellular speeds inconsistent — this overhead translates directly into slower page loads, higher costs for users, and worse Core Web Vitals scores for publishers.
Core Web Vitals, Google’s own set of metrics for measuring user experience on the web, have become a ranking signal in search results. Largest Contentful Paint, one of the three core metrics, measures how quickly the main content of a page becomes visible. When a browser is busy fetching off-screen video files, it competes for bandwidth and processing power that could be used to render the content users actually came to see. Lazy loading video elements would directly improve LCP scores for pages that currently load all media eagerly.
And this isn’t just theoretical. Web performance consultants have been recommending JavaScript-based lazy loading for videos for years. Libraries like lazysizes and custom Intersection Observer implementations have filled the void left by the spec’s silence on video lazy loading. But native browser support is categorically different from a JavaScript shim. It’s faster, more reliable, and requires zero additional code weight. Developers add an attribute. The browser handles the rest.
The commit doesn’t specify a target Chrome version for the feature’s rollout, and as with all Chromium changes, there’s no guarantee it ships exactly as currently proposed. Google frequently experiments with features behind flags before enabling them by default. But the direction is clear, and the engineering rationale is strong enough that significant pushback seems unlikely.
One open question is how other browser vendors will respond. Firefox and Safari have their own approaches to resource loading optimization, and neither currently supports loading="lazy" on video or audio elements. The Web Hypertext Application Technology Working Group (WHATWG), which maintains the HTML Living Standard, would need to formally extend the specification for this to become a cross-browser standard. Google has a history of shipping features in Chrome first and pushing for standardization later — sometimes successfully, sometimes not. Given the clear user benefit, this seems like a case where other vendors would eventually follow.
Safari’s behavior is particularly interesting to watch. Apple has historically been aggressive about limiting unnecessary data usage on its platforms, especially on iOS where battery life and cellular data are persistent concerns. WebKit, Safari’s engine, already implements some forms of media loading deferral, but not through the same declarative HTML attribute. A unified approach across browsers would simplify things considerably for developers.
There’s a subtlety to how this feature interacts with preload behavior. The tag already supports a preload attribute with values of none, metadata, and auto. Setting preload="none" tells the browser not to fetch any video data until the user initiates playback. But preload and loading serve different purposes. The preload attribute controls what happens once the browser decides to process the element. The loading attribute controls whether the browser processes the element at all based on viewport proximity. Used together, they give developers fine-grained control: lazy load the element, and when it does enter the viewport, fetch only metadata rather than the full file.
That combination could be powerful for publishers.
Consider a long-form article on a major news site — say, a multimedia investigation with eight embedded video clips spread across 5,000 words of text. Today, Chrome begins fetching data for all eight videos as soon as the page loads, even if most readers never scroll past the second one. With native lazy loading, only the first video (visible on initial load) would trigger a download. The rest would wait. For the publisher, that means faster initial page loads, lower CDN costs, and better search rankings. For the reader, it means the text and images they came for appear faster, and their data plan takes less of a hit.
Mobile performance is where this change will be felt most acutely. Google’s own research has repeatedly shown that page load time correlates directly with bounce rates on mobile. Every additional second of load time increases the probability that a user abandons the page. Video is one of the heaviest resource types on the modern web, and deferring its download until it’s actually needed is one of the most impactful optimizations available.
The timing of this move also aligns with broader industry trends around bandwidth efficiency and sustainability. Data centers and network infrastructure consume enormous amounts of energy, and unnecessary data transfer contributes to that consumption. It’s a small point in the grand scheme, but when multiplied across billions of Chrome sessions per day, the aggregate reduction in wasted bandwidth is nontrivial.
So what should web developers do right now? Nothing dramatic. The feature isn’t shipping yet. But it’s worth auditing media-heavy pages to identify where loading="lazy" could be applied once support lands. Developers already using JavaScript-based lazy loading for video should prepare to migrate to the native attribute, which will be simpler and more performant. And anyone still using preload="auto" on off-screen videos should reconsider that choice today, regardless of what Chrome ships next quarter.
Google’s track record with lazy loading for images suggests this rollout, when it comes, will be smooth and well-documented. The image lazy loading feature is now used on millions of websites and has become a default best practice recommended by Lighthouse, Google’s own performance auditing tool. Extending the same capability to video and audio feels less like an innovation and more like an overdue correction — filling a gap that should have been addressed when the original spec was written.
The web has gotten heavier every year. The median page weight has climbed steadily, driven in large part by video content. Chrome handling this at the browser level, rather than expecting every developer to implement their own solution, is the kind of infrastructure-level improvement that compounds across the entire web. Not flashy. Not headline-grabbing in the way an AI feature might be. But potentially one of the most practically useful changes Chrome ships this year.
WebProNews is an iEntry Publication