Responsive Images: The Ultimate Guide
As today’s websites and devices become ever more varied, a plethora of responsive images techniques are appearing to serve developers’ needs.
However, responsive design can seem like a minefield. The sheer range of responsive image options on the Web is daunting – and that’s before you get into facing the obstacles specific to the site you’re working on. But have no fear! Below is a basic outline of what responsive images are, how they can affect your work process, and some of the key defining factors that we think should apply to any designer’s thinking, whichever route you choose…
What Are Responsive Images?
Put simply, responsive design is an approach that enables your website to fluidly adjust within the parameters of any device – involving a minimum of scrolling or zooming. In other words, creating great-looking sites which are dynamic and flexible enough to be visually responsive to any screen, from mobile widths right up to desktop format. And to make that possible, you of course need a flexible approach to images. Simple, right?
Well … yes and no. While responsive images are now widely used and fairly easy to use in basic layouts, anyone designing more complicated sites will know that issues can quickly rear their ugly heads. Needless to say there is no one key to fit all locks – so we’ve listed seven of the most common problems below, along with a basic run-through of effective techniques related to each problem, to help you get your site running smoothly.
What Are The Problems?
One major factor in the need for responsive images is overall website size – even today, a huge percentage of mobile-version sites are as large (or even larger) than their desktop versions, thereby affecting performance negatively. Images play a large part in this, as image quality and size in general continues to increase, but it makes little sense if the data is wasted by mobile devices or desktops with low bandwidth connection. So to improve efficiency, more designers now using responsive images – however, these often open up their own cans of worms.
Scaling images down to better fit devices is the most common approach to making content responsive, but in many cases this can make the image less powerful – the ‘art-direction problem’. Other less aesthetic issues, such as processes which either don’t ‘validate’ or aren’t considered strictly semantic, can for some designers (or clients) be a stumbling block. Then there are the technical aspects to consider – server-side components, use of JavaScript, bandwidth testing, and third-party options. All these issues have (more or less) great solutions, so read on to discover which suits you best.
Problem 1 – Semantics
Making responsive images work cleanly and reliably across multiple platforms sometimes involves using techniques that aren’t ‘semantic’. Why? Because when the src of an image points to a real image, with an alt text to describe it, even if the src is the smallest image possible, it means you’re downloading unnecessary data.
To get around this, some of the techniques described below require the src of the image to be removed, or to link to a transparent GIF for example. If this doesn’t suit and you’re looking for a semantic approach, then Adaptive Images by Matt Wilcox, or the HiSRC jQuery plugin by Marc Grabanski and Christopher Schmitt, are two excellent options to look at.
Adaptive Images
If the site you are working on has a large amount of legacy images, it may not be workable to go through and adjust every image with special markup or specialised CSS. In this case, Adaptive Images is arguably the best solution out there. It requires no custom markup for any images and thus enables backwards compatibility by resizing images automatically. However, it does require the Apache 2 Web server and PHP 5.x, which may not be compatible with your site’s platform (more on this later). It also requires that your images be hosted with your Web server, as opposed to elsewhere via a delivery network.
HiSRC
Unlike Adaptive Images, HiSRC does require custom markup in the HTML, and so may not be appropriate in the case of sites with high legacy content. On the other hand, it gives you the freedom to specify custom cropping or zooming of images for smaller platforms (the ‘art-direction problem’ discussed below), as well as enabling the script to pick different image resolutions according to network speed (‘the bandwidth problem’) – neither of which Adaptive Images does. On the downside, HiSRC will only work if you’re using the jQuery library, so if that’s not an option try one of these other solutions.
Problem 2 – Art Direction
A picture tells a thousand words … most of the time. Many responsive image techniques enable you to provide several resolution versions of an image, which can then be used accordingly for suit a given platform. However, this can sometimes have a negative effect where the message of the image is diluted or lost altogether. What’s the minimum size for an image? The answer, of course, depends on context.
Even the most stunning images can lose their power when scaled down to fit the confines of smaller devices such as mobiles. If this predicament applies to your site, you’ll need a solution that addresses the ‘art-direction problem’ by enabling custom cropping and zooming specifications. Both the HiSRC and Picturefill techniques (described below) offer lots of flexibility here, but remember – if your site has a high number of legacy images, you’ll be doing a lot of custom markup, which perhaps isn’t desirable.
Problem 3 – Validity
If you are customising markup, checking markup validity using a validation service such as W3C ensures that a construct follows the correct syntax of whatever language it works with (for example, HTML). While most of the time browsers are able to think ahead to present Web pages that aren’t strictly ‘valid’ without any problems, these results can sometimes vary between one browser and another. In rare cases, it can cause confused layouts or even crashes. ‘Validating’ every page is a bulletproof way of identifying these problems before they occur.
But that’s not to say invalid code can’t work seamlessly across all browsers! In fact it often does. Picturefill by Scott Jehl is loved by many and uses JavaScript for the <picture> element to display responsive images, and it works excellently in spite of being technically invalid syntax. Go ahead with whatever works best for you: if validity is a must, then Adaptive Images or HiSRC may be a better fit.
Problem 4 – Bandwidth Capabilities
Much as we’d all like to say otherwise, a world of super-speed connections and lighting-fast load times for everyone is still some way off. That’s why in many developers’ opinions, responsive images ought to consider the bandwidth available on any given device, and adjust the image size accordingly to cut out excess downloads.
Foresight.js by Adam Bradley is a solution that works as a kind of connection speed checker, by first downloading a 50K test file and then determining which size image suits best: a technique that is also available with HiSRC. The downside of this? The test image means an additional 50K download, and a potentially delayed page load time. However, many consider this preferable to serving up large images that go unused.
Problem 5 – Server Side Components
The bulk of Adaptive Images’ work is done through .htaccess and PHP 5.x, which offers a great solution without complete dependency on JavaScript. The problem with .htaccess is that it assumes your website is running on an Apache server. If you’re using something else, such as Nginx, you can port the .htaccess over to Nginx syntax – which is similar to Apache’s but this still involves some work. Additionally, adding PHP files to your site’s root directory may not be possible if you’re running on other technologies, such as Ruby or Python. Clearly this isn’t ideal for everyone, so be sure to check first before you dive in.
Problem 6 – JavaScript
As you’ve probably noticed, many of the responsive image techniques above require some JavaScript. If you’d prefer to keep things as simple as possible and want to avoid using JavaScript altogether, then take a look at the third-party Sencha.io Src solution discussed a little further down.
JavaScript applies to most of the options listed here. Some only use a tiny bit, while others involve quite a lot of configuration depending on the scale of your project. Even the Adaptive Images technique requires JavaScript, although only a very minimal amount, doing most of its magic through Apache and PHP. Which leads us on to …
Problem 7 – Third Parties
If you prefer to outsource, Sencha.io Src is a completely third-party technique for resizing images to fit any given user. By acting as a proxy for images, it ensures you need never delve into custom configurations on your server – just point the image to Sencha.io, which then uses its user-agent string to detect the parameters of the device, and your image is resized!
There are several other options if you’re taking the third-party route. An alternative to Sencha.io is ReSRT.it, which offers a very similar service but without user-agent detection or cookies. It also allows for bandwidth detection and flexibility to address the art-direction problem, if that applies to your site. Device Atlas Cloud, Responsive.io, and Thumber.io are other options, just to name a few.
Needless to say, third-party dependency is to be treated with caution. While these solutions often work perfectly and are convenient (and free for individual users, in the case of Sencha.io) you always run the risk of unexpected downtime. So it’s best to weigh up the potential consequences before you jump in!
Best Practice Today
Picturefill 2.0 was recently released as beta, and it’s quite a large jump from version 1.
It allows us to use responsive images now and in a way that start to take care of some of the issues discussed above.
Installing and using a polyfill
Polyfills are meant to be set-it-and-forget-it, but because this is an HTML polyfill, you’ll either need to make the picture element manually or use some form of HTML shiv to do it for you.
HTML shivs are pretty ubiquitous and come with toolkits such as Modernizr; just verify that picture is supported in whatever shiv you choose.
<!-- Create the actual picture element if you haven't already. --> <script> document.createElement( "picture" ); </script> <!-- Asynchronously load the polyfill. --> <script src="picturefill.js" async></script>
Apart from creating the picture element, you have to link to the script. Using the async attribute is also recommended, so that Picturefill does not stop your page from loading.
Using PictureFill 2 with srcset
Ok so now we’ll look at the syntax that provides the best support and that uses srcset.
It should look familiar because it has the same attributes that we saw when discussing the specification.
<img sizes="(min-width: 40em) 80vw, 100vw” srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama”>
The main difference between this snippet and the specification is the removal of a fallback src attribute, which was intentionally taken out to prevent images from being downloaded twice in unsupported browsers.
The sizes attribute tells the browser of the image’s size relative to the viewport. This often gets overlooked because srcset is the cool kids choice now, but this attribute is equally important.
Using PictureFill 2 with the picture element
The RICG did such a good job with this second version of Picturefill that the syntax of thepicture element should come as no surprise. It matches the specification very closely:
<picture> <source srcset="extralarge.jpg, extralarge.jpg 2x" media="(min-width: 1000px)"> <source srcset="large.jpg, large.jpg 2x" media="(min-width: 800px)"> <source srcset="medium.jpg"> <img srcset="medium.jpg" alt="Cambodia Map"> </picture>
The biggest change between versions 1.0 and 2.0 is the removal of some traditional HTML (divs and spans) and the addition of newer elements (picture and source). Also, srcset support is built in.
The difference between this and the official picture element is the img fallback. You’ll notice here that the img fallback also has asrcset attribute, instead of a normal src (which is widely supported).
Again, this is to prevent double-downloading. The srcset in the img tag would also cause double-downloading if the browser supports srcset but not picture.
Conclusion
It goes without saying that until a magical one-for-all formula comes along, none of the solutions above will address every possible design eventuality. But that doesn’t mean you can’t create beautiful, responsive content that works like a dream from desktop to mobile. As with most things, the key is to weigh up which problems you most want to solve – be they legacy content, bandwidth, art direction or others – and start from there. Good luck, and as ever we’d love to hear your thoughts and stories about how you’re getting on with responsive images.
