Responsive images: What’s that?

cover-photo

TL;DR Responsive web design isn’t simply having a flexible grid framework.  A truly responsive site will have the pages’ actual content, not just layout, respond to the physical device and the user’s situation.  Having responsive images is going to make your site faster and save users money. Modern browsers aren’t able to make our images responsive on their own (yet), but there’s still a lot we can do as front-enders. If you are familiar with responsive images already and are looking for a solution/an actual implementation: you’ll want to read my post about using Picturefill to deliver responsive images.

Your new (nearly) responsive website

You’ve just built your client a super slick responsive site. They now watch as the pages twist and transform before their very eyes as you expand and collapse the web browser’s frame. You explain that this new, modern, responsive site will adapt to any device it is displayed on. Congratulations; you are King-wizard of the Internet!

Buuuut I have two questions for you, my fellow front-end soldier.

  1. Why are you asking the server for a 1800px wide image to be displayed on an iPhone 5?
  2. Do those <img> tags really say “display: none”???

rwd_imgs

RWD ain’t easy

I had once read an article about responsive web design (RWD) that if you are ever using {display: none;} as a solution for RWD-ing, then you really aren’t RWD-ing at all. (The phrasing may have been a bit different).

If it isn’t immediately clear why this is true, then let’s go take a look at the hypothetical website we made earlier and address those two questions.

Images are data hogs

First, we questioned why such a large image was being called up to be displayed on a handheld mobile device. It’s likely the site’s code looks something like this:

<article>
<img src=“../img/boardroom.png” alt=“Synergy meeting”>
<p>Efficiently unleash cross-media information without cross-media value. Quickly maximize timely deliverables for real-time schemas. Dramatically maintain clicks-and-mortar solutions without functional solutions.</p>
</article>

Now, the issue isn’t that a 1800px wide photo is going to be scaled down into an image container 1/5th its size. That’s fine; browsers scale images down quite well. The problem is that while the image ends up displayed only 320px wide on the iPhone it still chews up just as many resources as it would when displayed at it’s natural size. If the boardroom picture is 4MB on a desktop… it’s 4MB on a mobile device. And depending on what type of Internet connection that mobile device has, you may be waiting a loooong time for that stock photo.

IRL demo

I went on Wikipedia to find some extra large images and I made some GIFs (yeah, GIFs!) to help demonstrate this load time. In an article about videoconferencing I found a nice high resolution image:

Boardroom

Cool stuff! Now notice that this is indeed a relatively large file for a basic page’s content. It’s over 3000px wide and 4.1MB.

Boardroom image details

Is 4MB actually a lot of memory? Well, using Google Chrome’s Inspector we can see how long it takes to load.

Boardroom photo loading

It took over 6 seconds for the browser to receive and display 4MB – which is a long time to wait for pixels we won’t even be able to see. Let’s pretend that we were using this Wikipedia image in our example website and we will only be using the image size of 1280px by 817px for a desktop display. How long would it take that image to load?

Desktop size image load

35.353 ms. Thirty-five MILLISECONDS. That’s 180 times faster than the photo at it’s original size and the image size is about 25 times smaller. This is great! We’ll just use this on our website since 1280px wide is a pretty standard size for desktop. Except…

What if we were on that iPhone 5 that sparked our first concern about whether this new site was actually responsive? What would the difference be if we were served up an image that was more appropriate to that size? Let’s check the 320px wide image.

Mobile image size loading

It didn’t even take a millisecond to download this information. In comparison to the desktop image, our mobile appropriate photo loaded 35 times faster and was over 8 times smaller. This may seem like small gains, but imagine this website contained not just one image (most don’t), but 10, 20, or 30 images. Now multiply these savings in time and memory by each person that is accessing that page. This stuff adds up.

It should be acknowledged that this demo of response and download times was made from my home computer using our wifi. Performance in load time would most likely be different if I was on the same page on my iPhone, 50 kilometres out of the city, and sitting in my fallout shelter. It would be worse.

The point?

Hang around web development long enough and most conversations will turn to optimization. Minified scripts and stylesheets, server requests, CDN, asynchronization… a lot of brain power is devoted to thinking of ways to deliver websites faster. It seems like a lot of wasted effort though if all it takes is one oversized image of your cat to wipe away all these smaller savings.

A truly responsive website would have content that’s just as responsive as the layout. It would be great if we could serve up appropriately sized media for the device/situation.  Browsers aren’t able to do this for us just yet, but there is a very cool solution for delivering responsive images developed by the folks at the filament group called Picturefill.js.  If you want to know more: check out (my tutorial on picture fill.js).  Picturefill.js is a much better solution than using certain CSS techniques such as {display:none;} as your RWD solution.  If you wan’t to know why this is a bad idea: keep reading.

