Mobile - - By Annarita Tranfici

Understanding Responsive Web Design: Responsive Imagery

Understanding Responsive Web Design

In this fifth part of our Understanding Responsive Web Design series, I’ll show you one of the typical problems that a web designer faces when building a responsive website: the management of the images. As you’ve seen so far, the challenges that a mobile designer faces are numerous, and it’s not so strange or unusual to think that one of the biggest is serving multiple image formats to multiple screen sizes. There are currently three strategies that a developer can choose when it comes to responsive imagery: he can choose between: “fighting” the browser, “resigning” himself, or relying on the server. Let’s try to understand the advantages and downsides of each option.

Fighting the Browser

Most front-end developers choose to apply the first strategy and fight the browser. What does “fighting the browser” stand for? It means doing your best to give the “right” image (that is, the image that has the correct size for the device used to view the website) to the browser so that it can be loaded before the browser had downloaded the “wrong” one (that is, the “default” or the desktop version of the image). This is an increasingly difficult task, as modern browsers and ever-quickening bandwidth means that users try to download images as quickly as possible.


Sometimes the simplest and most comfortable strategy is the only viable option: admit defeat. Generally, this approach involves loading the default image onto small screens, and secondly, if necessary, loading a larger image for screens with larger dimensions. While this method is easy and straightforward, it’s not recommended, because in the second case, two requests are sent to the browser when only one is necessary.

Relying on the Server

The third strategy involves the use of the server, a server-side programming language and some basic forms of detection to determine which image to load. All of the logic is executed before the browser is able to see and interpret the HTML code. Unfortunately, this strategy has its own flaws: the act of maintaining an ever-growing list of mobile devices and screen sizes would become very complicated and require constant upkeep.

To help you understand better what this technique does and how it can be used, let’s consider an example. In the following example, I’ll show you a few lines of PHP, but don’t worry, you don’t have to me a PHP expert to create responsive images, and you’ll understand the example even if you haven’t worked with PHP before. Let’s assume that you’re creating a page dynamically and that you’re injecting an <img> tag using the following line of code:

echo '<img src="heavy-image.png" />';

As you might already know, mobile connections aren’t nearly as fast as their desktop counterparts. So, to speed up the rendering of your page for mobile devices, you’d like to inject a lightweight version of the image if the user is using… perhaps an iPhone. What you can do server-side is check the user-agent that made the request and—if the device was an iPhone—inject the smaller image. The next snippet demonstrates this technique:

if (strpos($_SERVER['HTTP_USER_AGENT'], 'iPhone') === false) {
  // Not an iPhone
  echo '<img src="heavy-image.png" />;
else {
  // An iPhone
  echo '<img src="light-image.png" />;

As you can see, the method is very easy to implement, however this approach isn’t very reliable because the user-agent information itself isn’t 100% reliable. If the method fails, you could have some glaring problems with your imagery.

Is One Method Better Than The Others?

Obviously, each approach has its own unique advantages and limitations, and it’s unlikely that one single method will be the ideal choice for all of your mobile projects. However, there are some additional techniques and resources that a developer may use to create responsive images. Src

The first option is very fast and simple. It is a service developed by James Pearce that returns the image you choose to load resized to fit your exact needs. Its name is Src, and all you have to do is put the Src URL location of your image as the image’s source.

<img src="" />

The service uses the user agent string of the requesting device to determine the desired image size and resize the image accordingly. By default, the image is scaled to 100% of the width of the screen. Src has a high level of customization; it’s possible to set a specific width or any other parameter. For example, if you want to set the image width to 250 pixels, you have simply to add the size into the URL as follows:

<img src="" />

The service also caches the request, so the image will not be reloaded each time the page is loaded.

Adaptive Images

A similar solution is proposed by Matt Wilcox. It involves determining the size of the screen first, and then creating (and caching) a scaled version of the correct image dimensions. This is an ideal technique to make the images of an existing website responsive. After downloading the code (which you can find at, to make this solution operational and running properly, you need to follow three simple steps:

  1. Add two files, .htaccess and adaptive-images.php, to the root folder;
  2. Create a cache folder and allow write permission;
  3. Add the following line of Javascript code at the beginning of your document:

[sourcecode language=”JavaScript”]<script>document.cookie=’resolution=’+Math.max(screen.width,screen.height)+’; path=/’;</script>[/sourcecode]

Thanks to this one line of code, the screen resolution is captured and stored in a browser cookie. It’s possible to configure multiple options in the file adaptive-images.php, but the primary purpose of the file is setting the variables for the resolutions ($resolutions).

$resolutions = array (800, 480, 320);

These resolutions are the “breakpoints” of images based on the screen resolution (a width to be measured in pixels). In this case, This tool will serve out a small, mobile-friendly image for devices with a pixel width of 320 or smaller. If the display exceeds 320 pixels, the new reference value is 480, which is the next numerical value in the array above.

Once created, the images will be stored in the cache folder (where you can change the filename), so that you will no longer need to generate them.

In addition to what I showed, I want to highlight that the key point of the discussion on adaptive images concerns their size. This is certainly an important factor, but we often forget that it is not the only one. For example, resizing an image for smaller displays often reduces the impact and the recognition of the image. In these cases, it may be necessary to modify the image. Even a simple cropping of the edges or of the superfluous elements can help the image retain it’s impact and significance at a smaller size.


In this article I described three ways to work with with images from a responsive design point of view. The first is fighting the browser—that is, doing your best to give to the browser the “right” image to download. The second is choosing services like which use the user agent string of the device from which the request is sent to understand screen size and resize the image accordingly. The last involves to adaptive images—in this case, the developer only needs to determine the size of the screen and the image will scale to accommodate.

In conclusion, between the three approaches discussed above, the one of the adaptive images is probably the best solution as it requires no dependency to another site or link. In the next articles in the series, we’ll examine other methods that a developer can use to manage all the images of a responsive website.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!