Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

One Solution To Responsive Images

Responsive images have been, and are, one of the hardest problems in responsive Web design right now. Until browser vendors have a native solution, we have to think on the fly and come up with our own solutions. “Retina” images are especially a challenge because if you have sized your layout with ems or percentages (as you should!), then you cannot be sure of the exact pixel dimensions of each image being displayed.

In this article, we’ll look at one solution to the problem that we implemented on our portfolio website at Etch1, where you can see an early working version in the wild.

Further Reading on SmashingMag: Link

Requirements For Responsive Images Link

We used a content-first6 approach on Etch. We knew we wanted to use a lot of images to quickly convey the atmosphere of the company. These would be accompanied by small snippets, or “soundbites,” of text.

The next decision was on image sizes and aspect ratios. To get maximum control over the design, we knew we needed maximum control over the images. We decided to use Instagram as the base for our imagery for the following reasons:

  • The aspect ratio is fixed.
  • Most employees here already use it.
  • Those lovely filters.

Instagram allows for a maximum image size of 600 pixels, so we now had our first set of content constraints to work with: images with a 1:1 aspect ratio, and a maximum image size of 600 × 600. Having constraints on the content side made the design process easier because they limited our options, thus forcing decisions.

When the content was completed, we began looking at the design. Again, to keep maximum control, we decided on an adaptive design style with fixed column sizes. We used grid block elements that match our maximum image size. Each grid block would either be 600 × 600 or 300 × 300, which also conveniently fit our rough plan of a minimum width of 320 pixels for the viewport on the website.

During the rest of the design process, we noticed that we needed two other image sizes: thumbnails at 100 × 100, and hero images that stretch the full width of the content (300, 600, 900, 1200, 1600, 1800). All images would also need to be “Retina” ready — or, to put it another way, compatible with displays with high pixel densities. This gave us the final set of requirements for a responsive images solution for the website:

  • Potential image widths (in pixels) of 100, 300, 600, 900, 1200, 1600, 1800
  • Retina ready
  • Must be crisp with minimal resizing (some people notice a drop in quality with even downsized images)

Having to resize that many images manually, even using a Photoshop script, seemed like too much work. Anything like that should be automated, so that you can focus on fun and interesting coding instead. Automation also removes the chance for human error, like forgetting to do it. The ideal solution would be for us to add an image file once and forget about it.

Common Solutions Link

Before going over our solution, let’s look at some common solutions currently being used. To keep up with currently popular methods and the work that the Web community is doing to find a solution to responsive images, head over to the W3C Responsive Images Community Group7.

Picture Element Link

First up, the picture8 element. While this doesn’t currently have native support and browser vendors are still deciding on picture versus srcset versus whatever else is up for discussion, we can use it with a polyfill.

<picture alt="description">
  <source src="small.jpg">
  <source src="medium.jpg" media="(min-width: 40em)">
  <source src="large.jpg" media="(min-width: 80em)">

The picture element is great if you want to serve images with a different shape, focal point or other feature beyond just resizing. However, you’ll have to presize all of the different images to be ready to go straight in the HTML. This solution also couples HTML with media queries, and we know that coupling CSS to HTML is bad for maintenance. This solution also doesn’t cover high-definition displays

For this project, the picture element required too much configuration and manual creation and storage of the different image sizes and their file paths.

srcset Link

Another popular solution, srcset, has recently been made available natively in some WebKit-based browsers. At the time of creating our plugin, this wasn’t available, and it looks like we’ll be waiting a while longer until cross-browser compatibility is good enough to use it without a JavaScript fallback. At the time of writing, srcset is usable only in the Chrome and Safari nightly builds.

<img src="fallback.jpg" srcset="small.jpg 640w 1x, small-hd.jpg 640w 2x, large.jpg 1x, large-hd.jpg 2x" alt="…">

The snippet above shows srcset in use. Again, we see what essentially amounts to media queries embedded in HTML, which really bugs me. We’d also need to create different image sizes before runtime, which means either setting up a script or manually doing it, a tiresome job.

Server-Side Sniffing Link