Under the rug is NOT a solution

CSS3 has given us @media queries and they are incredibly powerful for front-end developers. Bootstrap’s responsive framework makes great use of these and are core to the “mobile first” philosophy of RWD. There are even classes in Bootstrap’s responsive utilities kit that will show and hide elements at specified media widths. These are super handy, but really should not be used on media if possible.

Why? Just because you can’t see it doesn’t mean it’s not there. Those hidden images (and video) are still loading and chewing up resources. Check out my Bad News Bear pen I made on CodePen – try adjusting the size of the frame and watch the size of the image change.

See the Pen Bad News Bear by Nathan Ferguson (@NathanPJF) on CodePen.

In this CodePen example, CSS is being used to apply {display: none;} to different images at certain breakpoints – so it seems like we are getting appropriate image sizes depending on the width of the device. But the problem with just relying on the display property is that as soon as the page loads, all those images load one after the other.

Multiple file loads

Using {display: none;} as your RWD solution is actual more resource intensive than if we just cramped the desktop size image for all display sizes.  What we really need is a solution that only loads images at the size appropriate for the size of the device the user is on.

“What’s with the weird file names in these examples?” you ask.  Well, because I’m a cool guy, I’m using imgur to host my image files.

An actual solution: Picturefill.js

The talented and brilliant people over at the filament group have been working on a solution for responsive images for years and, lucky for you and I, have made Picturefill.js publicly available.

Something to keep in mind: As an open-source project, Picturefill has had multiple iterations and continues to be developed.  It looks like picturefill.js has become fairly stable, but there’s always the possibility that it’s implementation and mark-up will have changed from the time of me writing about it to the time you read this.


Picturefill doesn’t simply display and hide images, but swamps out images in real time and only loads the pictures you actually need. I discuss (how to use picturefill in another post)[link!], but you can check out my Pen below to see it in action.

See the Pen Picturefill with by Nathan Ferguson (@NathanPJF) on CodePen.

And in case you missed the magic, here’s a GIF to make it clear…

Picturefill demo on CodePen

Thanks to Picturefill.js, the first image call was actually canceled.   The first image would have been great for a desktop monitor, but unnecessarily big for a tablet or smaller.  So the the large desktop image was skipped (no information was downloaded) and the image which I specified to be used for “medium width” devices was displayed.

Download canceled

Isn’t that awesome!?!

Level 2: Automation

You know now that {display: none;} is not good practice for trying to display responsive images. However, you may be looking at the code in the Pen above and thinking this seems a bit intimidating/lengthy/a pain in the butt to do for all your images. Don’t worry my front-end developing, friend – we can do this programatically thanks to the wonderful world of CMS.

I have posts in the works on how to implement this solution with WordPress and Shopify – so check back later, dawgs!

Wait… why should I care about responsive images?

No one likes to wait for a page to load. This is obvious. And there is more than enough evidence that explain how a slow website costs businesses money in high bounce-rates and cart abandonment. This alone is enough to make the case for responsive images; however, here’s a reason you may not have thought about:

There’s a very good chance that you, the visitor to my website who is interested in front-end development, lives in a well-developed part of the world – much like I do. Free wifi signals happily dance in our cafés, the rivers runneth over with ample bandwidth, and we blissfully consume an unending feast of high-resolution handheld devices from friendly vendors offering ‘unlimited’ data. This life is… definitely not a global reality.

In other parts of the world, mobile devices and the Internet are accessible, but the data needed for using these tools is sold at a premium. Websites that are resource heavy are well-known and avoided. True RWD is more important than ever given that the more populated developing countries have skyrocketed in mobile phone adoption. Market forces are going to make responsive images not a “nice to have” feature, but a requirement for any business looking at their web strategy with any seriousness.

Not just a problem for ‘other people’

We don’t even need to travel abroad to find people who would benefit from bandwidth-conscious websites. Discount, no frills cell phone providers like Koodo, Wind Mobile, and Fido’s entire consumer base are people who are willing to sacrifice data usage in favour of a cheaper monthly bill. They don’t need you capping out their usage early because you’ve been serving up their phones with super-sized images or other such cool, yet expensive “features”.

We like to think that things are always getting better. Things will be faster, cheaper, and more available “in the future”. An unsettling, but plausible, reality is things won’t be.  Remember “Net Neutrality”? No? Remember The Internet is a series of tubes? Oh man – that was so long ago, eh? A two-tiered Internet – as if that would happen. … As if, right?

Internet usage caps and bandwidth throttling are most likely never going to stop being a concern. Debates and resolutions are outside my realm of expertise to comment on.  What I can do however is help people build better responsive sites and save my fellow Internet-lovers some money at the same time.

The Internet is for everyone.

Leave a Comment.