LGTM2 !! On Wednesday, April 1, 2026 at 4:41:08 PM UTC+2 [email protected] wrote:
> 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/f526563a-dcec-462f-8c8c-951dc8498265n%40chromium.org.