If you’d rather not use JavaScript to decide which image to serve, you could try sniffing out the user agent server-side and automatically send an appropriately sized image. As a blanket rule, we almost always say don’t rely on server-side sniffing. It’s very unreliable, and many browsers contain inaccurate UA strings. On top of that, the sheer number of new devices and screen sizes coming out every month will lead you to maintenance hell.

Other Solutions in the Wild Link

We chose to make our own plugin because including layout code in the HTML seemed undesirable and having to create different image sizes beforehand was not enticing.

If you’d like to explore other common solutions to decide which is best for your project, several great articles and examples are available on the Web, including one on this very website.

  • Choosing a Responsive Image Solution9,” Sherri Alexander, Smashing Magazine
    Alexander looks at the high-level requirements for responsive images, and then dissects the variety of solutions currently available in the wild.
  • Which Responsive Image Solution Should You Use10,” Chris Coyier, CSS-Tricks
    Coyer takes us through imaging requirements while suggesting appropriate solutions.
  • Adaptive Images11
    A solution very similar to Etch’s in its implementation. It uses a PHP script to size and serve the appropriate images. Unfortunately, this wasn’t available when we were coding the website.
  • Picturefill12
    This is a JavaScript replacement for markup in the style of the picture element.
  • Responsive Images Using Cookies13,” Keith Clark
    Clark uses a cookie to store the screen’s size, and then images are requested via a PHP script. Again, it’s similar to our solution but wasn’t available at the time.

Onto our solution.

Our Solution Link

With both picture and srcset HTML syntaxes seeming like too much effort in the wrong places, we looked for a simpler solution. We wanted to be able to add a single image path and let the CSS, JavaScript and PHP deal with serving the correct image — instead of the HTML, which should simply have the correct information in place.

At the time of developing the website, no obvious solution matched our requirements. Most centered on emulating picture or srcset, which we had already determined weren’t right for our needs.

The Etch website is very image-heavy, which would make manually resizing each image a lengthy process and prone to human error. Even running an automated Photoshop script was deemed to require too much maintenance.

Our solution was to find the display width of the image with JavaScript at page-loading time, and then pass the src and width to a PHP script, which would resize and cache the images on the fly before inserting them back into the DOM.

We’ll look at an abstracted example of the code, written in HTML, JavaScript, PHP and LESS. You can find a working demo14 on my website. If you’d like to grab the files for the demo, they can be found on GitHub15.

Markup Link

The markup for the demo can be found in the index.html file on GitHub16.

We wrap the highest-resolution version of an image in noscript tags, for browsers with JavaScript turned off. The reason is that, if we think of performance as a feature and JavaScript as an enhancement, then non-JavaScript users would still receive the content, just not an optimized experience of that content. These noscript elements are then wrapped in a div element, with the image’s src and alt properties as data attributes. This provides the information that the JavaScript needs to send to the server.

<div data-src="img/screen.JPG" data-alt="crispy" class="img-wrap js-crispy">
    <noscript><img src="img/screen.JPG" alt="Crispy"></noscript>

The background of the image wrapper is set as a loading GIF, to show that the images are still loading and not just broken.

An alternative (which we used in one of our side projects, PhoSho17) is to use the lowest-resolution size of the image that you will be displaying (if known), instead of the loading GIF. This takes slightly more bandwidth because more than one image is being loaded, but it has an appearance similar to that of progressive JPEGs as the page is loading. As always, see what your requirements dictate.

responsive images18
(Large preview19)

JavaScript Link

The JavaScript communicates for us between the HTML and the server. It fetches an array of images from the DOM, with their corresponding widths, and retrieves the appropriate cached image file from the server.

Our original plugin sent one request to the server per image, but this caused a lot of extra requests. By bundling our images together as an array, we cut down the requests and kept the server happy.

You can find the JavaScript plugin20 in /js/resize.js in the GitHub repository.

First, we set an array of breakpoints in the plugin that are the same as the breakpoints in the CSS where the image sizes change. We used em values for the breakpoints because they are based on the display font size. This is a good practice because visually impaired users might change their display’s default font size. This also makes it easier to match our CSS breakpoints with the JavaScript ones. If you prefer, the plugin works just fine with pixel-based breakpoints.

