LGTM1. I was about to suggest that the "tentative" status be removed from the WPTs now that the spec PR is merged <https://github.com/whatwg/html/pull/11980> but that was already taken care of in https://github.com/web-platform-tests/wpt/pull/57754/. On Tuesday, March 31, 2026 at 6:13:00 AM UTC-7 [email protected] wrote:
> *Contact emails* > [email protected] > > *Explainer* > https://scottjehl.com/posts/lazy-media > > *Specification* > https://github.com/whatwg/html/pull/11980 > > *Summary* > Adds the loading attribute to <video> and <audio> elements, allowing > developers to defer media resource loading until the element is near the > viewport using loading="lazy". This matches the existing lazy loading > behavior for <img> and <iframe> elements, improving page load performance > and reducing data usage. CL: > https://chromium-review.googlesource.com/c/chromium/src/+/7511253 > > *Blink component* > Blink>Media > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EMedia%22> > > *Web Feature ID* > loading-lazy-media <https://webstatus.dev/features/loading-lazy-media> > > *Motivation* > Web developers frequently need to defer loading of video and audio > resources to improve page load performance and reduce data usage, > especially on pages with multiple media elements below the fold. Without > native support, developers must implement custom JavaScript solutions using > Intersection Observer to detect when media elements enter the viewport and > then dynamically set the src attribute. This approach is error-prone, adds > complexity, and cannot integrate with the browser's preload scanner. The > loading attribute already exists for <img> and <iframe> elements, and > developers expect the same declarative API for media elements. Native lazy > loading allows the browser to optimize resource loading with network-aware > thresholds, properly handle the interaction with autoplay and preload > attributes, and avoid blocking window.onload for offscreen media. > > *Initial public proposal* > https://github.com/whatwg/html/pull/11980 > > *TAG review* > This is extending an existing attribution that was already reviewed by TAG > (https://github.com/w3ctag/design-reviews/issues/361) so we have not > requested a further review. > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > Low risk. This is a new opt-in feature that follows an established > pattern, the loading attribute already exists for <img> and <iframe> > elements and is interoperable across browsers. Compatibility: Since this is > an additive, opt-in feature, there is no risk to existing content. Pages > that do not use loading="lazy" on media elements will see no change in > behavior. Browsers that do not support the attribute will simply ignore it > and load media eagerly (the default behavior), providing graceful > degradation. > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/1325) Implementation > under way: https://phabricator.services.mozilla.com/D278547 > > *WebKit*: Support ( > https://github.com/WebKit/standards-positions/issues/586) Implementation > under way: https://github.com/WebKit/WebKit/pull/58220 > > *Web developers*: Positive ( > https://github.com/web-platform-dx/developer-signals/issues/534) > > *Other signals*: > > *Ergonomics* > None. The feature improves ergonomics by providing a declarative > alternative to manual JavaScript-based lazy loading solutions. Related > APIs: - The loading attribute interacts with the preload attribute; > loading="lazy" takes precedence over preload, which is intuitive and > matches developer expectations. - The autoplay attribute works correctly > with lazy loading; autoplay is queued until the element enters the > viewport, then triggered automatically. - The poster attribute on video > elements is also deferred when loading="lazy" is set. Performance: - The > feature is entirely asynchronous and does not block the main thread. - Uses > the existing Intersection Observer infrastructure internally, which is > already well-optimized. - Network-aware viewport margins automatically > adjust for connection speed, improving perceived performance on slow > networks. - Lazy media explicitly does not block window.onload, ensuring > page load metrics are not negatively impacted. > > *Activation* > None. This feature has minimal activation risk due to its simplicity and > familiarity. Ease of adoption: - Developers simply add loading="lazy" to > <video> or <audio> elements—no JavaScript required. - The pattern is > already well-known from <img> and <iframe> lazy loading, which has been > supported since 2019. - Works as progressive enhancement; browsers without > support simply ignore the attribute and load eagerly. > > *Security* > None. This feature does not introduce new security considerations. - No > new permissions or capabilities: The feature only controls the timing of > media resource loading, not what can be loaded. - Same security boundaries: > Media loading continues to follow existing CORS and Content Security Policy > rules regardless of the loading attribute value. - No new data exposure: > The feature does not expose any new information to web pages. > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > None > > > *Debuggability* > Supported with existing DevTools features; no special tooling required. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > New Web Platform Tests are added with this implementation. Since the spec > is not yet merged, tests are marked as tentative. Video element tests: - > html/semantics/embedded-content/the-video-element/video-loading-attr-reflect.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-lazy-in-viewport.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-lazy-window-onload.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-lazy-poster-preload.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-lazy-to-eager.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-lazy-load-when-visible.tentative.html > > - > html/semantics/embedded-content/the-video-element/video-loading-eager.tentative.html > > Audio element tests: - > html/semantics/embedded-content/the-audio-element/audio-loading-attr-reflect.tentative.html > > - > html/semantics/embedded-content/the-audio-element/audio-loading-lazy-in-viewport.tentative.html > > - > html/semantics/embedded-content/the-audio-element/audio-loading-lazy-load-when-visible.tentative.html > > - > html/semantics/embedded-content/the-audio-element/audio-loading-lazy-to-eager.tentative.html > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > LazyLoadVideoAndAudio > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/469111735 > > *Measurement* > UseCounters added in > https://chromium-review.git.corp.google.com/c/chromium/src/+/7665925 > > *Availability expectation* > Feature is available on Web Platform Baseline within 12 months of launch > in Chrome. Other implementations are already under way (see above). > > *Adoption expectation* > Feature is considered a best practice for some use case within 12 months > of reaching Web Platform baseline. > > *Adoption plan* > MDN updates are in progress. Chrome DevRel engaged to update their own > guidance. > > *Non-OSS dependencies* > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > None > > *Estimated milestones* > Shipping on desktop 148 > DevTrial on desktop 147 > Shipping on Android 148 > DevTrial on Android 147 > Shipping on WebView 148 > Shipping on iOS 148 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > None > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5200068565139456?gate=5779136872316928 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKSFVWGyOWV%2BKymVmsaro9YbXoN5YYGbnNpnLo1KLe4dCQ%40mail.gmail.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/580b433f-ffda-40a7-9da4-2ac304a54037n%40chromium.org.
