Why do you have to specify the padding-bottom? Is it the image ratio (as 16:9 = 56.25%)? In that case, it would practically render the plugin useless for sites with many images with unknown size.
You can read about the padding-bottom technique at http://alistapart.com/article/creating-intrinsic-ratios-for-...
It helps you preserve space for the image and prevents reflowing. If you have many images with unknown sizes there will be massive reflowing and the library can be tweaked to support that too if you really want it.
A big drawback of Pufferfish.js is that images are not indexable by Google. That's not the case with ResponsivelyLazy.js. It works great in search engines, social networks and read-it-later tools.
If you are using a browser that does not support the srcset attribute, the default image will be loaded, and no magic will happen.
Can you please tell me what your device, browser and window width are.
It seems to work - for me, in Chrome 44 on a Mac, at least - if you start with a mobile-width browser and then resize the window wider. Resizing from large to small doesn't seem to work.
This is the code for the library:
<script async src="responsivelyLazy.min.js"></script>
No images are visible until the library file loads. If you want you can inline the js code.
If you primarily care more about responsive images than about lazy loading, the Picturefill polyfill (https://github.com/scottjehl/picturefill) is a great option.
- The data:image in the srcset attribute shows transparent image and prevents loading the image in the src attribute in modern browsers
- The image in the src is attribute is used if the browser does not support the srcset attribute or when the page is scanned by social networks and read-it-later tools.
Lazy loading is a waste of time in my opinion. Yes it can save bandwidth but it actually creates an awful user experience.
If you have a bunch of images you don't want to wait to load them until in view especially on a slow connection. If you lazy load the images then that means every time the user scrolls they have to wait for an image. No one is going to wait for your image to load, so they will scroll on. You then cause a bottleneck in your javascript because the user is scrolling and you are using JS to download images which is not optimal.
The experience you want is to load the first image and then load then next image before the user gets to it so that it is ready when the user scrolls. Our browsers do a great job of this already. Don't reinvent the wheel. Our browsers have been optimized to download images the right way. And if you want to save bandwidth then use responsive images and let the browser determine the best size to download.
I've implemented lazy load on mobile and learned this first hand. I thought I needed lazy load, but to my surprise, the browser actually knows how to load images the right way. My app actually had less jank and loaded images faster when I left the images up to the browser.
Usually when I am on a slow mobile connection, I open a lot of tabs. In this case, the benefits of lazy loading are clearly visible. I agree it will be great to load all images, and it will be awesome if we can detect in JavaScript there is available bandwidth and preload the images that are below the fold.
Again even if you could detect bandwidth, you wouldn't want to do this because the current bandwidth is not a prediction of the future bandwidth. So then you get into a game of trying to predict bandwidth which is a fools game. I think even Google stop trying to predict bandwidth with Android.
And it makes the website change its layout multiple times which makes it really impractical for reading. And it ensures any user who disabled javascript will browse away very quickly from your site.
P.S. I'm totally with you on pointless lazy-loading - the browser should figure out what is sensible to load based on available bandwidth and where I have scrolled to...
From that link: "Lazy loading is a technique that defers image loading until it becomes visible on the screen."
Isn't this exactly the "pointless lazy-loading" that you and the OP are complaining about? If what you want is to "load only the right size images for different devices," and you're targeting browsers that support srcset, you can just use srcset.
Well I think this looks pretty good, the only issue is modern browsers without Javascript. It provides a lot of fallbacks that srcset does not on it's own.
No, it's not pointless; I think it's actually quite useful if you rely on Javascript, which some say is the worst thing in the world... but after using React I've been persuaded for complex interfaces it can provide clear advantages over progressive enhancement.
Sorry, what browsers? There is no such thing. Even virtually everyone's phone runs javascript.
The only way you are running a modern browser without JS is if you've (as a power-user) turned it off. In which case you need to turn it back on when you encounter weirdness on a website that expects that your browser behaves like a normal modern browser. If you run your browser without JS (like I do), then you encounter this situation frequently and it's part of the tradeoff of controlling exactly what code runs during your web experience.
If the browser is "modern" the blank image in the srcset will be loaded, not the image. And then nobody will load the correct image version. This is the problem i think.
> This is the source of the best lazy loading implementation available.
How can this claim to be the "best" when it's browser support is barely over 50%? Here's the one that I feel is "best" after trying many, it supports IE7, which is effectively 100% browser support as far as I'm concerned.
The browser support is currently 62% and rising, and a high-quality image can be shown on "not modern" browsers. So in terms of showing quality images the best possible way the support is almost 100% (we already discussed the case with the disabled JavaScript).
I've just noticed this demo exposes a Firefox bug with image scaling that I'm quite surprised to see. Not related to lazy loading, but may be of interest.
Bug: When the same image is found elsewhere on the page, Firefox doesn't bother using smooth interpolation when downscaling.
[Edit - workaround is to avoid cache, as in cat.jpg?01 ; cat.jpg?02 ]
Look at the cat's whiskers, they look rough in the smallest image. They should look smooth. So using Firebug I removed all other images on the page except the first smallest version. Hey presto, the whiskers are suddenly smooth.
I think the problem of lazy loading should be solved by browser vendors (maybe adding some new attribute on img). And it's sad that it doesn't work without JS. Cannot we fix this by using noscript tag?
55 comments
[ 3.5 ms ] story [ 109 ms ] threadAt the same time, one could use something like ImageMagick to find out the dimensions of the picture and set this ratio programatically (http://stackoverflow.com/questions/16266933/rmagick-how-do-i...)
It's a strict polyfill of the picture / srcset standards, which already have broad, native browser support: http://caniuse.com/#search=picture|srcset
- The data:image in the srcset attribute shows transparent image and prevents loading the image in the src attribute in modern browsers
- The image in the src is attribute is used if the browser does not support the srcset attribute or when the page is scanned by social networks and read-it-later tools.
If you have a bunch of images you don't want to wait to load them until in view especially on a slow connection. If you lazy load the images then that means every time the user scrolls they have to wait for an image. No one is going to wait for your image to load, so they will scroll on. You then cause a bottleneck in your javascript because the user is scrolling and you are using JS to download images which is not optimal.
The experience you want is to load the first image and then load then next image before the user gets to it so that it is ready when the user scrolls. Our browsers do a great job of this already. Don't reinvent the wheel. Our browsers have been optimized to download images the right way. And if you want to save bandwidth then use responsive images and let the browser determine the best size to download.
I've implemented lazy load on mobile and learned this first hand. I thought I needed lazy load, but to my surprise, the browser actually knows how to load images the right way. My app actually had less jank and loaded images faster when I left the images up to the browser.
Stop over engineering image loading please :-)
The technique here is an excellent way to load only the right size images for different devices.
It works in about 65% of browsers and has excellent fallback characteristics in others.
Read the bottom of the blogpost here for details:
http://ivopetkov.com/b/lazy-load-responsive-images/
P.S. I'm totally with you on pointless lazy-loading - the browser should figure out what is sensible to load based on available bandwidth and where I have scrolled to...
Isn't this exactly the "pointless lazy-loading" that you and the OP are complaining about? If what you want is to "load only the right size images for different devices," and you're targeting browsers that support srcset, you can just use srcset.
No, it's not pointless; I think it's actually quite useful if you rely on Javascript, which some say is the worst thing in the world... but after using React I've been persuaded for complex interfaces it can provide clear advantages over progressive enhancement.
Sorry, what browsers? There is no such thing. Even virtually everyone's phone runs javascript.
The only way you are running a modern browser without JS is if you've (as a power-user) turned it off. In which case you need to turn it back on when you encounter weirdness on a website that expects that your browser behaves like a normal modern browser. If you run your browser without JS (like I do), then you encounter this situation frequently and it's part of the tradeoff of controlling exactly what code runs during your web experience.
If your page has lots of search results and lots of images it really saves a huge amount and makes the page feel much lighter.
How can this claim to be the "best" when it's browser support is barely over 50%? Here's the one that I feel is "best" after trying many, it supports IE7, which is effectively 100% browser support as far as I'm concerned.
https://github.com/dinbror/blazy
Bug: When the same image is found elsewhere on the page, Firefox doesn't bother using smooth interpolation when downscaling.
[Edit - workaround is to avoid cache, as in cat.jpg?01 ; cat.jpg?02 ]
Look at the cat's whiskers, they look rough in the smallest image. They should look smooth. So using Firebug I removed all other images on the page except the first smallest version. Hey presto, the whiskers are suddenly smooth.
http://ivopetkov.github.io/responsivelyLazy/
Of course, IE is a lot worse - its scaling is rough all the time regardless.