search

aFarkas / lazysizes

High performance and SEO friendly lazy loader for images (responsive and normal), iframes and more, that detects any visibility changes triggered through user interaction, CSS or JavaScript without configuration.
MIT License
17.41k stars 1.73k forks source link

Worth it? #7

Closed rolfnl closed 9 years ago

rolfnl commented 9 years ago

No really an issue, more a thought/question.. because browsers are catching up with implementations and have short release cycles these days.. is it worth to implement such a script/feature into a site when on the browser side things are moving so fast you might not need this, only if you want super browser support and performance is a high priority. (simply put)

As a reference also read (but you probably already know this): http://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/

Thoughts? I like this though, don't get me wrong.

aFarkas commented 9 years ago

I'm not entirely sure how you mean this.

About performance in general Performance improvements should always be considered. The question is only, how much do you have to do, to get more performance. And in case of lazysizes you will get a hugh boost, while it is easy to integrate on the clientside. The only question is how much effort does it cost you to render the required markup through your backend.

About lazysizes responsive image support One goal of lazysizes was to support the responsive image markup especially with the addition of automated sizes calculation. But lazysizes is not a polyfill. If you want to support responsive images in other browsers than Chrome/Opera you need to use a polyfill like picturefill or respimage. Therefore as soon as every browser supports respimg you can drop those polyfills, but lazysizes stays as a great performance and sizes integration tool.

responsive images and the need for lazyloading lazysizes is a follow-up project from the knowledge I "collected" through my work on the respimg polyfill respimage. You really should check this project, if you are interested in HTML5 responsive images!

The average page size is currently about 1.9MB and about 1.2MB of that are images. And still most websites don't use a responsive image strategy. There is a big misunderstanding, that responsive images will make your webpage/webapp faster. respimg is more about serving the right image to the right device, this is mainly about image quality. Due to the fact, that most mobile devices have a 2x resolution mobile will often get higher resolution. A 2x resolution means 4x in file size!

In the css-tricks article you mentioned, this was explained very well. Including the downside that often a 2x device will sometimes get a 3x image. (This means a 2x device gets 50% more pixel than it can display, which means about half of the file size increase is use less extra pixels + the weight of this image in total is 6x higher than a simple 1x image!!!).

Such a massive increase in file size (think 1.2MB * 4) is something, that every user perceives even with a good connection (for example Mac Retina with wifi or cable access/connection).

With lazyloading you get high image quality on the one hand and a good percieved performance on the other. So lazyloading is becomming more important.

aFarkas commented 9 years ago

@rolfnl convinced?

rolfnl commented 9 years ago

I am convinced, I was already convinced ;) I'm just saying this really should be part of the browser's responsibilities (just like respimg was) and because release cycles are now so much fast I think (ehh, hope) this will be picked up by browser devs and be put in a spec and then implemented immediately as this "serving correct images"-business is a very important aspect of the browser imho.

So that said I think you should get this under the attention of some Chrome and Firefox devs and they must improve their browsers (assuming Explorer and Opera and others of course do the same). Let's post message at their

So I hope this will be redundant in a year ;) Until then I'll probably be using it where it makes sense.

aFarkas commented 9 years ago

Ok, now I understand you. The only thing I know of is this: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

There was also a more interesting postbone attribute, but they dropped it. Don't know why.

Additionally I could think, that a browser could abort an image request, if the image is interlaced and the server supports range requests or something like this, after the browser can render some part of the image.

But for things like this you will always need special new markup. Delaying an important image (for example for a canvas game) could slow down everything...