*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/CAFmjHKSvRRYgqOhJmPfKMoRsE6dx6d2oALfhzAg_2Zk7EO6yug%40mail.gmail.com.
