Images
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.
November 2015 update: This blogpost was written over 2 years ago. A native implementation for responsive images is now available. We highly recommend that you look at these native implementations rather than this custom JavaScript solution.
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.”
I think Paul misinterpreted the importance given to the first image in the page, because it was in the markup by default, its meaning was more important than the other images in the page (which we add using JavaScript). We do this with other types of content, anything that we consider to be secondary info is linked to with hyperlinks and replaced with the content of the linked to document via JavaScript. We call this approach transclusion.
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.
Although the rest of the images are loaded via JavaScript, we don’t consider them to have any less semantic importance over the first image. We load in images via JavaScript so users don’t load two different resolutions of the same image. Unfortunately, because “HTML4” browsers are not presented with JavaScript, they won’t see any images. Our editorial colleagues weren’t happy with this, so we compromised with them and agreed to add one image per page into the markup that all users would get regardless of their browser.
You can see it for yourself, disable JavaScript and then load our homepage. The first article will have a poor quality image. But if you re-enable JavaScript and load the page again, you’ll see it gets replaced by an image more appropiate to your screen resolution. This isn’t a mistake, yet it goes against one of our core principles: “Only download what you are going to use”.
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…
http://wwwnews.live.bbc.co.uk/media/images/67431000/jpg/_67431205_firing.jpg
to…
http://ichef.bbci.co.uk/news/235/media/images/67431000/jpg/_67431205_firing.jpg
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”:
<div class="delayed-image-load"></div>
If the user has a “HTML5” browser, JavaScript is loaded into the page that will convert these divs into images. The JavaScript will also check the width of each image element and change the URL to download the appropiate image. A resize event is also added onto the window object. If the user resizes the browser then the JavaScript will recheck all the widths of the image elements and change the URL if neccessary.
When the JavaScript was first written in 2011, we didn’t know much about responsive images. We made an arbitary decision to add a breakpoint every 30px from 96px up to 736px. This wasn’t based on any evidence or rationale. It was informed more by the image sizes that fit into the old grid system available in BBC’s GEL layout guide.
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.
We’re currently using element size. As the images are loaded in by JavaScript, it means images can’t start to download until the JavaScript is in the page. This means waiting for domReady, and also for our AMD loader to download and call in the rest of our JavaScript. This blocks the rendering of images until all the JavaScript executes.
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.