Change Details

This landed in Chrome 76, which is now the stable version: https://www.chromestatus.com/feature/5645767347798016 The description shows how elaborate this first implementation is, taking into account effective network conditions to adapt the amount of lazy-loading: > The distance threshold after which the deferred content will start loading-in depends on factors including the current effective connection type, and whether Lite mode is enabled. The distance is chosen so that the deferred content almost always finishes loading by the time it becomes visible. I've verified this behaviour using a demo page linked from the work-in-progress spec: https://scalable-loading-contribs.firebaseapp.com/test.html and it works as advertised. This adaptive behaviour is more advanced than our current homemade JS-based solution. Additionally, having the browser do it natively will get rid of processing overhead (see T225946). The only unknown is how we could detect that native lazy loading is present, in order to avoid running our own (in case we decide to keep our own for browsers that don't have native lazy loading). I've filed a Chrome bug about that: https://bugs.chromium.org/p/chromium/issues/detail?id=995780

This landed in Chrome 76, which is now the stable version: https://www.chromestatus.com/feature/5645767347798016 The description shows how elaborate this first implementation is, taking into account effective network conditions to adapt the amount of lazy-loading: > The distance threshold after which the deferred content will start loading-in depends on factors including the current effective connection type, and whether Lite mode is enabled. The distance is chosen so that the deferred content almost always finishes loading by the time it becomes visible. I've verified this behaviour using a demo page linked from the work-in-progress spec: https://scalable-loading-contribs.firebaseapp.com/test.html and it works as advertised. This adaptive behaviour is more advanced than our current homemade JS-based solution. Additionally, having the browser do it natively will get rid of processing overhead (see T225946). Support for native image lazy loading can be detected via: ``` if ('loading' in HTMLImageElement.prototype) { } ```

This landed in Chrome 76, which is now the stable version: https://www.chromestatus.com/feature/5645767347798016 The description shows how elaborate this first implementation is, taking into account effective network conditions to adapt the amount of lazy-loading: > The distance threshold after which the deferred content will start loading-in depends on factors including the current effective connection type, and whether Lite mode is enabled. The distance is chosen so that the deferred content almost always finishes loading by the time it becomes visible. I've verified this behaviour using a demo page linked from the work-in-progress spec: https://scalable-loading-contribs.firebaseapp.com/test.html and it works as advertised. This adaptive behaviour is more advanced than our current homemade JS-based solution. Additionally, having the browser do it natively will get rid of processing overhead (see T225946). The only unknown is how we could detect that native lazy loading is present, in order to avoid running our own (in case we decide to keep our own for browsers that don't have native lazy loading). I've filed a Chrome bug about that: https://bugs.chromium.org/p/chromium/issues/detail?id=995780Support for native image lazy loading can be detected via: ``` if ('loading' in HTMLImageElement.prototype) { } ```