This post is about a development experiment we ran at Next Digital recently. The post is co-authored by Next Digital front-end developer Anthony Bordonaro and myself. It was originally shared on the Next Digital blog.
For all its benefits, responsive design still has a long way to go before we have the level of control that we need to create great user experiences. Right now the only means of manipulation that we have is via CSS media queries and is limited to two main areas:
Media types like a screen or projector
Media features such as width, height, minimum-width etc.
At the moment we don’t know whether the user has the bandwith capacity (or desire) to download the potentially large files that that the site is sending. The biggest impact on bandwidth comes from images.One of the ways we can improve the end user experience is to use responsive image techniques. At Next Digital we have been looking into how to best implement responsive images. There are dozens of different methods and libraries out there for responsive images. For this purpose we chose two of the more popular options:
An issue with responsive images is that modern browsers use a ‘look ahead’ technique where the parser will create an HTMLImageElement as it comes across an img element. The advantage to this is that the browser can begin downloading images as the HTML is still being downloaded/parsed and your page can be rendered quicker.
The downside is that if we want to load a different image based on what width or resolution the user is currently viewing on multiple requests will be sent. Of course this leads to more downloads by the user which is what we’re trying to avoid in the first place. Responsive image techniques like these two give the client a better level of control while at the same time reducing the number of requests being sent.
We decided to consult Next Digital’s search expert Daylan Pearce. Image search is actually a pretty big deal for some of our clients and leads to a lot of traffic to their websites. So if we want to use responsive images we needed to find to ensure our images are indexed and visible by search engines. We set up two experiment meme pages, one using Picturefill and the other using Imager.js:
These particular images were selected because they were a little ‘left of center’, sure they exist online, but when it did come time to search for them we wanted to make sure that the we weren’t being blown away by massive amounts of high authority domains using the same images and keywords. Additionally, if we were going to be looking at two images for a while, it might as well be two pictures as awesome as a hedgehog in a party hat and a frog dressed as an astronaut.
As we suspected, none of the images were indexed and were not visible by Google crawlers. My first thought in getting the images indexed was by using a noscript tag which has a lot of merit, but ultimately is too clunky to insert every time we wanted to place an image on the page.
So we thought we should have a look at how Google treats similar code – in particular their stance on dynamically loading AJAX code, in which we discovered that Google’s stance on Ajax crawling contains a section on handing pages without hash fragments:
By inserting the meta fragment on your page, you’re telling the crawler that you have content here that is loaded via ajax, the crawler will hit an alternate page which displays what an end user would be seeing after the ajax content has loaded.
I set up a PHP script that displays a non-responsive image version of the page if the query “_escaped_fragment_” exists, render this page for crawlers. If the query does not match, just render the standard responsive images version. Pretty simple really and you can check it out here:
A couple of days later we checked Google and it worked, we had been indexed!
Success! But where could we take it now?
In the search tools option of Google search, users can select the exact image they are looking for based on a number of elements including ages, types of photo (headshot, scenery, pattern etc) and size.
Given that three separate image sizes were uploaded and accessible by the user based on device, we thought ‘Hey! maybe we can get all of these images indexed’, after all, three relevant results are better than one. So the next thing we wanted to test out was whether or not we could take advantage of Google Image search’s Size Selection option.
Sure enough, the page and content could be rendered but unfortunately only the original image was indexed in Google image search – even with the image size filter enabled. While exactly why Google opted to not index the additional sizes isn’t quite clear, we expect that this is due to the duplicate content element of the Google image search algorithm.
Conducting this experiment helped us to conclude:
#1 This seems to be the most elegant way that we’ve found so far to provide a responsive design that is both suitable for device/connection bandwidth optimisation, as well as being friendly for search engine indexation.
#2 Using pictures of hedgehogs wearing party hats and frogs dressed as astronauts was an awesome choice!