Responsive Web Design, Part 2 (2015)
Responsive Images
BY YOAV WEISS
Almost from its very beginning, responsive web design has had one thorny issue that has proved extremely difficult to get right: responsive images.
In this chapter, we will discuss the different responsive images use cases and what native solutions we may need to create performant responsive websites. We will also look at ways to make these solutions easier to deploy and maintain.
But first, let’s take a walk down memory lane, and see how we got here.
How It All Began
Our story starts in ancient times, when WURFLs roamed the wilderness and mobile-only websites were a thing. Back in these pre-2007 days, a developer who wanted to provide mobile users with access to their website created a simpler, dumbed-down version of the real website and served that based on UA detection. That method was never truly reliable, but it was necessary to serve tailored content to mobile devices.
But the mobile landscape was revolutionized by Apple’s iPhone. The proliferation of devices that followed, with a myriad of form factors and functionality, called out for a better way to target mobile (and not so mobile) users. Responsive web design combined new browser capabilities and CSS techniques to create websites that adapted to the device displaying them and maintained their good looks everywhere. Developers could stop worrying about unreliable device detection and think of their websites in terms of viewport dimensions.
RWD is based on three pillars: media queries, fluid grids, and flexible images. But even in RWD’s early days it was obvious1 that the flexible images part was not holding to its promise.
Even though RWD sites looked different on each device, underneath, they continued to download the same resources everywhere. And since images comprised the major part of the bytes that websites were downloading, and where lots of savings could be made between different devices, that meant a lot of wasted bytes for low end devices, and eventually, bloated mobile websites.
And so, the issue of responsive images was born.
The realization that something had to be done about those pesky responsive images started creeping up across the developer and web performance community. From the four corners of the world, developers gathered and started discussing possible solutions. Hacking around the problem seemed like the obvious answer but, as we soon discovered, it was a poor one2. All hacks had issues either with double downloads, delays or trouble serving the first site load, creating their own share of performance issues while trying to solve a performance problem.
Slowly but surely, more and more developers reached the conclusion that a native solution was required to resolve this problem, and that it could not come soon enough.
Some of us formed the Responsive Images Community Group3 (RICG), which took on the uphill battle of defining the various use cases of the responsive images problem; convincing browser vendors that it’s a problem worth solving; specifying, along with browser vendors, the solutions to these use cases; and pushing the implementation in browsers, with the help of the community4.