[wp-trac] [WordPress Trac] #44427: Introduce lazy-loading API for media and other elements

[WordPress Trac]

#44427: Introduce lazy-loading API for media and other elements
------------------------------------------+------------------------------
 Reporter:  mor10                         |       Owner:  (none)
     Type:  feature request               |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Media                         |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  performance
------------------------------------------+------------------------------

Comment (by mor10):

 @JakePT The main purpose of performance enhancements is exactly what you
 are asking for: Creating better user experiences for people on slow
 connections or with slower / older / less fancy devices. Reducing the
 weight of a page load, optimizing the delivery of assets, all these things
 benefit people on slow connections and/or devices more than it benefits
 people on broadband with top-of-the-line devices.

 Lazy loading was created specifically to address page load for people on
 slower connections because of large page sizes mainly caused by images
 appearing "below the fold" and out of view. There's ample research to show
 people rarely scroll all the way down a page, and loading images out of
 view is a waste of valuable resources which incurs cost and slowness for
 the end-user, especially on slow connections. By lazy loading images and
 other heavy assets, the user is delivered a significantly improved user
 experience while at the same time saving both time and money.

 The specific spec from Google, which is now implemented in Chrome, is to
 use the `loading` attribute to instruct the browser on ''how'' to lazy
 load images and iframes. By default, the browser treats all images and
 iframes as `loading="auto"` meaning the browser automatically lazy loads
 assets based on its own formula. Developers can set each asset to either
 `loading="lazy"` which "defers loading of the resource until it reaches a
 calculated distance from the viewport", or `loading="eager"` which "loads
 the resource immediately, regardless of where it's located on the page."

 My proposal is to build this functionality into WP core to give developers
 and users direct access to this functionality:

 - Developers can tag individual images or image types with either `lazy`
 or `eager` to control how they are loaded. A good example would be
 featured images being set to `eager` because they typically appear at the
 top.
 - Users ''could'' be provided with a toggle to choose if they want
 individual images to load `lazy` or `eager`, but this is quite advanced
 and puts the onus on the end-user to know what lazy loading means and how
 it impacts performance.

 Two crucial aspects of the proposal by Google are:
 1. Unlike current implementations of lazy loading which use JavaScript and
 an IntersectionObserver or similar to load images when they appear
 ''within the viewport'', the new spec loads the image when it is within a
 "calculated distance threshold" (https://web.dev/native-lazy-loading#load-
 in-distance-threshold) meaning the image is likely to be loaded ''before''
 it hits the viewport, thus reducing the risk of the scenario you are
 worried about with images not appearing when they are supposed to.
 2. The proposal is closely related to the `intrinsicsize` attribute
 proposal (https://github.com/WICG/intrinsicsize-attribute) which is slowly
 rolling out and will make it easier for browsers to clear space for yet-
 to-be-loaded images and other assets.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44427#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform