Responsibly Responsive Images & Sliders

Responsive websites are the latest trend these days. A Responsive website is viewable at all platforms whether its a mobile, an ipad or desktop/laptop of various resolutions. So, when designers {talking about the popular ones as well} design a website or a theme they make the website responsive but since they can not make images responsive they end up squeezing up large size images to smaller ones.
Now, displaying a large image in a small space by restring the width and height of image puts a lot of load on the browser. Because now the browser runs algorithms to correctly display the image, that is; it removes some pixels from the surrounding areas where there are pixels of similar color so that the image is displayed with minimal impact. Similar is the case when browsers are required to zoom the images.

Ultimately it impacts the load speed of the website, since browser now has to do a lot more to show the images. This impact increases in case of sliders when browsers have multiple images to handle.

Ideally an image of appropriate size should be available for every resolution.

So, for how many resolutions should a website have images prepared for?
/* Smartphones (portrait and landscape) ———– */
 320px & 480px

/* iPads (portrait and landscape) ———– */

768px & 1024px

/* Desktops and laptops ———– */

800px, 1024px, 1140px, 1280px, 1336px, 1440px, 1600px

/* Large screens ———– */

1824px

……

there are many other resolution but unless your website is a 100% fluid website, you would have a maximum supported resolution, usually 960px or 1140px. So all one needs to do is support lower resolutions and have lower resolution images which replace the original image.

Once you have all these images,

the next challenge appears how to show the appropriate image at the right resolution.

The challenge appears bigger because:

1. The right image source has to be loaded at the time of  image display. 

That means that if I have an iPhone then the <img src= should include the iphone resolution image when the page is loaded up.

2. The screen resolution can only be calculated once the viewer/user has opened the site.

Where here we can only find the user (client viewport) resolution when the javascript identifies user screen resolution. So, you can not replace the images via javascript because this would lead to simultaneous download of two images.

Here are some solutions to this issue:

1. ResponsiveImages.js by Filament : Here you give image source as <img src=”small.jpg?full=large.jpg” > and a javascript responsiveimages.js in the head and some changes in .htaccess file. So when the javascript loads up it redirects all images via .htaccess  of you site which determines which image to show.

2. Loading images via Ajax call: Here you load up the website without any images, then identify the users viewport using javascript and then make ajax calls to load up images and sliders on that page. We also set a cookie on that browser for the resolution it can support and next time use only the javascript to identify and render images, so we save ajax calls next time the user loads the website.

3. Another one is Called Picture fill: Here we give markup as

<div data-picture data-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia"> 

<div data-src="small.jpg"></div> 

<div data-src="medium.jpg" data-media="(min-width: 400px)"></div> 

<div data-src="large.jpg" data-media="(min-width: 800px)"></div> 

<div data-src="extralarge.jpg" data-media="(min-width: 1000px)"></div> 

<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. --> 

<noscript> 

<img src="external/imgs/small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">

</noscript> 

</div>

The javascript identifies the resolution and loads up the correct image based on the resolution, this is cool….

4. HTML5 History API : history.pushstate(): This is an interesting feature of HTML5 where in you can call the image form the users cache, the only disadvantage that it is not supported by all browsers and IE, so it goes out of the options…damn you IE !!

Out of the remaining options, I am much more comfortable with the (2.)  or (3.) option than the first one, because the former (1.) makes things more complicated and I am not sure how much speed benefit will I get using that. Whereas for the (2.) loading images via ajax, will give an SEO benefit because all your images would not be loaded up when the Google bot crawls your site (because bots can’t run javascript), plus the content would be rendered faster which is all that matters to the bot. I am applying (2.) and (3.) above technique in my next theme, and will test the theme on an existing site and see what benefit do I get out of it on my existing blog ;).

Share your thoughts on this….