Learning About Responsive Images
> **_Specification and API subject to change. Be aware that the specification is not finalized and it may change in incompatible ways. Do not use responsive images in production yet. If you do you do so at your own risk_** Once upon a time we were cool by just putting an image (or more) in our web content. Brownie points if we added a background image… bonus points if the colors in the image did not conflict with the colors of the text or the links :o) But now we have to worry about how fast our content loads, whether we are providing a good experience for users whether they are in a slow 2G connection or the fastest corporate wired broadband and everything in between. And the biggest cause of slowdowns are images! According to the HTTP archive data for January 15, 2016 images took 1163KB out of a total of 1961KB average total size.  And then breaks down the average size of an individual response per file format. &chxtc=0,6&chxs=0,676767,11.5,0,l%7C1,676767,11.5,1,lt,67676700&chxr=1,0,160%7C0,0,206&chxt=x,y&chbh=22&chs=640x310&cht=bhg&chco=3B356A&chds=0,206&chd=t:4,24,17,7,5,15,14,196&chm=N**+kB,676767,0,,12,,:4:&chma=%7C0,5&chtt=Average+Individual+Response+Size "Average Individual Response Size") The graphic and associate information can be found in the [http archive](http://httparchive.org/interesting.php?a=All&l=Jan%2015%202016&s=Top1000) ## So what can we do about this? The first aspect to consider is how we export the images from our photo applications. It may not sound like much but even shaving a few kilobytes from the image size can really enhance the user experience. I’ve been using [imagemin](https://www.npmjs.com/package/imagemin) both as a standalone tool and as part of my grunt and gulp build processes and I can see savings of up to 1MB for a site that used 20 images. These are production time decisions and, while we can revisit them, we can not make major changes to them. But what if we could create multiple versions of an image based on the browser screen size and resolution and then tell the browser which one to use based on media queries? Answer all those convoluted (and sometimes confusing questions) are what responsive images seek to answer. ## Use Cases and Applications ### HDPI versus normal resolution One my biggest pet peeves has always been having to hack around delivering images to HDPI (retina) devices and normal devices without having to create multiple pages. Responsive images solve this by adding an `x` component to the `srcset` attribute like in the example below. If the has a regular display the small (`1x`) image will be displayed but if we’re in a Retina display (or better I’d assume) then the larger image (`2x`) will be served. It is important to realize that the size of the image is the same regardless of the resolution used. The `x` attribute indicates resultions, nothing else. ```
```
### Fluid Images
I was thrilled when I discovered that making the width of an image 100% and the height auto would automatically resize them. I then learned about image preloading and how much it impacts performance and loading times… and how much it hinders really responsive images.
> Image preloading is, according to Steve Souders, “the single biggest performance improvement browsers have ever made.” Images are often the heaviest elements on a page; loading them ASAP is in everyone’s best interest. Thus, the first thing a browser will do with a page is scan the HTML for image URLs and begin loading them. The browser does this long before it has constructed a DOM, loaded external CSS or painted a layout. Solving the fluid-image use case is tricky, then; we need the browser to pick a source before it knows the image’s rendered size. From: [Responsive Images Done Right: A Guide To 
```
We can have multiple media queries in the sizes attribute. Say, for example, we want the images to be 50% of the viewport width if the monitor is 40em or larger, 33.3% if the viewport is between 36 and 40em and 100% if it’s 36em or narrower. The code would look like this:
```
sizes="
(min-width: 40em) 50vw,
( (min-width: 36em) and (max-width: 40em) ) 33.3vw,
100vw"
```
**_TODO: Verify that the second value for the sizes attribute is valid for sizes. Have asked RCIG on twitter_** **_TODO: Research if we can put this in a SCSS mixin and drive it from stylesheets instead of putting it directly in the HTML_**
### Switching image types while supporting older browsers
In an ideal world, all browser would support all image formats so we can take advantage of the formats stregths and avoid their weaknesses. But this is not the case. To handle this we’ll introduce a new element: `picture` and repurpose the `source` attribute from the `audio` and `video` elements.
In the example below the browser will take the first image format it supports and if it doesn’t support any of the formats listed in the `source` children it will default to the `img` element. The same thing will happen if the browser doesn’t support the `picture` element at all.
```
