At Squarespace, many of our core products are built on web standards, and our engineers are constantly pushing the boundaries of the web’s capabilities. Occasionally, those boundaries reveal a limitation: an opportunity for the web’s native capabilities to grow. This post is the story of how we found such an opportunity to work with the standards community to improve the web in a way that we – and everyone who uses it – can benefit.
Over the past few months, a small team of Squarespace engineers embarked on a journey to contribute back to the web platform and bring a long overdue feature to today’s browsers. In the end, we succeeded: our proposal was adopted as a new feature in the HTML Standard, and we built and contributed spec-compliant browser implementations for Firefox and WebKit that are being considered for inclusion in upcoming versions, as well as automated testing. We also worked closely with Chromium’s developers to help them produce an implementation that now lives in Google Chrome.
For us, this journey was a reminder of just how accessible the web standards community and the browser development process is, even to engineers who don’t specialize in those areas in their daily work. On the web, our medium itself can be changed by any of us willing to get involved. As web developers, we are all capable of building features that work not only for our own users, but for everyone on the world wide web.
This post is part 1 of a 2-part series. For part 2, a best practices guide, be sure to see our follow-up post, How To Use Standard HTML Video & Audio Lazy-Loading on the Web Today.
It Started With a Hackathon…
Last fall, a small team assembled for our semi-annual hack week with aspirations to make a public contribution to web standards. We had a particular problem in our sights. A year prior, I had filed an issue against the HTML Specification to propose that a new feature be added to HTML: lazy loading for the HTML <video> element.
What Is Lazy Loading AND Why Do We Want it?
As a refresher, lazy loading is a pattern to delay downloading resources until they’re needed. Since 2019, standard HTML has afforded authors the ability to delay requests for images and iframes until they are visible in the page – either by scrolling them into the viewport or revealing them in a tab or menu – right when they’re needed.
In HTML, this behavior is controlled declaratively by adding loading="lazy" to <img> and <iframe> elements, like this:
<img loading=”lazy” src=”myimg.png” alt=””>Native HTML lazy loading for images and iframes has saved users truckloads of bandwidth and helps improve page loading performance in general. But despite its success, until now HTML <audio> and <video> have had no similar standards-based mechanism. That’s left developers with no good options to prevent these resources from downloading until they’re needed, so they’ve been left creating workarounds to mimic the behavior by generating or enabling HTML with JavaScript, which can make pages slower, unreliable, and leave code unintuitive and harder to maintain.
A proper solution to this was long overdue. As the HTTPArchive demonstrates, video formats like Webm, MP4, and QuickTime are the heaviest asset types delivered on the web, and when compared to the next-heaviest image formats, it’s not even close.
Downloading videos that are never seen by users is, to be frank, a big waste of energy at internet-scale. Additionally, there was a related problem our team was keen to look at as well: in most browsers, autoplaying videos – controlled by adding an autoplay attribute – start immediately when the page loads, regardless of whether they are visible to the user. That made autoplay useless for videos that aren’t visible when the page loads.
Of course, a video can’t autoplay (or play at all!) until it downloads its resources. Our team thought it stood to reason that a lazy-loading feature could smartly delay autoplay from starting until a video is visible as well.
Our Early Wins
We spent hack week gaining a better understanding of these problems, use cases, and potential hurdles and complications. We also aimed to make a dent in the solution.
By the end, we made great progress. First, a small win: everyone on the team got a crash course on checking out and building major browsers from source, something we rarely otherwise need to do as web developers. Did you know Chromium takes over 6 hours to build on an M2 Mac? Well, I know that now.
There were bigger wins as well. In just a week, our team was able to create working prototype patches for both Firefox and WebKit browsers, a very early draft of a proposal to amend the HTML Standard with video lazy loading, and we drafted Web Platform Tests to demonstrate the functionality as well.
It’s worth mentioning that most of our team had little or no prior experience directly contributing to web standards or writing browser code. All are highly trained, experienced engineers, but they weren’t browser developers by trade – they were full-stack web developers.
That said, web standards work can be a lot more accessible and inclusive than many folks assume! As web developers, we know our standards deeply, and that knowledge is transferable and relevant for any of us who would like to contribute to the platform itself.
Building a Web Standard
Post-hack week, our team was encouraged by feedback across the org and had renewed confidence that our products and customers would benefit from this feature if it really existed. After all, millions of websites run on Squarespace, plenty of them serve video and audio to their customers, and we use those features on our own company websites as well. Of course, more broadly, a standards-based solution would reach far more than our own customers; it’d be built into the browsers for everyone on the web to use. The possibilities for improving experiences beyond our typical reach were exciting to consider.
With the enthusiastic support of Squarespace Engineering, my teammates Credo Duarte, Brad Frost, and Zach Lysobey stayed on to see this through and build video lazy loading into the foundation of the web.
The Ingredients of a New Web Feature
The work involved in shipping new browser features is multi-faceted, with many ingredients that need to be proposed and revised in coordination with one another. This process can take a lot of time, which is reasonable because web standards are meant to be permanent. If you’re coming from a product engineering world where phrases like “perfect is the enemy of good” and “ship early, ship often” are the guiding ethos, you may find this work to be, well, slow. But take heart that the outcome of all this rigor is indeed a beautiful thing. In web standards, breaking changes are meant to be avoided, and we’re not supposed to use the undo or redo buttons – though I have seen exceptions!
Ultimately, if a change involves HTML language features and you’d like it to work in more than one browser, then you’re going to have to propose a change to the HTML Standard itself. These days, the HTML Standard is controlled by the Web Hypertext Application Technology Working Group, or WHATWG, who took over responsibilities from the W3C in 2019. Amendments to the HTML Standard can be proposed by sending a pull request to the WHATWG’s HTML repository on Github, and their contributor guidelines are very helpful in that process.
Opening a pull request against the HTML Standard will reveal a checklist of related tasks that must accompany major proposals. These are things like:
Filing an issue in the tracker describing the need for the change,
Creating Web Platform Tests that allow browsers to validate their implementation of a feature,
Seeking formal browser vendor approval through standards positions,
Filing bugs in browser issue trackers,
Finding implementers interested in writing browser patches (assuming you aren’t planning to do it yourself),
Signing contributor license agreements (which can be done as an individual or on behalf of an organization), and
Ultimately, if you’re lucky, asking for documentation to be added to MDN.
Early on, the order of these steps can be somewhat unimportant. A formal spec will be the source of truth, but sometimes it helps to prototype and experiment with the feature first, and you’re welcome to submit a patch to browser vendors before you have a standard proposal or spec for their engineers to refer to. Alternatively, some folks prefer to channel their test-driven development side and write tests first, which can be a great way to explore and understand the various moving parts.
Our team chose to work on all of these facets from the start, and we found that helped a lot in informing others’ efforts.
Let’s walk through what we’ve contributed to date.
Amending the HTML Standard
Below is a screenshot of our pull request proposing changes to the HTML Standard. The change added sections to the video, audio, and media element specifications, describing how browsers must implement this feature and how authors should use it.
Here’s an example of how those edits look in the HTML Spec, where they live today. You can read them all by visiting the HTML Standard. In it, you’ll find instructions for browser developers (“user agents” in spec terms) to define steps for selecting, fetching, and deferring audio and video resources based on the presence of the new loading attribute (with a value of “lazy”). The spec also describes how autoplay and poster image loading should be deferred when this attribute is present – useful behaviors in their own right.
Our proposal had been in review by the WHATWG since December 2025. During that time, code owners from Mozilla, Apple, and Chromium formally endorsed the change and suggested plenty of revisions to get it ready to ship.
As an example of such revisions, in January, reviewers from Mozilla suggested we broaden the scope of our proposal to include the HTML audio element in addition to video – this made a lot of sense because, as another media type, they happen to share a common base class.
In early February, I presented this proposal to the chair of HTML Working Group, which kicked off the process of moving it through their formal stages of adoption.
On March 23, 2026 HTML Video and Audio Lazy Loading became an official web standard. Here’s the commit where the revisions were merged into the HTML specification.
Web Platform Tests
The major browsers all run a suite of Web Platform Tests to ensure consistent implementation of all web standards. Our team ended up contributing over 30 such tests that serve to validate this new feature’s behavior in audio and video elements.
In February, our tests were merged into the standard suite, which meant browser vendors could automatically pull them into their build processes and ensure their implementations are to-spec.
Now To Patch Those Browsers…
Standards are critical, but browser changes are where the rubber meets the road. Even if a feature is a web standard, that doesn’t mean it’ll be implemented soon or at all by all browsers. Typically, we have to wait for browser vendors to prioritize a feature.
Of course, if you want to get your hands dirty, you can send browser vendors a patch to start moving things along. This was the path our team chose to get this feature adopted sooner.
Contributing Support
To implement support in Firefox, teammate Brad Frost and I co-authored the patch for lazy loading video and audio and contributed it to Mozilla in early January.
In reviewing our patch, the revisions suggested by Mozilla’s engineers informed improvements to our spec proposal numerous times, and we want to send them special thanks for all of their help. We look forward to seeing this patch in an upcoming Firefox release.
Credo Duarte, mentioned earlier, wrote the WebKit patch and we contributed it in February. We look forward to collaborating with the WebKit team to help support land in a future Safari release.
Last but not least, much of the web runs on Chrome today and that’s even more true of Chromium, the browser engine that drives Google Chrome, Microsoft Edge, and many more.
Thanks to third-party engineer Helmut Januschka, video and audio lazy loading was implemented to our spec and on February 20th it was merged into Chromium 147, available for beta testing on March 11th, and set for stable release in Google Chrome 147 on April 7th behind a command line switch — for now! Google’s Roadmap estimates that this feature will be enabled by default in version 148, slated for rollout beginning May 5th.
Update (4/7): Chrome 147 is rolling out to GA today. If you have 147 installed, test this new feature with the --enable-features=LazyLoadVideoAndAudio flag!
Update (5/11): Chrome 148 is now at 100% on all platforms!
If you’re curious about contributing to any or all of these browsers, we found Mozilla’s Firefox Contributor Quick Reference guide to be helpful. For WebKit, their guide is a perfect place to start and, for Chromium, we found Monica Dinculescu’s guide to be a fantastic primer.
Looking Ahead — There’s More To Do!
It’s fun to think of the future patterns this feature enables for the web. Web-based video and audio player sites can now load thousands of media elements that’ll wait to load any data until they’re in-view – something that, until now, involves a fair amount of JavaScript to do well.
Of course, our own products at Squarespace should see massive savings from this work as well. I hope this project demonstrates that as web developers, we not only build on web standards every day, but can directly contribute to how those standards work.
So, to wrap things up, I’ll end with a question:
What should Squarespace build into browsers next?
Thank you for reading. Be sure to check out our follow-up post: How To Use Standard HTML Video & Audio Lazy-Loading on the Web Today.