Racing Toward Responsive?
A Look at Responsive Web Design and Mobile Performance
Like the quest for the Holy Grail, Web developers have been searching for a magical solution that will make every website shine on any and every device. It appears that, if not the actual Grail itself, they have come upon something that takes them leagues closer to that elusive goal. It’s Responsive Web Design, or RWD, and in the past year it has been picking up tremendous momentum as the go-to solution for getting content onto an ever-growing and ever-more-disparate pool of Web devices.
Through a combination of techniques, responsive Web design promises to render content in a visually pleasing, highly usable format, true to the designer’s intentions, on virtually any device. Many websites are achieving that promise in large measure. But at the same time, questions arise as to whether mobile performance is taking a back seat to visual appeal and usability. The short answer is, it doesn’t have to. As with any development technique for mobile or desktop, performance depends on what’s being included and how it’s being included.
The blog post heard ’round the Web
It all started with a blog post. In May of 2010, Web designer-developer Ethan Marcotte published an article on A List Apart titled simply, “Responsive Web Design.” That particular expression had not been used before. But what a stir it was about to make.
Marcotte proposed a development strategy to address, and even embrace, the ephemeral and fluid nature of the Web. His idea acknowledged that the ways the Web is viewed, and the content itself, changes too quickly for a traditional, linear development approach to continue to be practical. He suggested that three concepts – fluid grids, flexible images, and media queries – could be coordinated to enable website designs and content to adapt to almost any screen or window and deliver a satisfying user experience. It’s an idea that’s proven largely to be true, and is reverberating throughout the Web community.
“I do think fragmenting our content across different ‘device-optimized’ experiences is a losing proposition, or at least an unsustainable one,” Marcotte writes in his book, Responsive Web Design. “As the past few years have shown us, we simply can’t compete with the pace of technology. Are we really going to create a custom experience for every new browser or device that appears?
“And if not, what’s the alternative?”1
The idea that responsive Web design will make a site future-ready, whether it’s for this year’s new iPhones and the dozens of other smartphones that will come out, or some new connected device yet to be imagined, is a strong argument that proponents of RWD make.
“We need to get smarter about how we construct our Web experiences and make them so they are able to flex and adapt to whatever device the user happens to be viewing,” says Brad Frost, a developer and leading thinker, speaker and writer about RWD. “We don’t know what devices, what gizmos are going to be under the Christmas tree two years from now. That’s the sort of stuff we need to be designing for today.”
Time magazine illustrates how responsive Web design can enable content to gracefully parse to different screen sizes. As is often the case, a three-column layout stays intact from desktop to tablet, and changes to a single column for smartphone.
Responsive Web Design 101
Responsive Web design, simply put, is a design and development approach that enables content to be presented in visually satisfying, usable form regardless of the viewport through which it is seen (viewport meaning the framed area, typically a browser window, in which content is displayed). Whether viewed on a large desktop monitor, tablet, smartphone, TV – or eventually the refrigerator door, dashboard display, bathroom mirror and who knows what else – the website displays properly and meets the user’s needs.
Instead of asking what type of device is at the other end of the connection, i.e., a desktop, an iPhone, a Galaxy S4, etc., RWD uses media queries to determine the screen size and resolution and other key data that determine how the layout should be presented. Then, through a flexible grid and flexible images, and using the appropriate layout determined by screen size/resolution breakpoints, content is presented in an optimum format for each screen.
The Building Blocks of Responsive Design
From a practical front-end standpoint, RWD has three main components.
Flexible grid. Instead of the content space being expressed in absolute, unchanging pixel dimensions, it is expressed proportionally, as a fluid percentage of the overall space that changes as the size of that space – the viewport – shrinks or enlarges. Size and position in the viewport is expressed as a ratio between the element and the container.
Flexible images. Flexible or fluid images work in similar fashion to the flexible grid; image size is expressed proportionately to the container in which the image fits. The browser scales the image and fits it per the instructions in the CSS. It works for video and other embedded media as well.
Media Queries. This is the mechanism that identifies what’s on the user side of the equation – the type of media, and the physical characteristics of the device and browser – and enables designer/developers to specify the optimum display of content, including alternate layouts tailored to screen orientation and resolution.2
Why responsive, why now?
The need for responsive design or something like it becomes more obvious with each passing day. There are just too many ways to get at the Web. In November of last year, the tech site Mashable was accessed on more than 2,500 different devices; no wonder Mashable is calling 2013 “the Year of Responsive Web Design.”3 It’s no longer enough to create a desktop site plus something that will work on an iPhone and the top few Android devices, and feel like sufficient audience is covered. Without a bigger solution, too many people are left out.
Is RWD the solution? Many certainly believe it is at least a major step in the right direction. In 2012, Google made it the “recommended configuration” for smartphone sites to facilitate search. Some of the biggest names on the Web have gone responsive with beautiful results.
BarackObama.com is a well-constructed responsive site. However, the pitfalls of responsive images can be seen in the iPad photo, lower left; it's an unfortunate crop that should have been corrected.
Raising the performance question
From a visual perspective, RWD has the promise to deliver home runs. It’s a lot of work, but as a number of sites have demonstrated, it’s within reach. From a performance perspective, however, there are more groundouts on the mobile side than one would like to see. But it’s not necessarily RWD that is at fault.
The problem is the same as it’s always been for mobile: It’s not just about making a site fit on a tiny screen. It’s about making it fit through the tiny pipes to get to that screen. Visual presentation is a fairly simple problem. But whether one is building a mobile site the old-fashioned way or using RWD, the problems of latency, slow wireless connections, and limited client-side processing power will always dramatically impact performance, and will always require careful attention from the development team. But there are some performance issues that are unique to RWD.
Keynote monitored performance for a handful of top responsive sites on a typical weekday. The mobile numbers here are all respectable, though it should be noted these measurements were taken over WiFi and not the slower over-the-air carriers. If there are any performance issues here, they seem to be on the desktop side, with only two of the five sites coming in under three seconds.
Serving a heaping helping of hidden content
From a performance perspective, pushing a website’s full content through and reformatting it to look great on a smartphone is not much different than simply pushing through the whole desktop site. In fact, it could be worse, as the responsive site is likely to be scaling images on the fly in the browser. It may look better, but it’s not an optimized mobile experience.
Akamai performance researcher Guy Podjarny looked at 347 responsive sites in 2012 and found that 86 percent of them weighed about the same when loaded in the smallest, smartphone-size window as when loaded in the largest desktop window. He writes, “despite the fact the websites look like an m-dot site when loaded on a small screen, they are still downloading the full website content, and are thus painfully slow.”4
Podjarny finds three reasons for this “over-downloading” that cover virtually all the cases. First, “download and hide,” the biggest culprit, refers to downloading all the site content and then selectively displaying it on the smaller device. Next, “download and shrink” refers to downloading a “desktop-grade” image and then scaling it down to the small screen, effectively wasting tons of downloaded pixels. Lastly, “excess DOM” refers to parsing and processing hidden areas of the DOM that aren’t needed for the smaller site.5 Pushing too much unneeded content through a mobile connection and then asking the browser to deal with it is guaranteed to slow any site down.
Because they are among the weightiest assets on a site, images tend to be big performance culprits (as in “download and shrink,” above). One-size-image-scales-to-all is definitely not a performance-minded strategy.
“Media content, in particular, on responsive design websites is often stored in basically one or two resolutions,” says Ken Harker, senior consultant and mobile evangelist at Keynote Systems. “So if you need to fetch an image, you may end up doing things like scaling it on the fly in the browser to fit the screen, which is OK in a design sense because it will look fine, but from a performance sense, it can be highly inefficient. If you take an image and shrink it down by 50 percent in each dimension, you’re downloading four times as many bytes as you need for that image.
“I personally see evidence that it’s probably best to go with three or four different versions of the site, and figure out which one is closest, and then work on being responsive within a narrower range.”
The case for RWD and mobile-first
Certainly, a site built from the ground-up only for mobile – the m-dot site – should always have a performance advantage over the built-for-everywhere responsive mobile site, even when both are built to best practices. The question then, is whether the performance ding is outweighed by the advantages of a build-for-everywhere responsive approach. If the site is built well, there’s a good chance those dings are small enough that the answer is yes.
What are some of those key RWD advantages? Obviously, the huge one is a site that can display beautifully on almost any device, while having to tailor it only for a handful of “breakpoints,” or viewport widths that necessitate a change in layout and/or media delivery. There are other advantages as well:
• Content is easier to update, as there is only one site to manage (though as noted in the image discussion above, multiple versions of some assets may be required).
• There is only one set of analytics to review, which makes for easier analysis and faster responses.
• Overall site strategy is simplified and unified.
Some might also count the discipline involved in creating a leaner and more focused site to be a big advantage of RWD. If throughout the strategy, planning, design and development process, everyone on the team has the small screen top-of-mind, it is likely that the content will be more focused, the hierarchy more clear, and the overall experience more fluid and streamlined.
FoodSense is a highly designed, highly visual site that shows how good design can hold up across devices; that round logo does take up an unfortunate amount of vertical real estate in the smartphone version. FoodSense was also the best overall performer in a one-day Keynote responsive test, with all three versions loading on average under three seconds.
In fact, many RWD teams are embracing a mobile-first strategy, creating and building the mobile site before tackling the bigger screens. It turns standard development flow on its head: Instead of “graceful degradation” from big screen to small, the path is “progressive enhancement” from small screen to big.6 This keeps performance front-and-center, and keeps the team focused on creating efficient, streamlined user experiences.
Making responsive perform
The responsive Web design movement is raising the level of debate not just about how websites look, but also about how they perform. The prominent RWD innovators and evangelists make the case that making the transition to RWD is an excellent time to re-focus the entire team on performance.
“The fact of the matter is that everyone’s site is having a hard time with performance,” Frost says. “Once they start growing fatter and fatter and fatter, whether it’s a desktop-only site, whether it’s a mobile-specific site, whether it’s a responsive site, it’s a really big problem across the board…We need to really elevate the conversation around performance as a priority, instead of treating it as an afterthought.”
Google performance guru Steve Souders and others have put forth the idea of a setting a performance budget, either in terms of page weight, number of requests, page load time – whatever metric makes sense. Then everyone on the team has to live within it. So if the product people want to add more photos, or the visual designers want to use more fonts, the decision has to be made as to what’s going to go to accommodate these additional items. As often as not, they end up not being as important as first thought.
Mobile responds to best practices
So how do you make sure a RWD site performs acceptably on mobile? Podjarny urges developers to use responsive images, to build for mobile first (and actually code it), and measure everything to make sure you understand the site’s true performance.7 Frost would concur with that list, and also add “embrace conditional loading” to make sure small screen users aren’t needlessly downloading content they can’t use.8
Above all, the key to great performance is thorough testing on all the devices being used to access the content, first to make sure that the layout design is in fact responding properly to the viewport parameters, and second to make sure the content is loading in an acceptably short time.
Design for the ebb and flow
Responsive Web design is an exciting idea, but like anything, it’s probably not for everybody. Some businesses have had good reasons to pursue a dedicated app strategy. Some have big mobile teams and are successfully following a path of dedicated, built from the ground-up mobile sites. But for those site owners who need a robust presence on every screen and are not there yet, or are finding their current approach unwieldy, RWD might be an excellent path to follow if it is followed with performance as a primary deliverable. It’s hard to tell yet if it’s the Holy Grail, but it may be the closest we’ve come yet.
“Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences,” Marcotte concludes in his seminal article. “Responsive web design offers us a way forward, finally allowing us to ‘design for the ebb and flow of things.’”9
- Ethan Marcotte, Responsive Web Design, p. 19 (iPad edition), A Book Apart, New York, 2011
- Ethan Marcotte, Responsive Web Design, p. 179 (iPad edition), A Book Apart, New York, 2011
- Mashable.com, “Why 2013 Is the Year of Responsive Web Design,” by Pete Cashmore, 12/11/12
- Guy’s Pod/Quick Thoughts on Performance, “Performance Implications of Responsive Design – Book Contribution,” by Guy Podjarny, 7/11/12
- Jason Grigsby, “Performance Implications of Responsive Web Design,” from a session at Velocity 2012
- Guy’s Pod/Quick Thoughts on Performance, “Performance Implications of Responsive Design – Book Contribution,” by Guy Podjarny, 7/11/12
- Brad Frost Web, “Prioritizing Performance in Responsive Design,” by Brad Frost, 3/7/13
- A List Apart, “Responsive Web Design,” by Ethan Marcotte, 5/25/10