By Scott Jehl
In case you haven't already heard, my team at Squarespace has been working to standardize HTML Video & Audio element lazy-loading, and good things are happening!
This feature began as an issue filed in the HTML tracker in 2024, but in the span of the last 3 months the actual work on it has ramped up! As is the nature of web standards work, this has all been happening in public and progressing fast, so I wanted to post a summary of what's happened so far and how and where the feature works today.
Long story short, the feature is not yet standard, but the HTML spec proposal, platform tests, and browser patches have been in review for many weeks and support just landed behind a flag in Chrome Canary! Things are moving along in a very positive direction and you can start experimenting with it today!
A Quick Disclaimer/Note! this is an unofficial/personal post summarizing the public progress on this feature to date. You'll likely see better coverage as support and standardization finalizes and lands in stable browser versions. As an aside, it has been amazing to see my employer, Squarespace, support our work to bring this feature to everyone on the web. This work takes time and care and I'm thrilled to see them excitedly giving back to the open web.
What's Happened So Far
Since early December, the public work on this feature has involved:
- Proposing and iterating on changes to the HTML Standard Specification,
- Writing Web platform tests for browsers to validate against, and
- Contributing patches to Firefox and Webkit to implement this feature in today's browsers.
- Also! Thanks to some amazing work from Chromium Developer Helmut Januschka, you can now use this feature in Chrome Canary!
A special early shoutout is due to Brad Frost (...this Brad), Credo Duarte, and Zach Lysobey for their collaboration on the above features, as well as our teammates on the Websites team for code reviews and support, and to Keith Cirkel and Simon Pieters.
How it Works
As the HTTP Archive reminds us, video and audio files are some of the heaviest resources requested by web pages. This new standard will dramatically reduce page weight and ease resource overhead all through a simple declarative HTML attribute.
Lazy audio and video works just like lazy-loading of image and iframe elements work today: just add loading="lazy" to an audio or video element and it'll defer the loading of assets like video and audio files and poster images, and delay autoplay, until the element is visible in the browser viewport.
For example:
<video
loading="lazy"
autoplay playsinline muted controls
src="path/to/sloth.webm"
poster="path/to/sloth.jpg"></video>
<audio
loading="lazy"
autoplay playsinline muted controls
src="path/to/sloth-sounds.mp3"></audio>
With that attribute in place, browsers will load the media based on whether the element is visible or near the viewport.
Try it out Below!
This feature is coming to today's browsers and is already available in Chrome Canary.
Here's how to use it (It's cross-platform, but these are Mac instructions):
- Download Chrome Canary
- Drag it to your Applications folder
- Start it up with the feature enabled:
$ /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-features=LazyLoadVideoAndAudio
Once you're in Chrome Canary, reopen this blog post and scroll down to see the video element below. It has autoplay and a poster image to demonstrate both deferred asset loading and play start (you can watch the requests in Developer tools, if you're so inclined).
Okay, Start scrolling...
Keep going...
Okay, here it is:
And there it is. You're looking at the first native lazy-loaded video on a public website.
I mean, probably.
And of course, <audio> elements will support this too, which should bring interesting performance benefits in web audio interfaces.
A Quick Performance Note: it's early to form best practices around this, but here's one that's pretty certain. Just as with images, you won't want to use lazy-loading on videos that are likely to be front-and-center in the viewport when the page loads. That's because the feature will naturally cause resources to request later than they otherwise would, waiting for page layout to define whether they're needed. That makes this feature best for media that's unlikely to be visible when the page first loads (far down the page, inside a tab or carousel, etc.). So try and reserve it for that!
What's Next?
Folks are preparing the standards and patches to be accepted in their respective destinations. You can keep an eye on browsers' nightly release channels and this WHATWG Pull Request to see when this feature lands in the HTML standard. And I'll post here as well.
In the meantime, you can go ahead and experiment with this feature yourself too, as the attribute is simply ignored in browsers that don't support the feature.
Stay tuned!