breakpoints: [

As we pass each of these breakpoints, we need to check the images to make sure they are the correct size. At page-loading time, we first set the current breakpoint being displayed to the user using the JavaScript matchMedia function. If you need to support old browsers (Internet Explorer 7, 8 and 9), you might require the matchMedia polyfill21 by Paul Irish.

getCurrentBreakpoint: function() {
      var bp, breakpoint, _fn, _i, _len, _ref,
        _this = this;

      bp = this.breakpoints[0];
      _ref = this.breakpoints;
      _fn = function(breakpoint) {
        // Check if the breakpoint passes
        if (window.matchMedia && window.matchMedia("all and (min-width: " + breakpoint + ")").matches) {
          return bp = breakpoint;
      for (_i = 0, _len = _ref.length; _i < _len; _i++) {
        breakpoint = _ref[_i];
      return bp;

After setting the current breakpoint, we gather the images to be resized from the DOM by looping through them and adding them to the plugin’s images array.

gather: function() {
      var el, els, _i, _len;

      els = $(this.els);
      this.images = [];
      for (_i = 0, _len = els.length; _i < _len; _i++) {
        el = els[_i];

The PHP script on the server needs the image’s src and current width in order to resize it correctly, so we created some serialized POST data to send to the server. We use jQuery’s param method to quickly convert the image into a usable query string.

buildQuery: function() {
      var image = { image: this.images }
      return $.param(image);

The images are then sent via an AJAX request to the server to be resized. Note the single request, to minimize server load.

grabFromServer: function() {
      var data,
        _this = this;

      data = this.buildQuery();
      $.get("resize.php", data, function(data) {
          var image, _i, _len;
          for (_i = 0, _len = data.length; _i < _len; _i++) {
            image = data[_i];

Once we have retrieved the images from the server, we can add them to the DOM or replace the image already in place if it has changed. If it’s the same image, then nothing happens and the image won’t need to be redownloaded because it’s already in the browser’s cache.

loadImage: function(image) {
      var el, img,
        _this = this;

      el = $("[data-src='" + image.og_src + "']");
      img = $("");
      img.attr("src", image.src).attr("alt", el.attr("data-alt"));
      if (el.children("img").length) {
        el.children("img").attr("src", image.src);
      } else {
        img.load(function() {

PHP Link

With the JavaScript simply requesting an array of images at different sizes, the PHP is where the bulk of the action happens.

We use two scripts. One is a resize class22 (found in /php/lib/resize-class.php in the demo), which creates cached versions of the image at the sizes we need. The other script23 sits in the Web root, calculates the most appropriate size to display, and acts as an interface between the JavaScript and the resizer.

Starting with the sizing and interface script, we first set an array of pixel sizes of the images that we expect to display, as well as the path to the cached images folder. The image sizes are in pixels because the server doesn’t know anything about the user’s current text-zoom level, only what the physical image sizes being served are.

$sizes = array(

$cache = 'img/cache/';

Next, we create a small function that returns the image size closest to the current display size.

function closest($search, $arr) {
    $closest = null;
    foreach($arr as $item) {
        // distance from image width -> current closest entry is greater than distance from  
        if ($closest == null || abs($search - $closest) > abs($item - $search)) {
            $closest = $item;
    $closest = ($closest == null) ? $closest = $search : $closest;
    return $closest;

Finally, we can loop through the image paths posted to the script and pass them to the resize class to get the path to the cached image file (and create that file, if necessary).

$crispy = new resize($image,$width,$cache);
$newSrc = $crispy->resizeImage();

We return the original image path in order to find the image again in the DOM and the path to the correctly sized cached image file. All of the image paths are sent back as an array so that we can loop through them and add them to the HTML.

$images[] =  array('og_src' => $src, 'src' => '/'.$newSrc);

In the resize class, we initially need to gather some information about the image for the resizing process. We use Exif to determine the type of image because the file could possibly have an incorrect extension or no extension at all.

function __construct($fileName, $width, $cache) {

    $this->src = $fileName;
    $this->newWidth = $width;
    $this->cache = $cache;
    $this->path = $this->setPath($width);

    $this->imageType = exif_imagetype($fileName);

        case IMAGETYPE_JPEG:
            $this->path .= '.jpg';

        case IMAGETYPE_GIF:
            $this->path .= '.gif';

        case IMAGETYPE_PNG:
            $this->path .= '.png';

            // *** Not recognized

The $this->path property above, containing the cached image path, is set using a combination of the display width, a hash of the file’s last modified time and src, and the original file name.

Upon calling the resizeImage method, we check to see whether the path set in $this->path already exists and, if so, we just return the cached file path.

If the file does not exist, then we open the image with GD to be resized.

Once it’s ready for use, we calculate the width-to-height ratio of the original image and use that to give us the height of the cached image after having been resized to the required width.

if ($this->image) {
    $this->width  = imagesx($this->image);
    $this->height = imagesy($this->image);

$ratio = $this->height/$this->width;
$newHeight = $this->newWidth*$ratio;

Then, with GD, we resize the original image to the new dimensions and return the path of the cached image file to the interface script.

$this->imageResized = imagecreatetruecolor($this->newWidth, $newHeight);
imagecopyresampled($this->imageResized, $this->image, 0, 0, 0, 0, $this->newWidth, $newHeight, $this->width, $this->height);


return $this->path;

What Have We Achieved? Link

This plugin enables us to have one single batch of images for the website. We don’t have to think about how to resize images because the process is automated. This makes maintenance and updates much easier, and it removes a layer of thinking that is better devoted to more important tasks. Plug it in once and forget about it.

TL;DR? Let’s summarize the functionality once more for good measure.

In our markup, we provide an image wrapper that contains a <noscript> fallback. This wrapper has a data attribute of our original high-resolution image for a reference. We use JavaScript to send an AJAX request to a PHP file on the server, asking for the correctly sized version of this image. The PHP file either resizes the image and delivers the path of the correctly sized image or just returns the path if the image has already been created. Once the AJAX request has been completed, we append the new image to the DOM, or we just update the src if one has already been added. If the user resizes their browser, then we check again to see whether a better image size should be used.

Pros And Cons Link

All responsive image solutions have their pros and cons, and you should investigate several before choosing one for your project. Ours happens to work for our very specific set of requirements, and it wouldn’t be our default solution. As far as we can tell, there is no default solution at the moment, so we’d recommend trying out as many as possible.

How does this solution weigh up?

Pros Link

  • Fast initial page download due to lower image weight
  • Easy to use once set up
  • Low maintenance
  • Fast once cached files have been created
  • Serves image at correct pixel size (within tolerance)
  • Serves new image when display size changes (within tolerance)

Cons Link

  • Unable to choose image focus area
  • Requires PHP and JavaScript for full functionality
  • Can’t cover all possible image sizes if fluid images are used
  • Might not be compatible with some content management systems
  • Resizing all images with one request means that, with an empty cache, you have to wait for all to be resized, rather than just one image
  • The PHP script is tied to breakpoints, so it can’t be dropped in without tweaking

Responsive image solutions have come a long way in recent months, and if we had to do this again, we’d probably look at something like the adaptive images24 solution because it removes even more non-semantic HTML from the page by modifying .htaccess.

Wrapping Up Link

Until we have a native solution for responsive images, there will be no “right” way. Always investigate several options before settling on one for your project. The example here works well for websites with a few common display sizes for images across breakpoints, but it is by no means the definitive solution. Until then, why not have a go at creating your own solution, or play around with this one on GitHub25?

(al, il)

SmashingMag front page image credits: PhoSho’s front page showcase26.

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26

↑ Back to top Tweet itShare on Facebook

Gavyn McKenzie likes downhill skateboarding, pondering semantics, painting with CSS and fine gastronomy. He is currently employed as a front-end web developer at Etch Apps and dabbles in freelance work for interesting clients.

  1. 1

    This solution is just brilliant. Not perfect for all possible cases, but for your set of requirements (which happens to be a very common set), it solves the problem. Thanks for sharing this.

  2. 2

    I’ve developed a configurable responsive lazyload plugin for this problem –

    LanguidLoad.js –

    It’s designed for responsive, mobile first development environments. Caveats – it’s a jQuery plugin at present, but I’ll get round to paring it back to native when I can find some time.

    • 3

      Gavyn McKenzie

      February 4, 2014 2:36 am

      Awesome solution! I meant to add lazy load on scroll to ours like you have at some point. Great work!

    • 4

      I’ve found many such plugins. Ended up using this one, which looks a lot like yours, but it’s probably already much more mature and thus it sure has a simpler implementation process: and since it’s on github, it automagically has a cdn. :)

  3. 5

    I created a similar solution, except I use a JS first to check the dimensions of the placeholder where the image is to be loaded, and also check pixel density of the device. Then the JS can simply inject an image src with size that is appropriate for the given placeholder area, regardless of layout, breakpoints and density …

  4. 6

    I have yet to see a responsive website that has nice textures and looks as good as a “pixel-defined” site. I have been trying to find one, but can’t. And whenever I post a question on a blog post like this no one else can find one either.
    All responsive sites look the same… square and flat and boring.

  5. 7

    Pure awesomeness!!!

  6. 8

    “This is a great solution, and Imma let you finish, but the “Adaptive Images” solution is the greatest image solution of all time…” Kanye West, 2014

  7. 9

    Is there really a good reason why responsive image solutions should force images to be displayed using one aspect ratio?

    Doesn’t that limit the way browsers can arrange the appearance of on-page images!? The very thing responsive solutions are trying to break from. For that to work, there would be control over the images pre-rendered to the browser and thus takes away responsive image rendering, leaving us with what we had before … one img tag per image that can be scaled (if needed) in a responsive (if needed) layout. Or am I missing something?

    • 10

      Gavyn McKenzie

      February 4, 2014 2:34 am

      Hi Steven,

      Indeed, if you already know you want to change aspect ratios then you’d be better off using a solution like srcset or picturefill. We started with the images before we knew the site layout (content first!) so just worked the code around the images rather than the other way around.


  8. 11

    You should have a look at this solution, yet another solution for responsive images ;)

  9. 12

    Creation Date ETCHAPPS.COM: 2012/06/01

    Release version 1.5.2 (latest version): 2012/04/16

    How can you seriously suggest adaptive-images wasn’t available when you started This appears to be a case of lack of research combined with urge to reinvent the wheel.

    • 13

      Gavyn McKenzie

      February 4, 2014 2:27 am

      Hey Tim,

      Adaptive images didn’t quite fit our set of requirements, and as you say I don’t think I could find it at the time of writing the Etchapps site.
      The adaptive images solution only allows you to specify one resolution per screen size. We needed anything from 1500px wide to 100px wide to be served on the same page. With such an image heavy site, every byte counts so we wanted something tailored to each individual images display size.

      Do give me a shout if you’d like to discuss further,

  10. 14

    Wow – a lot of work went into this article. Thank you for another angle on responsive images, and thank you for the GitHub repo to play with!

  11. 15

    For anyone reading this comment: Do yourself a favor and use something like Picturefill instead. It’s simple and will be easily replaceable once the picture element gains adoption.

    • 16

      Gavyn McKenzie

      February 4, 2014 2:32 am

      Hi Evan,

      Picturefill does indeed look like a great solution if you have your image paths predefined and the sizes you’d like to serve them at.
      Something about adding media queries in your HTML (when that seems like the work of CSS) erks me though. I like to try and keep the HTML design agnostic where possible for easier re-branding later.


  12. 17

    what is a high resolutiton for, if the pictures are in this boring instagram stile? It is for nothing to share picts in this style in a real resolutuion.

  13. 18

    Krzysztof Karski

    February 3, 2014 10:59 pm

    If anyone would like to use, essentially, the very same solution as Gavyn presents here for their own website right now, there is Pixtulate ( We also provide a javascript to perform the size detection for scaling images to any dimension you want, including device pixel ratio detection. You can choose between scaling images or cropping and take art direction into consideration using focal points.

  14. 19

    You forgot a “con” – the unnecessary strain on your server when converting the images.

    If you already know the set sizes then it’s much easier to (if you’re lazy) watch a folder for new uploads (your source images) and resize the images to your set sizes. You can then eliminate the entire request stream and do the rest with pure javascript.

    You’re only using PHP to resize and serve the image to the closest size – that size is already known by Javascript (the browser) and you can easily work out what’s closest to it and if you already have the image pre-rendered by PHP at upload time then it’s a matter of swapping the sources over.

    • 20

      Gavyn McKenzie

      February 4, 2014 2:29 am

      Hi Alex,

      That is indeed true, the first load can be pretty harsh on the server. Luckily, once we’ve created the images they are stored in a cache folder so they are only ever resized once with GD. After that, the PHP just checks for the existence of the cached image and serves that instead. By the time we’ve finished testing a release, everything’s already cached and ready to go :)


  15. 21

    Jason Derifaj

    February 4, 2014 3:01 am

    You lost me at PHP

  16. 22

    Erick Boileau

    February 4, 2014 4:15 am

    height: auto
    width: 15vw ;

    and that’s it ! ….

  17. 23

    Thanks, good read,

    I don’t really find anything bad about srcset especially if running a content managed platform, then it’s just a case of generating library of image sizes for srcset to use on upload for example.

  18. 24

    Great and thorough article, really appreciate the effort that’s been put into it. Really makes a lot of sense given the setup of your site. Up until this point I have been wrangling with the element and picturefill however given progress(!) from the vendors all this extra markup is starting to feel a little unnecessary.

  19. 25

    Chris Markham

    February 4, 2014 7:43 am

    I’m looking for a solution where our clients can use a CMS like Joomla or WP to add an image to a page without having to add extra attributes onto img tags, yet still be responsive. Any suggestions?

    • 26

      Gavyn McKenzie

      February 5, 2014 2:33 am

      In a situation like that, I’d be looking at the solution I think.

  20. 27

    I’ve been creating HTML/CSS templates for years now and I STILL don’t understand the need for defining font-sizes/layouts in ems, rems, or percentages (like the author says “as you should!”). The only reason I have been told is that IE8 and IE9 don’t support zoom-functionality when font-sizes are defined in px – but even that works (when using IE10 and setting IE8 mode). And even if it would not work, what is the big deal? If someone needs this zoom-function, just use another browser.
    So can someone please explain me, why to use ems/rems/percentage in font-sizes/layouts and thereby creating a lot of problems like the one that is described in this page? I think it is much more easier to just use pixel and let the browser do the rest (zoom, whatever). Don’t you agree?

    • 28

      Yeah, I was thinking the same when I read “as you should”. I think that neither is better, it depends on the site you are trying to create. In some cases em/rem/percentages are really great, but in others px are better. My responsive sites usually are easier to create, maintain and keep style with px. Sometimes I need to use percentages and ems, sometimes I need a mixture of both ems and pixels, and that’s just fine.

    • 29

      Ever build a responsive website using pixels? ;)

    • 30

      Gavyn McKenzie

      February 5, 2014 2:32 am

      Hi Flummi,

      This was the article that got me converted:

      To summarise: Using ems for fonts/MQs mean that when a user zooms on desktop, the layout changes to accommodate. Large font size shows mobile view so you don’t get the same layout issues as when using pixels. Everything just works.


      • 31

        Thanks Gav for the link. I have found another one that has some good points in it:

        When you scroll to the Block “The Opinion” there are really good reasons to use pixels. The author josh3736 mentions for example:

        “Modern browsers (and even the not-so-modern IE7) all changed the default scaling method to simply zooming in on everything, including images and box sizes. Essentially, they make the reference pixel larger or smaller.
        One other potential problem of using only relative units for font sizes is that user-resized fonts may break assumptions your layout makes. For example, this might lead to text getting clipped or running too long. If you use absolute units, you don’t have to worry about unexpected font sizes from breaking your layout.”

        I think these are strong arguments for px – how do you think about it?

  21. 32

    Great article, but you are missing one “con”: in your solution, you’re basically disabling the standard ability of web browsers to do look-ahead parsing, which start image downloads even before the page is fully downloaded and parsed. That means that images will appear later compared to alternative solutions.

    That may not be an issue in your case, but it’s definitely a con.

  22. 33

    Aamir Shahzad

    February 5, 2014 9:30 pm

    Awesome learning article for everyone who is worried about what to do with responsive images.

  23. 34

    Henk C. Meerhof

    February 9, 2014 4:11 pm

    I still find measurements used in webdesign very disturbing! In international conventions is made a deal to call the unit of measurement a meter, the exact measurement is kept in Paris for those who want to calibrate their instruments.

    ‘if you have sized your layout with ems or percentages (as you should!)’
    ( from the intro of this article )

    An em is a typographic measurement relative to the chosen font size in (still most of the time) Pica points, where we should have converted to mm long ago.

    A percent is also a relative measurement, so without something to relate too, it is of no value.

    I understand very well the problem with getting visual information, specially photographic images, as quick as possible to many different devices. This if possible in the highest quality, but not higher than the device that is receiving the information/image.
    In developing a fitting solution, we need a visionary approach. independent from Device, OS or browser.
    With so many clever people, we humans should be able to do that. Designing a system that is independent and need only one original, to build a fitted image from it before sending the information to the requesting device.
    This removes the need for developing one ‘new wheel’ after the other and it offers the possibility for low(er) resolution devices to ‘zoom in’ on the image until the original resolution is reached.

    Unless someone has the key to digitize images without a resolution (without pixels).

  24. 35

    Nice article. Thought I would replace the $.get on resize.php by
    combining an .htaccess rewrite rule and setting the image.src to ‘Image-widthxheight’ provided that you are on a LAMP stack. It would be even more useful if you have a Varnish server in front of your web server.

  25. 36

    Really superb..!!! i lov it..

  26. 37

    Nowadays non-JavaScript-enabled browsers are mostly those on feature phones which have very small screens – take my former phone for an example, 240px wide – and they want small images which could help their users save money.

  27. 38

    Bernard Bierenbroodspot

    February 17, 2014 3:42 am

    That’s quite an intriguing, intricate solution. But it also feels somewhat hard to maintain. If anything, it proves that responsive retina images are still a huge problem for current day webdevelopers. It should be enough to just include a @2x image and be done with it.

  28. 39

    I made a solution (which i think is cool) (code itself is on github as well) which has feature to: have real image, have container only and lazy load, It is using the image ratio to not simply reflow the page and using the srcset data attribute to give the available options based on width/height/density. Our client application stores enough metadata to have the available images per component. The solution API can handle to clean your view (when having SPA) as well. Now it is written as an AMD module leaning on jQuery but maybe i will write native one as well. Maybe if you have some time check it out.

  29. 40

    just another awesome solution to the ever increasing problem of image weight and loadability. What I do, and I have yet to see this referenced in any article, is use images as background elements, switching out the image in the media query for the device size (set by my breakpoints) … this does several things – gives me more control over the image used (phone vs tablet vs desktop), preloads all images via the css file, and switches out the image based on the viewport. No problems ever reported or logged, and clients are extremely happy. Thanks for demonstrating another way …

  30. 41

    Luca Passani

    June 23, 2014 3:00 pm

    Nice overview, but the author dismisses server-side image optimization a bit quickly:

    “As a blanket rule, we almost always say don’t rely on server-side sniffing. It’s very unreliable, and many browsers contain inaccurate UA strings. On top of that, the sheer number of new devices and screen sizes coming out every month will lead you to maintenance hell.”

    My company recently launched a free and highly-available service that effectively addresses the problem. It is called WIT (WURFL Image Tailor) and can be found here:

    As far as “maintaining the sheer power of devices” goes, we have fully fledged WURFL behind the scenes, so the issue of accurate device detection is handled on behalf of the developer.


  31. 42

    Great idea ! Awesome Solution!
    Thanks for providing this post.
    May I translate this post in Chinese and share in my private Website (not business) ?

  32. 43

    Hi there,
    I had a very headache problem with all of the image in my website.
    Do you think I can use this method to my project?
    you can see the site,
    Especially this link:
    This is a very big image I tried to upload but the result it displayed is like a very small resolution of image and tried to be resized to the larger one.
    Any advise for me?

  33. 44

    I like this solution – but what about server load? What if just 10 users try to see webpage with just 10 images on their retinas? Sounds a bit like DDoS attack to me. What if there is more simultaneous users?

  34. 45

    What about resources? Using http server and php to serve an image?


↑ Back to top