Goodbye to Painful Image Loads on Small Devices

http://zurb.com/article/1211/say-goodbye-to-painful-image-loads-on-sma

by seferphier • 13 years ago

109 39 13 years ago

zurb.com

mtrimpe• 13 years ago

I also ran across imgix.com a few days ago which is a CDN that does on the fly image resizing on GPUs.

Are there some examples on how you would integrate something like that here?

sp3322• 13 years ago

It looks like the cool part of this is not serving or making the images, but in the JS to request a specific pre-made image. imgix seems to be more about making new images that fit a page or device exactly. You could probably use them together: zurb would request a specific image size and imgix would generate and serve the image on the fly. But imgix seems to have code for that already, and it's more fine-grained since you don't have to specify your sizes ahead of time.

kellysutton• 13 years ago

The two go together like peanut butter and jelly. As an imgix customer, I can tell you that the service is a godsend. It looks like you would just pass your imgix URLs into the data-interchange tag.

Or for bonus points, fork Interchange and have it pipe every image request through Imgix.

ericcholis• 13 years ago

I've requested access for the service a few times, any tips on getting in?

wonderyak3• 13 years ago

I just heard about this today... the pricing seems a little off kilter unless I'm understanding it incorrectly. How prohibitively expensive would this be for a SMB to implement?

The tech behind the service sounds fantastic, I'd love to be able to use them.

disbelief2• 13 years ago

Could someone explain to me why this is better/easier than just using CSS media queries myself?

Also:

> Whatever image you put inside the src of the image element will render by default. Then, the Javascript will progressively load larger images based on media queries that you pass into the data-interchange attribute.

So, for larger screens, there would be many requests for a single image? For example, if I drop a mobile-optimized image into the src and then view the page on a retina macbook, wouldn't this mean many image requests from the "mobile" version up through "full-size retina"?

sp3322• 13 years ago

So, for larger screens, there would be many requests for a single image?

The demo page doesn't seem to work that way. In fact, if you resize the window gradually, it won't load new images at all. You have to wait for a second after resizing for it to bother loading the new image.

disbelief2• 13 years ago

I see! So maybe it decides which media-query it should be using and then makes the one necessary request?

uptown3• 13 years ago

If you take a look at the Foundation source, the Interchange event responsible for swapping in/out images is setup with a 50 millisecond throttle. That's probably why you're seeing a slight delay. Additionally, they seem to also cache previously-loaded images to speed up future replacements.

From a practical standpoint, this is designed to address device-specific uses where the screen-width is less-likely to experience size-adjustments than a desktop browser, so you'll probably see the initial HTTP request for the small-resolution image, followed by the HTTP request for the appropriately-sized image for whatever device/screen you're using, and you're less-likely to see the same number of requests made while wildly resizing a demo page.

robeasthope• 13 years ago

I'm guessing looks like it's built to solve the problems of serving HD images via a CMS?

For static hand coded images media queries will suffice but once you start dynamically serving images it gets tricky fast, especially when faced with users that don't know/care about HD images issues.

Combined with some code to scale images to the correct size on the fly (with caching, etc) I think it could be pretty useful.

smileyj686• 13 years ago

Poor wording - we match the media queries and the last valid match is loaded, not each in sequence. We'll make that clearer.

bchhun• 13 years ago

I wouldn't mind having Interchange or this: http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/#adaptive... as a standard

smileyj686• 13 years ago

From what I've heard srcset is the likely eventual standard (as oppose to the picture element) but the timeline there is...long and murky.

wonderyak3• 13 years ago

Unfortunately the browser vendors get to make this up as they go along and they seem unwilling to take into consideration the many developers which are more in favor of the <picture> element because its so much easier to write.

Naturally, if/whenever it is implemented we'll all scuttle back to our keyboards and play with srcset .

crazysim2• 13 years ago

Is there an RSS feed of Zurb's blog? I can't seem to find it.

dchest• 13 years ago

http://feeds.feedburner.com/zurb/blog

uptown3• 13 years ago

View the source, Luke:

http://zurb.com/article/rss.rss

http://feeds.feedburner.com/zurb/blog

crazysim2• 13 years ago

Wow, I wonder why my extension didn't pick that up. Thanks.

edit: Ah, no meta tags.

gondo• 13 years ago

this solution does not work as domload is executed way too late and image replacement cause nasty reflow.

RWD images problem is much more complicated than this. you have to consider things like: - dom reflow (img tag without width/heigh) - requests (additional request to load default image) - internet speed (you can use wifi on your phone, or 3g on laptop) - choosing breakpoints

