In his presentation at An Event Apart in Austin TX 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 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.8MB. 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.
- When Youtube redesigned their player page to be 98KB vs. 1MB, they found the average load time went up. They had accessed markets they couldn’t reach before due to their high load times.
- 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. Only 6% optimize things for specific devices.
- 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.
- 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.
- Through Kickstarter, the picture element was implemented in Blink and now is being ported over to Webkit.
- The picture element is shipping in upcoming Firefox, Webkit, and Chrome browsers.
- You can use the picturefill Javascript polyfill to start writing images in the picture element format. It has been updated to reflect the final specification.
- Responsive images breakdown to a few use cases: art direction, device pixel ratio, sizes,
- Art direction: when you need full control of images. The first source in a matching media query gets loaded.
- Device pixel ratio: determine which images get used on high resolution screens. This is implemented as a suggestion and can be over-ridden by users.
- With picture, you can serve image types that are only supported in specific browsers and not in others without incurring double downloads.
- Sizes: use this in situations where you don't need art direction, just provide a few sources and let the browser do the rest. It factors in screen size, bandwidth, etc. and it can make educated decisions about what to download.
- The picture element can be used in lots of different ways, you don't need them all. Don't get intimidated by all the possible use cases.
- Ultimately, users don't and shouldn't care about your technical solutions. They should just get a faster experience.