Lazy Loading Support Coming at the Browser Level

[Ryuzaki]

Past couple of days there's been some talk about lazy loading again.

Apparently Google has been testing getting lazy loading working in Google Chrome since January 2018. And since March 2019, Mozilla Firefox has started working on it as well. That leaves Microsoft Edge and Apple Safari and that would be enough global support to drop all the plugins and javascript libraries being used for observing the intersection of the images and the viewport and swapping in images.

The real question is whether or not they create a unified, conventional way of doing it, or if each browser decides to be stupid and implement their own methods. It'd be as simple as having us use CSS classes on images such as "lazy-load" and "lazy-skip." We'll see...

They want it to work on iFrames too. There is a chance this could impact display ads if applied automatically in some fashion.

There's also the miniature nightmare of CMS's adding in the CSS Classes (assuming that's how it's done) and having to resave all your content in order to add it in, unless it's added through a filter on the content, which then has a server load and speed impact.

If it's at the rendering level, then Blink (Chromium) and Gecko (Firefox) will be covered the soonest. Then we just need WebKit (Safari). Turns out Microsoft Edge is about to drop EdgeHTML and move to Blink.

 

[Ryuzaki]

The image above shows a Google Chrome employee sharing how this is going to officially work on Chrome at least. You can read the full details here: https://addyosmani.com/blog/lazy-loading/

It's not going to be a CSS attribute, but an HTML attribute within the <img /> tag called loading. (I'm typing this in case the image goes down in the future).

You have two options: loading="lazy" and loading="eager". The first one is self-explanatory. The second one means "skip lazy loading and load the image immediately. Perfection.

If every browser will implement this (and quickly), I'll be a happy camper. I suspect by the time this rolls out, all browsers add it in, and then users update to the new versions, we're still years away. But things are looking up!

 

[turbin3]

The nice thing about going the attribute route is, it'll "fail" gracefully. Old browsers that don't support it will simply ignore the attribute. The trick, then, would be adding some conditional JS logic to a site to load a third party lazyloading library if it's detected the user's browser doesn't support the attribute.

Even better, if existing lazy loading libraries start updating to read not just from classes or ID's, but also those exact attributes. Then we can skip classes all together, standardize on the attribute, and just conditionally load for older browsers (plenty of existing feature support detection scripts out there to do that quickly).

 

[GoldMarketing]

This can be tested by enabling it as experimental feature in Chrome. Just type chrome://flags/ and search for Enable lazy image loading.

 

[Samwise89]

I can't find it again but I saw that people are already tracking a ticket for Wordpress to get them to start working on adding this as a default feature in a way that can fail gracefully as turbin3 said.

If Wordpress picks this up earlier in the adoption cycle that will put the heat on all browsers to get it together and follow a convention too.

Browsers are getting nicer, slowly, but kind of policing the net like Google does. It's mostly been a good thing in terms of spam and development methods. We've seen how they're starting to block 3rd party tracking scripts and all that. I saw Chrome is now thinking about using some different API that sucks a lot worse but makes it possible to block all Ad Blockers. They have a certain incentive to do that. Is that good or bad, I don't know. But if they can use Google's algorithm to enforce better display ad usage by websites, then we won't need ad blockers.

It won't be long before Browsers can build our websites for us on some AMP nonsense.

 

[Ryuzaki]

This saga continues with Google's new Wordpress plugin for Lazy Loading natively with Chrome.

Basically it goes into the_content() and the_excerpt() (I'm guessing, since it's a non-Javascript solution) to add the new "loading" attribute to images.

It does have the classic fallback to Javascript & IntersectionObserver plus adds a noscript tag too.

Ultimately one day IntersectionObserver or some equivalent will be in every browser by default and they'll all standardize on the same loading attributes, and then Wordpress and other CMS's will work the attribute into the core, and we'll all have lazy loading by default.

That's sweet but it does suck to be losing that competitive edge.

 

[Ryuzaki]

The saga continues!

