

Goodbye to Painful Image Loads on Small Devices - seferphier
http://zurb.com/article/1211/say-goodbye-to-painful-image-loads-on-sma

======
russelluresti
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...](https://hacks.mozilla.org/2013/03/capturing-improving-performance-
of-the-adaptive-web/)).

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.

~~~
smileyj68
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.

------
gondo
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.

------
bsimpson
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.

------
aaronbrethorst
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?

~~~
smileyj68
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.

~~~
aaronbrethorst
> 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)]">

~~~
smileyj68
Lamentably, yes. I'd suspect the prefixes will drop off this year but we're
sort of stuck with the browser adoption in this case.

------
r0s
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
Looks like it doesn't require PhP, for one.

~~~
r0s
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.

------
disbelief
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"?

~~~
sp332
_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.

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

~~~
smileyj68
Correct.

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

------
da_n
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/>

~~~
wonderyak
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_n
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.

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

~~~
smileyj68
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.

~~~
wonderyak
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 .

------
newman314
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.

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

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

~~~
uptown
View the source, Luke:

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

or

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

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

edit: Ah, no meta tags.

------
_k
What if users want to zoom in on the picture ?

------
mtrimpe
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?

~~~
kellysutton
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.

~~~
wonderyak
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.

~~~
nsp
I don't have a lot of experience with imgix, but <http://filepicker.io> will
resize your images on demand server side, and its all hosted in your S3
bucket/pretty reasonable pricing.

Example:

640x400 and formatted as a jpg

[https://www.filepicker.io/api/file/rHA62UiiQyCZdEyw6rgw/conv...](https://www.filepicker.io/api/file/rHA62UiiQyCZdEyw6rgw/convert?w=640&h=400&fit=crop&format=jpg)

200x200 and a png

[https://www.filepicker.io/api/file/rHA62UiiQyCZdEyw6rgw/conv...](https://www.filepicker.io/api/file/rHA62UiiQyCZdEyw6rgw/convert?w=200&h=200&fit=crop&format=png)

