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

 > I think that discussing importance and decoding is getting us a little
 off track here. If those attr are going to be added, it should be after
 this and use the existing regex for performance reasons.

 Frankly don't think discussing `importance` and `decoding` is off track
 here. It's not about adding them, it's how would their presence affect (or
 would it affect) adding `loading="lazy"`. Reading the docs, they seem
 mutually exclusive. Seems WP should not be adding `loading="lazy"` when
 there is `importance="high"` and/or `decoding="sync"` as both of them
 imply that the image has to be loaded "eagerly".

 On the other hand it may be "OK" to add all of these attributes and the
 browser would prioritize them?

 > IMO, I believe that browser will never automatically lazy load images.
 You never know when a image HAS to load. For example, tracking pixels or
 an important logo.

 I share @mikeschroder's concerns here. If the browsers would "never" lazy-
 load images by default, should WordPress be doing it? Seems that figuring
 out the "interactions" between `importance`, `decoding`, and `loading`
 would alleviate some of these concerns.

 Also, don't think this would be a problem for "tracking pixels" as the
 browsers fetch the first 2KB of every image. This does the "tracking"
 request. Also racking pixels are usually smaller than 2KB anyway.

 > I think it would benefit from a public proposal so that we can gather
 feedback from the wider community about potential side effects/edge cases.

 Thinking this is an excellent idea! Perhaps a "request for feedback" post
 on https://make.wordpress.org/core/ with (concise) explanation of the
 benefits and concerns? This will also serve as a early dev. note about
 what may be coming in WP 5.4 :)

 At the same time thinking that shouldn't slow down development of the
 patch. As far as I see, the "worst case" scenario would be that we release
 this as a feature plugin and (try to) solicit wide testing and feedback in
 an attempt to find all edge cases. Planning to look at 44427.8.diff later
 today or tomorrow and see if it can be optimized a bit.

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