Responsive & Fast

Chapter 1. Quick Introduction to RWD

Background

Mobile took the web by surprise. The fast growth of cellular devices (and subsequently feature phones) was impressive by itself, only to be compounded by subsequent disruptions such as the launch of the iPhone, the rapid and diverse growth of Android, and the emergence of tablets, led by the iPad. And the next wave of devices is already well on its way, with voice-based systems, smart watches, connected eyeglasses, and even connected mirrors and fridges.

As is often the case, many organizations initially chose to outsource the handling of this brave new world. Building in-house knowledge and technology is hard and time-consuming, and nobody knew for sure whether mobile devices were just a fad, or whether some new revolution would take over before the current one settled down. Even organizations that kept mobile internal usually created separate teams to handle it, separating this risky new turf from the more stable, revenue-generating desktop business.

For the mobile web, this separation manifested as separate mobile sites, known as mdot (or m.) sites. Organizationally, this separation was a good way to let independent teams work effectively. Technically, a separate mobile website was easier to tune for mobile displays and capabilities. Lastly, for many organizations, “mobile strategy” included both mobile web and native mobile apps, and mdot sites were aligned more closely with apps than with the desktop sites.

Dedicated Website Challenges

While useful, the dedicated website approach presents some significant challenges.

On the technical front, maintenance can become an issue. Maintaining two websites is not easy, and gets truly unpleasant when we start repeating the split for tablets, TVs, consoles, and more. Moreover, even within a category there is a huge range of display properties, input methods, browser capabilities, computation power, and other factors—making it impossible to treat all “smartphones,” for instance, as one.

In addition, mobile device fragmentation and the fast pace at which new devices are introduced makes it hard to consistently identify a client device. Facebook is accessed by more than 7,000 device types every day, a figure that is two years old and likely even bigger today. This introduces a need for dedicated device detection libraries, such as Akamai’s Device Characterization, ScientiaMobile’s WURFL, or DotMobi’s DeviceAtlas, which constantly track and update the database of devices. In addition, even these dedicated libraries are limited to the information present in the HTTP request, which often does not hold some of the information we seek. For instance, while one could identify that a request came from an iPhone and determine the iOS version, nothing in the request indicates the actual model of the iPhone used.

On the business front, it became clear that users expect the mobile and non-mobile experiences to be completely aligned. The same user would often browse the same website through their laptop, phone, and tablet—possibly in a single session—and would expect consistent content, functionality, and style across all of them. The approach of “outsourcing mobile” is no longer viable: mobile has to be embedded into the core business and strategy.

Responsive Web Design 101

In May 2010, Ethan Marcotte proposed an alternate approach to dealing with mobile browsing—Responsive Web Design.

Conceptually, Responsive Web Design (RWD) means having a single website that “responds” to the current device, and changes its design accordingly. The use of a single URL, also known as a One Web approach, makes sharing links across devices easier, saves time by removing the need to redirect users from one domain to another, and is likely to improve search engine ranking because the single URL fits Google’s “Dynamic Delivery” recommendation. The adaptation means the web page would modify its design and interaction model to match the current device, striving to achieve an optimal user experience for a specific device.

To achieve this flexibility, Responsive Web Design relies on three primary building blocks:

1. Fluid Grids
2. Flexible Images
3. Media Queries

Implementing Fluid Grids means replacing any fixed size element on the page with a percentage, making its dimensions relative to its parent element and—eventually—the display size itself. For instance, instead of saying that the main content column is 512 px wide, say that it’s 50% of its parent container. On a 1024x768 display, the resulting size will be the same, but on a smaller screen, the column will adapt to take up half the screen width, implicitly improving support for different display sizes.

Flexible Images is essentially the application of Fluid Grids to images, specifying their size as a percentage of their parent container. Note that this means the page needs to explicitly state the (relative) size of every image, using style rules for the image itself or a parent container. Responsive pages cannot rely on the actual dimensions of a downloaded image to determine how much space it will take on a page (a limitation that helps performance, as it avoids unnecessary reflows).

Lastly, Media Queries is a styling capability introduced with CSS3 to extend the simpler media types. These queries allow websites to set different style rules for different display properties (or any “media feature”). For instance, a three-column layout is common on desktop screens, but on a 320-pixel-wide smartphone screen, each column becomes too small to use. A Media Query triggers if the window is below (or above) a certain width, and overrides the styling to use a single column instead. The transition points specified by the Media Queries are known as breakpoints.

These three building blocks, when combined and well implemented, enable powerful web pages that seamlessly work on many devices and appear as though they were written exclusively for it. This helps battle device fragmentation, and even addresses devices that did not exist when the website was created, making RWD “Future Friendly.”

It’s important to notice two properties that these three techniques share.

First, they’re all client-side techniques, applied in the browser. This trait is expected, as RWD aims to eliminate the need for server-side device detection, replacing it with client-side feature detection (such as display size). Nevertheless, it has significant implications, as we’ll soon see.

Secondly, all three techniques focus solely on styling. They dictate the way a page is displayed to a user and how users interact with it, but not the parsing and processing of a page, nor how its resources are downloaded. This property matches the problem RWD set out to address—the design of the page, not the underlying mechanisms.

What This Book Is NOT

Before we go any further, let’s set some expectations.

This book is not a broad web performance book. Web performance is a big and complex topic, and there are many great web performance books out there, most notably Steve Souders’ High Performance Web Sites.

This book focuses on the performance issues specifically related to RWD, and does not cover broader performance practices.

This book is also not an end-to-end RWD book. While it covers some of the basic implementation concepts of RWD, it limits those to the ones that eventually impact web performance. Once again, there are many good books that can help you port your design, code, and entire organization to the world of RWD, and I would encourage you to read those.

Where this book fits is in the intersection between performance and Responsive Web Design, outlining the challenges RWD creates when trying to make pages fast, and helping you overcome them in the best way possible.