loading...

Native Lazy Loading for <img> and is Coming to the Web

ben profile image Ben Halpern ・1 min read

I'm really excited about the upcoming loading attribute in HTML.

<img src="example.jpg" loading="lazy" alt="example" />
<iframe src="example.html" loading="lazy"></iframe>

Lazy loading in this case refers to delaying the loading of certain content until the user is near that content on a page. If they never scroll to the content, it is never loaded.

The loading attribute takes three possible arguments:

  • lazy: Candidate for lazy loading.
  • eager: Load right away.
  • auto: This is the equivalent to not having the attribute.

You have probably seen lazy loading libraries which show a "preview" of an image before loading the whole image. In some ways, this is a really efficient way to deliver content on the web, but since this is done via JavaScript, it is kind of a hacky way to do things. I've never wanted to get JavaScript in between the user and the basic experience on the web.

This new attribute lets that happen without getting in the way.

It will be available in Chrome 75 and can be turned on already by visiting chrome://flags

More info:

Addy Osmani's post

Specification PR:

How do you feel about this?

Posted on by:

ben profile

Ben Halpern

@ben

A Canadian software developer who thinks he’s funny. He/Him.

Discussion

pic
Editor guide
 

Awesome.

Only question is, is there native support too for placeholder image before the lazy loaded image comes in?

Checked the Addy link, didn't seem to notice any placeholder option natively.

I'm terribly excited about this. The less JS, the better.

 

I think it would make sense to put that as a CSS pseudo-class. Could be useful with a broken image pseudo-class too.

 
 

This is absolutely fantastic! Especially since it's arriving just in time to prevent me from learning to do this the hard (current) way.

Now if we could only get Safari to respond to <input type="date">...

 

I'm struggling to see how this feature will be effective if it has to fetch the first 2KB of all images on page-load, just to determine what images are in viewport. Let's say I have 20 images stacked on top of each other ... The browser will need to make 20 image requests to determine which images are in viewport, and only then will it start loading the full images that are within viewport. That's 22 server requests even if there are only 2 images in viewport, something which might slow down the response. And it means 40 server requests for 20 images on a page in total, basically doubling the amount requests.

One could include correct intrinsic placeholders for the images in the layout, but then what would be the point of the browser pre-fetching 2KB data from each image in the first place? Waste of requests and bandwidth.

For now, modern JS IntersectionObserver seems more effective, causing much less requests, only for images in viewport.

Did I miss something?

 

You bring up a very valid point, but I think that the amount of image bloat on most sites these days still makes it a huge net gain at the end of the day.

 

We are waiting for this the long time. I hope that others browsers (firefox and safari) implement this specifications so fast.

 

This almost feels like it should be the default behavior for a browser. I get there's potentially a lot of backwards compatibility issues with that, but that's letting legacy get in the way of a superior web experience.

 

Try Something new:::

Lazy Loading Images and Video Following By Google:
I'm an image!
============Try New==================
I'm an image!
================ JS Link ===============
developers.google.com/web/fundamen...
+++++++++++++++++++++++++++++++++++++++++
I was try this into my website
ictseller.com
This is the doble best solution.

 
 

I'm really excited about the upcoming loading attribute in HTML. ?
Seems like this is only chrome idea. In this case this statement is a lie, isn't it ?

 

It's something being added to the spec, it was actually an engineer at the BBC that suggested the feature πŸ™‚

 

It's the PR Ben linked in the article.

It wasn't added to spec - another lie, isn't it ?

something being added to the spec

That means it's something not in the spec that will be at some point. The world's not out to get you πŸ™‚

People who like that post also:

  1. Not carrying about other browsers than chrome (as pushing (news pressure) mozilla/safari/opera/etc engineers by chrome to introduce something which doesn't exist still in spec is wrongdoing ; Probably you like pressure created by competition and their news (which is still not in specs... I thought that whatwg.org/ is community not driven only by chrome(google) ) (If you still didn't agree I want to here 'how you will feel hearing news like that when you still under same 'community driven group' and your functionality have defects ???

  2. Trying to create their own English gramma/word meaning
    "something being added to the spec"/" = "That means it's something not in the spec that will be at some point."

 
 

Isn't the web great πŸ˜ƒ

 
 

Awesome! Can't wait for this πŸ™

 
[deleted]
 

Wow! This is great stuff. Can't wait for the next Chrome update!

 

Meh, it will take a lot while to be adopted.

 

Yay, that's cool.
Wish they add placeholder too.

 
 
 

that's super cool. I'd rather do this than insert javascript between my content and the reader. The browser was meant to do this kind of work.