An Event Apart: The Future of Responsive Images

by February 18, 2014

At An Event Apart in Atlanta GA 2014, Mat Marquis walked through the history of developing a responsive images solution for the Web and the solution coming to browsers soon. Here's my notes from his talk The Past, Present, and Future of Responsive Images:

  • Responsive Web design is made up of three things: a flexible grid, media queries, and flexible images & media. But as developers we've also made responsive design synonymous with large web sites.
  • One of the most common critiques against responsive Web design is that it creates large (file size) Web sites, thereby slowing Web pages down.
  • The average Web page sizes are 1.6MB. Images are responsible for most of these large sizes.
  • The Web is all about universal access. We are responsible for making sure people can get to content and not block them based on their device.
  • We are surrounded by high resolution displays. Larger images can be even 4x higher than a standard resolution image.
  • The complete works of William Shakespeare can be downloaded 3 times before reaching the files sizes of some Web sites.
  • 72% of responsive sites send the same assets to mobile sites as they do to desktop sites.
  • Measure twice, cut once. Web browsers should take the burden of images on.

Working Through Options

  • Images and media can be made fluid by setting max-width to 100%. This requires us to send images at the largest size they can be shown.
  • In the video element, you can use the media attribute to send different sources to different sized screens.
  • The image element, however, only fetches a single element and brings it down to the screen.
  • To avoid downloading big images on mobile, developers loaded small images first, then replaced them using Javascript if the screen was large.
  • Due to more aggressive browser pre-fetching behavior, this solution stopped working. Many new solutions were tried until ultimately, a Javascript solution was ruled out.
  • Two competing proposals for a browser-standard to support responsive images emerged the picture element and srcset.
  • srcset was efficient at dealing with resolutions and worked outside of media queries. These ideas were adopted into the new picture element.
  • srcset is specced as a suggestion. People can set up preferences like: always give me high res image, never do, or give them when bandwidth permits.
  • The picture element was submitted as a proposal but browser manufacturers were not providing feedback.
  • A proposal from Google for srcN gained a lot of traction in a short amount of time. The basic structure was the same as picture but with a few challenges. But the syntax had issues with numbered attributes.
  • Most people liked the srcN proposal except for the issue of numbered attributes -which went against the way most Web standards worked.
  • Webkit killed srcN and srcset was removed by Mozilla. This officially took these two options off the table.

A Final Solution

  • After three years of work, browsers have finally agreed to support the picture element.
  • It is on Mozilla's roadmap for the first quarter of 2014.
  • Members of the Responsive Images group put in hundreds of hours to help make this happen.
  • This was a community effort to help the Web.
  • You can use the picturefill Javascript polyfill to start writing images in the picture element format.

Other Techniques

  • Compressive images allows you to compress images a lot at large sizes, then allow browsers to scale down to the right size.
  • Users saving compressive images get blurry assets if they download the compressed size image. Browser memory can be overloaded with images that are too large.
  • SVG images are vector-based code that scales fluidly.
  • SVG support is pretty great except for Android 2 and lower. So you need to provide a fallback.
  • Grunticon is a tool that automates all your SVG fallbacks and outputs 3 stylesheets and URIs for all support across all browsers. There's also a drag & drop solution on the Web.