Like .webp images that Google is pushing, Wordpress is ready to fire up the "loading" HTML attribute that directs images to either "lazy" or "eager" load images, meaning lazy load them or not, respectively.

The only problem, like with .webp images, is that the adoption rates by browsers simply isn't there yet. I keep seeing more and more websites with "broken" images because even the newest Safari won't load .webp images.

Here's the adoption rate for the "loading" attribute:

The future looks bright though. That's 61.5% of the global browser usage ready. That will grow fairly quickly. This means that we can lazy load without having to load any javascript, which means a faster internet and lower bandwidth for everyone (not only from lazy loading but loading less scripts).

Google is going to enable lazy loading by default in the "Lite" version of their browser (I guess this is a mobile thing, called Data Saving Mode) that is meant to save bandwidth.

Wordpress 5.4 Lazy Loading

This will be released on March 31, 2020, that could change. It'll be around that time. They're going to insert the "loading" attribute into anything they can within a loop or a function. That means:

• Images in post content
• Images in post excerpts
• Images in comments
• Images in text widget content
• Images fetched by wp_get_attachment_image()
• Images fetched by get_avatar()

It will detect an existing "loading" attribute and not override it.

You can test this out with the plugin they've released for testing purposes: Lazy Loading Feature Plugin by The Wordpress Team

As For Me And My Sites

I'll be disabling this with whatever function they provide until the browser adoption rate is 100%. Then I'm going to happily remove all my lazy loading code and scripts and celebrate one less global file loading on every page. The only problem is everyone gets this gain so there's no competitive edge.

The other thing to note is, there's going to be a lot of places we'll need to manually add the "loading" attribute in our templates since Wordpress can't access them all.

Or if you already run a render blocking javascript file, you could add it that way before the browser attempts to load any images and cover ALL images on the site and not just ones in the loops or WP functions, and disable it in Wordpress altogether.

Either way, the future's looking nice. They're doing more and more of our page speed optimization for us, putting some of us out of a job!

The one thing that will be nice is not having a "data-src" attribute having to swap out with the "src" one. We can simply have the normal "src" attribute and Google can crawl it confidently.

 

[LinkPlate]

The only problem, like with .webp images, is that the adoption rates by browsers simply isn't there yet.

I was just optimizing some websites and realized that there was a quality issue with a lot of images on the sites. The common factor was that they are both using a caching plugin that optimizes JPG and converts images to webp format.

Even when turning off the JPG optimization (since we already upload optimized images), the webp still shrinks the size of the image and affects its quality. It's really disappointing because the speed is great, however looking at the websites, it makes them seem less professional and not as aesthetically pleasing. The lower quality webp versions are just not worth it to save a few milliseconds.

I also know that webp removes the "Use modern image formats" complaint in pagespeed insights, but at this point, I could care less. Would rather someone visiting me view high quality images than care about Google pagespeed insights errors.

What is your take on this?

 

[Ryuzaki]

What is your take on this?

It depends on the site. If it was some kind of product lander or eCommerce I'd rather have high quality images. In fact I'd might upload them at TWICE the resolution you'd expect to see, since smart phones are now have "retina" vision. They might dislay at 600px wide but they're actually loading 1200px wide and then shrinking it to 600px but at twice the pixels per inch or whatever.

So like... even on my sites where I'm just mass publishing content and the image quality isn't that important, I still upload my logos and images I care about at twice the recommended resolution so they look nice and crisp on these newfangeled smartphones.

I was thinking about it earlier today, how Google keeps moving the goal posts with site speed. Now it's not just speed but crap like "cumulative layout shift" and crap that really doesn't matter in the first second of a page load. And they have unrealistic expectations for some of it. You satisfy those and you don't satisfy their page speed expectations, and vice versa. I say do what makes the most money.

 

[LinkPlate]

They might dislay at 600px wide but they're actually loading 1200px wide and then shrinking it to 600px but at twice the pixels per inch or whatever.

Exactly what I was thinking. The retina display is tricky and messing with me. I checked the site on PC and it looks great. On a MAC - meh. I am going to upload them at double the resolution and see how that plays out.