[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:                   |     Focuses:
-----------------------------+------------------------------

Comment (by jonoaldersonwp):

 This feels like a great win for performance, standards, carbon, etc.

 Is there any reason why we can't/shouldn't implement this, verbatim, as
 per the [https://developers.google.com/web/fundamentals/performance/lazy-
 loading-guidance/images-and-video/ Google documentation] (using the `event
 handlers` method, until such time as the `intersection observer` method is
 universally supported)?

 Given how minimal the JS size and processing overhead is, and given that
 we'll want lazy-loading to be default ''on'' (at least, in future/ongoing
 theme dev etc), I've no objections to the JS being autoloaded on all
 front-end requests (unless it's specifically disabled/de-enqueued).

 I do think that there may be some nuance in implementation; some
 scenarios:

 1. Inline images, inserted in content; where we'll be adding a bunch of
 `data-` params to the code. We'll need any existing or new
 filtering/validation to anticipate and manage this (or, to transform the
 code via a filter on `the_content`, if we're concerned about code bloat or
 confusion in the content editor).

 2. Theme/template images which use `wp_get_attachment_image()` or similar
 to output image HTML. We'll need to hook into these with an additional
 parameter (we ''shouldn't'' make this a universal default/assumption, as
 many themes use 'hero images' in header areas where lazy-loading may
 produce an unwanted delay).

 3. Theme/template images which use `wp_get_attachment_image_srcset()` or
 similar to construct the output of the `img`/`picture` etc tag. This poses
 a challenge.

 The first and the second feel achievable; some settings, an extra
 parameter in the case of **2**, and everything else can happen under the
 hood.

 The third feels like the messiest for easy adoption; we're relying on a
 significant change to coding approaches, which @mor10 rightly wants to
 avoid. Thoughts appreciated!

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