[wp-trac] [WordPress Trac] #44427: Introduce lazy-loading API for media and other elements
WordPress Trac
noreply at wordpress.org
Thu Jan 9 06:25:38 UTC 2020
#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 mikeschroder):
Replying to [comment:67 spacedmonkey]:
> Lazy loading images / iframes, is an opt in feature in chrome. There
many use cases that require an image or iframe to be loaded on page load.
A good example of which would be a tracking pixel. This image is not
loaded, then a page view is not tracked. So the browser can not and should
not force this behavior.
>
> In the WordPress use case, image tag generated by PHP seems to be
reasonable to make lazy loading. It is the some reasoning behind srcset,
to increase loading performance and make user experience better.
Thanks for the reply! While both lazy loading and srcset are both
performance-centered features for images, I think they're a bit different.
Users already had the expectation that those sizes were generated for the
images' use with respimg, but it's seems like a pretty big behavioural
change for images not to be loaded automatically at all.
> 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'm concerned about this, but from the WordPress side of things. How can
WordPress know what a user intended -- in particular with previous
images/themes that weren't aware of this feature? I like the idea if we
can do it safely -- just want to be sure that I understand what makes
things different here.
A quick note that if it's decided to go ahead with this, 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/44427#comment:75>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list