Cool, nice to see this community effort. LGTM3 On Wed, Apr 1, 2026 at 11:19 AM Yoav Weiss (@Shopify) < [email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f526563a-dcec-462f-8c8c-951dc8498265n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY8TUrgf-eeKD2GHM8fExW0gx%3D-S2Lt%2BNtDVzVU25vZcoQ%40mail.gmail.com.
