This chapter is from the book
This chapter is from the book
This chapter is from the book
Responsive image options
There are limitations to every approach to responsive images currently available. To illustrate this, let’s look at a couple different techniques for setting responsive images, and evaluate whether they’re right for the Yet Another Sports Site page.
Sencha.io Src
Sencha.io Src is as close as you’re going to get to a plug-and-play solution for responsive images. The service, originally created by James Pearce, takes an image that you pass and returns it resized. To use it, you simply preface your image source with the Sencha.io Src address like so:
http://src.sencha.io/http://mysite.com/images/football.jpg
Sencha.io Src uses the user agent string of the device making the request to figure out what size the device is and then resizes your image accordingly. By default, it resizes the image to 100% of the screen width (though it will never size up).
A great deal of customization is possible. For instance, if you want the service to resize your image to a specific width, you can pass that along as another parameter. For example, the following line of code resizes the image to 320px wide:
http://src.sencha.io/320/http://mysite.com/images/football.jpg
Sencha.io Src is also smart enough to cache the requests, so the image isn’t generated each and every time the page loads.
Unfortunately, this probably isn’t the best solution for Yet Another Sports Site. Sizing the images to 100% of the screen size only helps on small screens. On a large display, when the article spans two columns, the image remains its original size because Sencha.io Src looks at the screen width, not the width of the containing element. While it’s possible to tell Sencha.io Src to use that width, it involves using the service’s experimental client-side measurements feature and doing a bit of JavaScript hackery.
While the current version of the page doesn’t run into the issue, Sencha.io Src is also limiting if you want to do more than just resize an image, for instance, if you want to recrop the image. Perhaps the “More in Football” images could become square thumbnails at some point. If they did, a simple resize wouldn’t work. Some art direction capability is needed, and Sencha.io Src doesn’t allow for that.
You might also be a bit uncomfortable using a third-party solution for this. If the company changes its policy or goes out of business, you could very well be out in the cold and looking for another solution entirely.
Adaptive Images
Another solution bordering on plug-and-play is Adaptive Images, created by Matt Wilcox. It determines the screen size and then creates, and caches, a resized version of your image.
It’s an excellent solution for an existing site where you may not have time to restructure your markup or code. Getting it up and running is a simple three-step process:
- Place the .htaccess and adaptive-images.php files that are included in the download into your root folder.
- Create an ai-cache folder and grant it write permissions.
- Add the following line of JavaScript to the head of your document:
<script>document.cookie='resolution='+Math.max(screen.width, screen.height)+'; path=/';</script>
That line grabs the resolution of the screen and stores it in a cookie for future reference.
While there are many options you can configure in the adaptive-images.php, much of the time you’ll be able to get away with just setting the $resolutions variable to include your breakpoints:
$resolutions = array(860, 600, 320); // the resolution breakpoints to use (screen widths, in pixels)
If you’re paying close attention, you’ll notice that the breakpoints are slightly off from the CSS of the Yet Another Sports Site page. There’s no 320px breakpoint in the CSS, and the highest two breakpoints, 1300px and 940px, are not included in the $resolutions array. This is because of the way the script works.
The smallest breakpoint, in this case 320px, is the size at which the image will be created for any screen that does not exceed that width. So, for example, a 300px screen will receive a 320px image because it’s the lowest size defined in the $resolutions array. A 321px screen, since it exceeds the 320px value defined in the array, will receive the next size image—in this case, 600px. If we left 600px as our first breakpoint, any device with a screen size below 600px would have received a 600px image.
We also don’t need the two highest breakpoints, because again, the script will try to resize an image to the breakpoint size. It will never size the image larger than it already is, so really, anything above 624px (the physical dimension of the image) doesn’t matter much—the script won’t resize the image.
Once created, the images are stored in the ai-cache folder (you can change the name) so they don’t have to be regenerated. There’s also a configuration setting to control how long the browser should cache the image.
The installation is simple, and again, it’s a great solution for existing sites that need to get something in place, but it’s not without its faults. Unfortunately, no opportunity for art direction exists since the images are dynamically resized.
Art direction and responsive images
Much of the conversation about responsive images revolves around file size. While that’s an important consideration, it isn’t the only one. Sometimes, resizing an image for smaller screens can reduce its impact.
Consider this example photo of a football helmet.
)
The photo looks nice at its original size, and is well balanced. If we make the image smaller, suddenly the helmet is almost too small to be recognized.
This is an instance where art direction is necessary. Resizing the image alone causes it to lose its impact and recognizability. By tightening the crop instead, we keep the focus on the helmet despite the small image size.
The script also doesn’t help you if the image is actually smaller at a large resolution. For the Yet Another Sports Site page, that’s a problem. When the screen is above 1300px, the article goes to two columns and the image is placed inside one of them, reducing its size. Using the Adaptive Images script, the largest version of the image will still be downloaded.
The other concern with this approach is that the URL stays the same, regardless of the size of the image being requested. This could cause issues with Content Delivery Networks (CDNs). The first time a URL is requested, the CDN may cache it to improve the speed the next time that same resource is requested. If multiple requests for the same URL are made via the same CDN, the CDN may serve up the cached image, which may not be the size you actually want served.
Wait, what’s the answer here?
Ultimately, no definitive solution currently exists for responsive images. Each method has advantages and disadvantages. The approach you take will depend on the project you’re working on.
Of the two approaches we’ve discussed, settling on Adaptive Images is probably the best route to take since it doesn’t require any reliance on a third-party source.