[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 flixos90):

 > 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)?

 I like this idea, relying on a method that has been recommended by one of
 the expert sources in the field seems like a solid approach to me. We
 might even implement both ways in one script, and only execute the modern
 one if `"IntersectionObserver" in window`. Otherwise use the event
 listener one.

 Before we dive into implementation further, I think we need to discuss how
 this should integrate with themes.

 * Given the need for some images to always load immediately and skip lazy-
 load, I suggest we only lazy load when the theme does `add_theme_support(
 'lazy-load' )`. While this will result in adoption of lazy-loading not
 drastically increasing immediately, experience has proven that, over time,
 most theme features introduced were at a certain point commonly supported
 by most themes (think about `title-tag` for example). We just need to
 document well, make supporting the feature easy and encourage it. I think
 by making it opt-in, we're on the safe side. Also, some themes include
 this already, and there are plugins implementing that, so with opt-in we
 ensure that there are no conflicts for those sites.
 * I think we should only account for what we can reasonably account for.
 `<img>` tags in filterable content should be adjusted, as well as any
 calls to `wp_get_attachment_image()`. However, when people use other
 techniques (i.e. "hard-code" the `<img>` tags themselves, what you
 @jonoaldersonwp mentioned too), we shouldn't automatically touch this, as
 it would require some output buffering, which we should avoid IMO.
 Documentation should rather highlight that this way of including images is
 not recommended and `wp_get_attachment_image()` should be used instead.
 Something I'm not sure about is how to deal with background images as
 there's no standardized way of having that markup generated (also it's
 only markup if through an inline `style` attribute, otherwise in a CSS
 file, which makes this more tricky).
 * We need to figure out a way to easily allow theme developers to indicate
 that specific images must not be lazy-loaded. This could mean having a
 specific CSS class for this, or such thing as a `data-skip-lazy-load`
 attribute. Possibly, we could allow content creators to handle this as
 well, by putting a checkbox into the "Insert Media" modal somewhere, which
 says "Skip lazy-loading for this image?" - and if so, put the class or
 attribute into the generated tag.

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