How truly responsive images create a web for everyone: Mat Marquis

Mat Marquis told a remarkable story from YouTube in the opening of his talk at Etsy about what’s to come in responsive images.

He told a story that Chris Zacharias, a former developer there, had shared on his blog.

Zacharias accepted a personal challenge within the dev team to get the page weight of YouTube’s watch page down from 1.2 MB to under 100 KB. With some sweat, he did it, and then something incomprehensible happened: the average load time for the new, featherlight page, was going up dramatically. In fact, for lots of users the load time was an inconceivable two minutes.

What was going on?

People were visiting the watch page in disproportionately greater numbers in parts of the world where access to the Internet is much more precious. Places like Africa, Siberia and Southeast Asia, where people pay, as Marquis explained, for every kilobyte they use.

Marquis told the story during a talk, “The Past, Present and Future of Responsive Images,” at Etsy‘s Code As Craft event, early this month. He’s a developer at Bocoup in Boston, a shop that believes deeply in the open web.

Marquis made it his personal crusade to find a way to decrease the load time for web pages and make images truly contextually responsive. Context, he explained, is more than screen size. It’s also about resolution and bandwidth.

If you’re concerned about page weight, he said (and if you want your site to reach people globally, you should be), the major source of increased page weight is heavier and heavier images.

Marquis said, “Maybe without realizing it, we are building websites that fit our contexts, browsing conditions we are used to,” explaining that developers have powerful computers, fast, stable connections and high-resolution screens.

Meanwhile, the mobile spec that reflects most smartphones on the planet is the K-Touch W619, a phone with an 800 MHz processor, 320-by-480 pixel screen and an antique instance of Android. Building websites ready for the iPhone 6 is the exception, not the rule.

Marquis pointed out that the approach 72 percent of all websites take to responsive imagery is simply serving up the exact same image up to whatever screen requests it, and making that image fit on the screen (by using the “100%” tag rather than specifying a pixel width). But a 14 MB image downloaded to your dad’s BlackBerry is still a 14 MB download, even though a high-resolution image still looks low-res on an old screen.

“This is something I want solved at the browser level. This is something I want baked into HTML 5,” Marquis said.

He told the story of how he and some others went to the World Wide Web Consortium (W3C) and formed what would become the Responsive Images Community Group. They wanted something that could serve different images to a user based on the context. The problem was, they needed to give the browser information about those images before it made the request for the image itself. If a browser has to request an image to find out if it’s appropriate, that already misses the point.

It took three attempts to get it right, but (skipping to the end) the team came up with an approach to images now known as the <picture> element, which Marquis says is set to be implemented into Firefox 33, Chrome 38 and Opera 25. It’s also been integrated into Drupal 8, so that a user can upload as massive of an image as she wants, their server will automatically prepare a bunch of versions of that image and the code will help the viewer’s browser decide which of those versions to request.

This helping-the-browser-decide element is critical, because the team realized that responsiveness works best if the user has the power to say that they still want big images even in unstable bandwidth decisions, rather than devs making widely varying subjective decisions for users.

The four use cases <picture> can handle, are as follows.

• Art Direction. When you want to specify a specific image for a context. In particular, if completely different versions of an image, such as different croppings or orientation make sense. See below.
  

  An example of the art direction use case, where a browser downloads a differently cropped and oriented image based on the screen it is loading on. (Image courtesy of the Responsive Images Community Group)

• Types. If new image formats come out this will enable the correct type to be served to the browser that supports it.
• Device Pixel Ratio. Serving the correct resolution to the power of the screen that’s rendering that resolution.
• Sizes. This approach takes a different course based on whether a dev is coding an image as “max width” and “minimum width.” As Marquis explained, it can be a bit hard to follow, but a dev doesn’t really have to follow it. The code sorts it out for you. “We give it a list of options and let the browser take the wheel, and that’s fine,” Marquis said.

The new standard ends up spitting out a lot of code, but that code is telling the browser what it’s choices are for each image, so it chooses just one, optimally. As Marquis said, users won’t see any difference in terms of how their pages look. A few years ago, the only real option for telling a browser what image to serve was the old familiar “img src=” tag. Under this new approach, there’s a bevy of ways to serve an image, but the developer doesn’t have to think them all through.

What users may notice, Marquis said, is a web that seems to be working a bit faster, with fewer websites that users who pay for every kilobyte have to studiously avoid.

Watch his whole talk here: