The specification for native image lazy-loading is merged into HTML standard

If you are going to use this, keep in mind the advice given... set the height and width attributes of the image to prevent the page jumping around for lazily loaded images.<p>Which means, if you accept user generated content or images from any CMS or other source you really should be obtaining the image dimensions and using them in the HTML.

Lazy loading can be frustrating when the connection between the website and your browser is slow. I come across this from time to time and the result is that every time you scroll down, you have to wait ages for the next set of images to load.

Now that this is in the spec we just need browsers to implement it and then I can make a &quot;shaking your phone loads things faster&quot; plugin. People will notice a slight difference just often enough where eager loading worked out better. They&#x27;ll waggle their phones all the time. It&#x27;s going to look hilarious.

This is exciting, because the sooner developers standardize on single method of lazy-loading, the sooner I&#x27;ll be able to disable it with a userscript.

I wish browser vendors, instead of native lazy loading for images, focused on a universal mechanism to lazily render arbitrary elements, including custom ones.<p>Browsers could profile how long rendering a particular type of element takes on a given website, and optimize render triggers to provide seamless experience while conserving bandwidth.<p>Currently lazily rendering custom elements requires a fair chunk of IntersectionObserver boilerplate code, and beyond that any adaptability to user connection seems too complex to even consider.

<a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1542784" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1542784</a><p>The bug is already closed in Firefox. Hopefully it&#x27;ll be here soon.

While I think lazy loading is great in itself, I wonder why we haven&#x27;t come up with something better before.<p>There is progressive loading embedded directly into JPEG and if browsers would prioritize loading of assets through the DOM (order), we wouldn&#x27;t need any other solutions.<p>Or am I wrong here?

I hate lazy-loading so much, since it never keeps up with my scrolling speed. So I first have to scroll down slowly and wait for everything to load, then go back to the beginning and start for real. Tried some methods to stop lazy-loading but none worked reliably.

Lazy loading is helpful but if the img tags&#x27; sizes attribute is mucked up then less is gained. That is for example, due to the sizes the browser is led to believe it needs an image that&#x27;s 100vw when the actual width is 25vw. This happen quite a bit with WordPress.<p>Here&#x27;s a great article on sizes and srcset.<p><a href="https:&#x2F;&#x2F;ericportis.com&#x2F;posts&#x2F;2014&#x2F;srcset-sizes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ericportis.com&#x2F;posts&#x2F;2014&#x2F;srcset-sizes&#x2F;</a><p>Editorial: Personally, my fear (based on history) is this will ultimately lead to more bloat, not less. The belief in &quot;oh not to worry, we&#x27;ve got lazy load&quot; is not a positive overall.<p>LL is a good thing. But it will likely increase abuse, not mitigate it.

The first mainstream browsers with support: Chrome and <i>Edge</i>!<p><a href="https:&#x2F;&#x2F;caniuse.com&#x2F;#feat=loading-lazy-attr" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;#feat=loading-lazy-attr</a>

I remember there was a huge protest from the ad industry over that.<p>This is the time we live in now, web standards are set by the ad industry

Status on Safari [1];<p>&gt;<i>Rob Buis 2020-02-13 00:04:07 PST<p>I was waiting for the spec to land before working again on this. First step is to fix the tests: <a href="https:&#x2F;&#x2F;github.com&#x2F;web-platform-tests&#x2F;wpt&#x2F;pull&#x2F;21773" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;web-platform-tests&#x2F;wpt&#x2F;pull&#x2F;21773</a><p>I&#x27;ll incorporate them into <a href="https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=200764" rel="nofollow">https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=200764</a>, test a bit and hopefully put it up for review soon.</i><p>This is exciting. We should have all major browser supporting it within this year. Fewer Javascript required.<p>[1] <a href="https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=196698" rel="nofollow">https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=196698</a>

I detest hard coding image sizes. I only want to add `img { width: 100% }` and that&#x27;s it.

So this means better user tracking capabilities are now native, even with Javascript disabled.<p>You can learn what the user have read on the page before, and deliver more relevant ads next.

It seems like this is bound to have security holes at least for a while, right?