[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:  flixos90
     Type:  feature request                      |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.4
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion                                        |  performance
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:69 azaozz]:

 Thanks for the detailed feedback and thoughts!

 > The more important question (imho): Is this an essential enhancement
 that would require "backporting" to all content ever published in
 WordPress?
 >
 > - If yes, what are the chances the browsers would start lazy-loading
 images by default? Seems like that's the best way to implement it. Reading
 @addyosmani's excellent "introductory" post at https://addyosmani.com/blog
 /lazy-loading/ this seems quite possible?
 >
 > - If no, does it warrant adding yet another runtime filter on all
 content outputted from WordPress that "parses" HTML with regex? This is
 slow, may increase page load time/use of server resources on the front-end
 quite a bit, and prone to edge-case errors/failures. Would it be better to
 add the attributes only in new content, for example in the image and
 gallery blocks, etc.

 I think this should be back-ported to all content because only then it
 will have a significant impact on performance of WordPress websites. We
 surely need to get it right, but I think only adding this to new content
 (e.g. via expanding the `core/image` Gutenberg block type) would leave
 most WordPress sites without major improvements, leaving that chance
 unused. Furthermore doing it on the fly makes this more maintainable, as
 we'd be easily able to make further improvements in the future. In terms
 of the cost, that is certainly a consideration. However, I think the
 impact of one `preg_replace_callback()` per post is rather low on a
 relative scale - the logic for adding `loading` attributes is much cheaper
 than e.g. the one for making images responsive, it includes much less
 logic and no potential database call. Maybe we can optimize the patch
 further though, particularly the additional `preg_match()` that runs for
 every match/image.

 Regarding browsers lazy-loading images by default, I'm personally not
 aware of any such plans. Was there anything particular in the blog post
 that led you to this thought? In that regard, I'd be curious to learn more
 about the behavior of `auto` - is there any chance that `auto` today means
 `eager` and at some point in the future would automatically become `lazy`?
 cc @addyosmani

 > Another question is: Are there any downsides in automatically adding the
 `loading` attribute to all img tags (either in new content or by regex at
 runtime)?

 I don't think there are. The `loading` attribute is a progressive
 enhancement, browsers that don't support it will ignore it. Also, the
 browser implementation is rather conservative in my experience, mostly
 because users not seeing an image yet when it has just entered the
 viewport should be prevented. What is great here over pretty much any JS
 implementation is that e.g. Chrome fetches the initial 2KB of each image
 initially still so that the size of the image is known immediately, thus
 preventing later content shifting once the image has been actually loaded.

 > Looking at the `img` tag specs: https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/img there are several (newer) attributes that may
 need considering. Most importantly the interactions between `decoding`,
 `importance`, and `loading`. What happens when an image has
 `importance="high"` and/or `decoding="sync"` and WP adds `loading="lazy"`?
 Also, should we be considering adding any of these attributes together?

 That's a good question. I haven't been able to dig up a resource on the
 combination of these three, but we should sort that out before moving this
 forward. I don't think we should expand this ticket further to cover
 adding these attributes too, but whether their combination can have
 unintended effects is crucial to know.

 > Also have few remarks about 44427.8.diff. Thinking that, perhaps, some
 things can be done a bit better there but will review it separately after
 the above two questions are cleared.

 Sounds good, let's get back to the specifics of patches once we have
 identified the overall path forward.

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