Why I Chose to Optimise Images for Retina Display

Having recently bought a MacBook Pro with Retina Display (these machines are absolutely stunning by the way), it is glaringly obvious that images on the web that aren’t optimised for these types of resolutions simply look awful. They can look quite blurry and I can certainly see how it would be a less than aadequate experience for a user, never mind those of us who have poor eyesight anyway.

Images that are optimised for the Retina Display look amazing. The details are sharp and crisp, and everything looks more vivid.

The recent update for WordPress to version 3.5 has Retina Display optimised graphics, and they look gorgeous. It really brings a whole new aesthetic and experience to the interface.

With that in mind, I’ve decided to include the optimisation of images for the Retina Display and other high resolution displays as a standard part of any new build I do for my clients going forward. Having made this decision, I decided to do some research on the subject.

How to Serve Optimised Images for Retina Display

Serving high resolution images for the Retina Display is made really simple thanks to a small open-source script written in JavaScript called Retina.js. I suggest that you check it out if you are considering optimising for high resolution displays such as Apple’s Retina Display.

You simply include the script in your page and it will detect if a device has a Retina Display, then it will check to see if high resolution versions of your images exist (using Apple’s prescribed high-resolution modifier (@2x)) and simply swap them out. It even includes a CSS mix-in which you can include as part of a LESS stylesheet that will allow you to use media queries to swap out background images with their higher resolution counterparts.

The Problem with Optimising for Retina Display Devices

While conducting research, it really got me thinking about the problem of serving high resolution images to devices that will be using slow internet connections, 3G and below for example. This seemed counter intuitive to me as the images, though now looking fantastic, might make the site frustratingly unusable as they would be larger in file size than the originals, taking longer to download to the client.

In Search of a Solution

With this issue in the forefront of my mind, I set about looking for a way to detect the clients connection speed. At first it looked as though detecting the connection speed of a device would be impossible but I eventually came across a couple of scripts that looked to be a promising start for crafting a solution.

The first script was written in 2006 by Emanuele Feronato using PHP.

<?php
$kb=512;
echo "streaming $kb Kb...<!-";
flush();
$time = explode(" ",microtime());
$start = $time[0] + $time[1];
for($x=0;$x<$kb;$x++){
    echo str_pad('', 1024, '.');
    flush();
}
$time = explode(" ",microtime());
$finish = $time[0] + $time[1];
$deltat = $finish - $start;
echo "-> Test finished in $deltat seconds. Your speed is ". round($kb / $deltat, 3)."Kb/s";
?>

There was a problem with the accuracy of this solution though, as many commenters on the article pointed out. This script was in fact measuring the speed at which the server could send data to the client, only really giving us an indication of the server’s speed. It was however a good starting point.

The second script I found was written by a Dutch web developer named Jan Moesen. Now this script looked a lot more promising.

Again, it didn’t provide an entirely accurate indication of connection speed but it was certainly a lot closer to the mark.

I decided that I would post my thoughts over at the Web Designer Forum to see what my fellow developers thought about it all.

A Possible Plan of Action

Having studied both solutions, and after conducting a little more research I came to the conclusion that a solution to this problem could be developed. I even had an idea of how it might work.

1. Declare a $serverTimestamp variable containing the server time.
2. Use AJAX on the client side to request a specific amount of data in KB, 512KB for example.
3. Once the request had been completed set a new $clientTimestamp variable containing the clientside time.
4. Compare the two variables $serverTimestamp and $clientTimestamp and evaluate the time it took in milliseconds to receive the 512KB of data.
5. Extrapolate the clients connection speed by using the data size, time in milliseconds and an overhead based on the data size (I still needed to work out the exact formula).

Best Laid Plans

With my simple plan of action in place I went about researching some more and came across an article on www.quirksmode.com entitled ‘Measuring Connection Speed in Browsers‘. Wow! This article brought my plans to create a simple and elegant solution crashing down to Earth pretty swiftly. It seemed that there was a hell of a lot more to consider than just connection speed.

When I began writing this article I fully intended to have a working solution by the time I had completed it but instead, I have more questions and a headache.

So, what do you think is the best possible way forward? My thoughts are that until there is full support for browsers (specifically mobile browsers) to provide information on a devices connection speed, it’s possibly a case of letting the user choose between low resolution and high resolution images. Not very elegant I know but it’s the best option I can see for the moment. What do you think?