Here’s a quick overview of our strategy for delivering images into a responsive web page. I didn’t want to add to the debate on responsive images, as its already a well documented topic, but recent industry chatter means we need to clarify our position.
In his Responsive Day Out presentation, Paul Robert Lloyd spoke about the use of images on the responsive BBC News website. He said (and please correct me if I misinterpreted this Paul), while referring to the homepage: that the “first image is important enough to be in the markup”, and that “… all other images are considered enhancements. If not there, the experience is not degraded at all.”
The semantic importance ascribed by Paul to images added directly into the page is not quite correct. Yes the first image is in the markup and will be loaded by “HTML4” and “HTML5” browsers (click here for a definition of both), but this is more a technical consideration than an editorial one.
Our responsive images process
There are two steps to adding responsive images to a page:
- Creating multiple versions of the same image at different resolutions
- Deciding which image to use at run time
As the BBC News site publishes MANY articles everyday, many images are published too. BBC News has an automated process to create 18 different versions of each published image.
When a journalist publishes an article via our CMS to the live site, any images associated with it are also published to a live URL. The link from the article to the image is modified by our PHP application layer, it adds a resolution size into the URL. The URL is changed from…
This new URL points to our image resize service that we call “Image Chef”. Image Chef sits between our website and the static image server, creating new versions of the original image based on instructions that we set for each image resolution size.
On each of our webpages there are two elements that are relevent to our responsive image solution. We have the image that is double loaded at the top of each page:
<img src="http://ichef.bbci.co.uk/news/235/media/images/67431000/jpg/_67431205_firing.jpg" class="image-replace" alt="image" />
And there are divs with the class “delayed-image-load”:
Issues with responsive images
There are a few notes to make about this. A great post by Jason Grigsby proposes using a break point rationale based on file size. In the comments there is a discussion about choosing which version of the image to download based on element size versus viewport size.
At the moment making the choice based on element size is the best fit for us, as element widths do not correlate to viewport widths. We use images in many different contexts, stretched across columns, left aligned, etc, so we have to use element width. We do use a grid, so maybe in the future there will be a clever way to match the element width to the viewport width using a grid system.
Jvaux from Facebook states in the comments that scaling images is also a problem, especially when the page scrolls. We definitely worry about processing time as well as download time. This would suggest the process of using an image that best fits the width of the element has a better effect on DOM reflow rather than scaling images up or down.