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:
- Fluid Grids
- Flexible Images
- 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.
Get Responsive & Fast now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.