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

 Replying to [comment:70 flixos90]:

 Thanks for the explanation and clarification! :)

 > I think this should be back-ported to all content because only then it
 will have a significant impact on performance of WordPress websites.

 Yep, I agree this will have the highest/best impact.

 > 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.

 Yes, thinking we can try to optimize the exact method used a bit more.
 Also perhaps not parse all `<img>` tags twice with regex. Maybe the
 current functionality can be extended to add all needed HTML attributes at
 the same time/with one `preg_replace_callback()`. Lets look a bit more
 there when reviewing the actual patch.

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

 No, nothing "direct" in the post. But it explains it very well, including
 the "side effects". When thinking more about it, seems the best place for
 this enhancement is in the browsers, i.e. change the default from `eager`
 to `lazy` as you mention :)

 Of course there is the caveat when the browser "doesn't know" the size of
 the image before starting to download it. As mentioned Chrome fetches the
 initial 2KB of each image file to try to get the (intrinsic) size.
 Generally this is "not ideal" as establishing another http(s) connection
 takes time and resources (there are usually 7 "back and forth" between the
 client and the server in an https handshake). I'm not sure if that happens
 for all images or only when there's no `width` and `height` attributes in
 the img tag.

 Perhaps this is something that can be considered when implementing it in
 WP? Would it make sense to make it conditional on having `width` and
 `height` and not having `importance` and `decoding`? Or should we ignore
 the presence of `width` and `height` and assume the browser will always be
 able to get/guess the image size and the webpage content will never "jump
 down" when the user scrolls and images are loaded. Thinking it would be
 great to try to "dig up" some more info about the "interactions" between
 these img tag attributes.

 > I don't think we should expand this ticket further to cover adding these
 attributes too (`importance` and `decoding`), but whether their
 combination can have unintended effects is crucial to know.

 Yes, completely agree. These two attribute seem very specific anyway,
 don't think we can auto-add them even if we wanted to, and seems they
 shouldn't be removed when present.

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