i wrote a blog post about this some time ago http://gondo.webdesigners.sk/responsive-images/ apparently i'm not the first one thinking about using base tag. i've come across some old video (dont remember the link anymore) where it was refused because of "browser bug". unfortunately i never found out what bug is the guy referring to so i can just assume that it was already fixed.

russelluresti• 13 years ago

It's not a bad solution, but I don't think it's the best solution. Obviously, the thing that sticks out as being the most inefficient is that the small (or default) image is always loaded. This means that for tablets and desktop browsers there will be an extra image request that is never used. Not too bad, but on a page with a lot of images this could add up.

I haven't personally tried it yet, but it seems the best option out there at the moment is the Capturing polyfill by Mozilla (https://hacks.mozilla.org/2013/03/capturing-improving-perfor...).

Another thing I would suggest the team think of is not loading images by browser width only. If we're tying these libraries to the idea that they improve performance by optimizing which images are loaded - so that you only transfer the necessary amount of KB per page view - browser width is a bit removed from what you want. What you actually want to measure is the user's network speed (which can be done with libraries like Foresight.js : https://github.com/adamdbradley/foresight.js). Loading large images on a slow network isn't going to be good for performance. By using both browser size and network speed, you can optimize images for mobile devices over 3G or those connected to WiFi. Or desktops on broadband versus desktops on 56k modems.

smileyj686• 13 years ago

Checking network speed is actually a great idea - we'll investigate this. The reason we use the img src (which as you noted means you might load two images) is twofold: so that if your image is the same aspect ratio, you'll get an immediate load of something before the better image comes in (without which you'll have a really nasty reflow). This also guarantees you'll get something that works if JS is disabled or unavailable.

Please submit pull requests or issues for ways we can make this better, we're all ears.

aaronbrethorst2• 13 years ago

This looks great! How do I specify a media query for different screen densities? For instance, if I wanted to serve a 2880px wide image to a 15" Retina MacBook Pro and a 1440px to a 'normal' computer?

smileyj686• 13 years ago

There's a media query available (with prefixes, right now) for pixel density – a retina MBP reports it as 2 whereas a standard one reports it as 1. So you can have a media query for a pixel density >= 2, etc.

aaronbrethorst2• 13 years ago

> with prefixes, right now

Right, which is what concerns me. So is this the expectation?

    <img src="small.jpg" data-interchange="[normal.jpg, (only screen)], [medium.jpg, only screen and (min--moz-device-pixel-ratio: 2), 
        only screen and (-o-min-device-pixel-ratio: 2/1), 
        only screen and (-webkit-min-device-pixel-ratio: 2), 
        only screen and (min-device-pixel-ratio: 2),
        only screen and (max-width: 749px)]">

Groxx• 13 years ago

maybe fat-fingered on a phone? (edit: referring to its previous downvoted state)

newman314• 13 years ago

Does anyone know of a JS slideshow that leverages this? I would love to have the ability to load smaller images for a mobile device.

uptown3• 13 years ago

My guess is that it'll eventually make its way into Orbit, the slideshow from Zurb.

meritt• 13 years ago

How about only loading the best image once? Forcing the smallest image down the throat of everyone is wasteful and only benefits mobile.

da_n2• 13 years ago

I'm a huge fan of Zurb and their work on Foundation, this looks like a good stopgap implementation. I just hope it isn't long until there is a standard implementation everyone can settle on, we don't want to end-up with http://xkcd.com/927/

wonderyak3• 13 years ago

I also am a huge fan of Zurb and Foundation but I'm not sure why this implementation is any better than picturefill. I still have to write a whole bunch of stuff I shouldn't have to write.

Markup for an image should not be several lines long.

da_n2• 13 years ago

I agree it shouldn't, this is why I call it a stopgap measure. Beyond the fact we both dislike extra markup I do find this solution cleaner than picturefill however, at least there are no extra divs inside the markup itself just a data attribute.

r0s2• 13 years ago

How does this compare with existing solutions like: http://adaptive-images.com/ ?

Obviously this is client side, does that make it better? Timing my page load around a set of loading images seems counter intuitive; there's lots of other stuff to worry about.

SkyMarshal• 13 years ago

Looks like it doesn't require PhP, for one.

r0s2• 13 years ago

It also looks vastly less efficient, loading every image size in addition to the one needed.

The server side technique could be achieved in any language really, so it doesn't require PHP unless we use that library.

bsimpson• 13 years ago

Their demo page fails to take into account pixel density, which is a shame since serving the right image to the right device is their entire justification.

Those images look awful on my Chromebook Pixel.

_k• 13 years ago

What if users want to zoom in on the picture ?

Goodbye to Painful Image Loads on Small Devices

Related Stories