Improving Responsive Web Design Part 1 – The Problem

Responsive Web Design (RWD) has seen a tremendous rise in popularity over the past year as designers/developers search for an elegant solution to dealing with the ugly reality of browser fragmentation on the web due to the ever-increasing influx of new mobile devices on the market.

While it seems that much of the industry was hoping that this new approach to web design would be the ‘silver bullet’ we’ve all been searching for, as with all design approaches this one is not without its challenges.

Let’s look at some of the popular Responsive Design sites to better understand the challenges.

Grey Goose

Total Size Scripts CSS Images
Desktop 1.03MB 328KB 96KB 617KB
Mobile 650KB 302KB 96KB 234KB

Boston Globe

Total Size Scripts CSS Images
Desktop 878KB 172KB 77KB 434KB
Mobile 886KB 198KB 77KB 445KB


Total Size Scripts CSS Images
Desktop 1.58MB 380KB 34KB 329KB
Mobile 909KB 380KB 34KB 339KB

Red Bull Music Academy

Total Size Scripts CSS Images
Desktop 1.51MB 345KB 411KB 697KB
Mobile 1.49MB 372KB 412KB 653KB

Even though all of these above sites do an excellent job in responding to device dimensions, they are not being responsive to the connection speed, latency, device capabilities and dare I use the word “context”. Serving 1.49MB in case of Red Bull or even 650KB in case of Grey Goose is not an acceptable response size for a mobile user on a 3G connection speed. The richer you make the desktop experience, the greater this additional overhead will be.

So here are the challenges with Responsive Design:


One area of weakness of Responsive Design is related to the handling of images and other media types on a page. Traditional Responsive Design relies on a one-size-fits-all approach where a single image is either scaled up or down to properly size itself for a given viewport.

While at a high-level this may ‘make sense’ it quickly falls apart when you start looking at the details and the resulting websites. Viewports range in size from 320×240 for a low level mobile device upwards to 1920×1080 for a HD1080 display. Obviously sending an image optimized for 1080p display to a mobile device is not a good idea. Likewise sending a mobile sized image to a high definition desktop display and scaling it up is likely to make your designer’s head explode due to the high loss in image fidelity.

Image size concerns aside, there is also the question of image composition itself. Framing an image for a 3” display probably should be done differently than that of a 24” screen. There is a difference in utility that is more than just scaling; it’s about communicating a message.

There are few solutions to overcome flexible media challenge, but each of them come with a drawback.

Device Specific Features

Another area of contention with Responsive Design relates the way you are forced to handle device specific features. In a responsive paradigm all devices have to load the code for the feature whether they can use it or not.

One area where this is becoming a concern is related to leveraging ‘app like’ functionality of new devices such as touch events, accelerometers and gyroscopes. In a responsive website these features are detected on the client using JavaScript and as such the code to deal with these must all be downloaded by the user. Essentially you have just used up some of your consumers limited mobile bandwidth with no gain for the end user – you just slowed down the user experience. This situation will only worsen as new device classes and display contexts like smart TV browsers emerge.

Content Prioritization

Content targeting for a specific device can be problematic when serving the same HTML/CSS/JS to all devices. Once the source order of the page has been set, it can be a challenge to reorder the content or bubble up relevant content for a specific device type. Additionally personalization based on device, user preferences, or user profile can be a lot harder to achieve.

Typically changes in the content from a responsive model involve simple information hiding. I would argue about prioritizing content for a specific device in most of the cases, but there is definitely a need for it on a Mobile device. One good example of this is NFL. When you access the scores section of the site on a Mobile device, the site just displays the current score, but on desktop it shows videos and other content.

The Overall Challenge

I’m sure there are a lot of talented individuals reading this thinking, “Yeah, but I can fix that and make it work…” And I agree, these challenges aren’t wicked problems that have no possible solutions, they are addressable. But the front-end code is already responsible for so much:

  • Progressive Enhancements
  • Cross-browser Support
  • CSS Browser Hacks
  • Shims and Fallbacks
  • Polyfills
  • Vendor Pre-fixes
  • Script Loaders
  • Conditional Logic
  • DOM Manipulation
  • Analytics

Addressing all the needs of Responsive Design is going to quickly add a significant amount of code to the HTML, JS and CSS files which have a direct relation to increased code maintenance, increased up-front build times, and increased QA time for regression testing all devices. Obviously this larger code base and added complexity will lead to more bugs and larger overall file sizes of page assets which will ultimately be visible to the end-consumer in the form of a slower site that is not responding in expected ways.

If only there were an alternative… (Stay tuned for the next installment!)

Contributions from: @sashasklar, @JohnnyReading, @mutootum

Posted in Blog, Responsive+ Design, Web Design
3 Comments » for Improving Responsive Web Design Part 1 – The Problem
  1. Scott Jehl says:

    Hey there – I came upon this great post and figured I’d lend a point or two on the Boston Globe stats, if I may.

    Flat filesize breakdowns make for an interesting comparison of these sites, but they don’t go very far in telling how that filesize actually affects the user experience (it often does adversely, but not always).

    In the case of the Boston Globe site, almost all of the JavaScript (save for 5kb or so) is loaded conditionally and lazily, long after the page is already rendering and usable. Many browsers and devices receive no further JS at all, but for those that do, it’s likely a different filesize for every browser that visits the site, since a different pack of JS files are combined and delivered based on that device’s constraints and capabilities. In that way, the JS download size can vary greatly, and a hard number is tough to nail down – especially with broad categories like “mobile” and “desktop”. Regardless of the JS size though, the site is usable before the JS gets there, which I think makes a difference. (Fwiw – ads are often particularly heavy, but also are loaded in such a way to not block the content.)

    Markup and images on that site *should* also vary depending on screen size. At least at launch, we chose to include several large-screen features only for devices that are greater than a certain resolution, such as the drawer at the bottom of the desktop experience. Feature images often start small and enhance to larger versions on big screens as well, but that isn’t used very widely to my knowledge.

    That said, “mobile” and “desktop” are tough definitions: perhaps if you were looking at the site on a tablet, the numbers would be pretty close together.

    Either way, filesize matters, no doubt. I just think the way files are loaded is often just as important as how big they are. Perhaps the other sites you featured have some loading niceties as well, but I can’t say.

    • Shiva Vannavada says:

      Hi Scott, thanks for taking the time to comment. While conditional/lazy loading JavaScript certainly helps I think you’d agree it would be optimal if we could only deliver the payload a user needs without it.

      Additionally, JavaScript is only one part of the additional code and assets we are sending to the client. Markup, CSS, sprites and standalone images are being sent to the client layer with content and logic that’s not needed by that user. How can we keep the important part of RWD, design, while leaving behind some of these sub-optimal approaches? This is the problem we’re trying to solve.

      I agree that “mobile”, “tablet” and “desktop” are increasingly useless terms. We should be clearer that when we use them we’re referring to breakpoints and capabilities that map to them.

  2. John Reading says:

    File size (particularly in the case of js) can be misleading. On most responsive sites, you may not see a huge difference in K size because a lot of the functionality in handling multiple layouts is baked in. You might use lazy loading for progressive enhancement of certain pieces of functionality (which is preferable to loading everything for everyone), but there are issues there as well. Lazy loading functionality introduces K size, memory footprint, and a lag in UX. Granted the K size for a lazy loader is probably negligible, it does introduce MORE logic and MORE memory. Again, this may not be a problem for most end users, but it all adds up and it’s clear that’s where UX is impacted most. If you could avoid K, extra memory, and showing your users a loading indicator, why wouldn’t you? Why off load capabilities tests to the client if the server can sniff “iOS4”? Why send Modernzr down the wire to an iPhone at all? The goal of responsive design is to remain device agnostic with your layouts and, most importantly, with your content. Secondarily, it’s about a common code base but those two are definitely NOT mutually exclusive. Run-time or build-time forking is something that should be part of the equation. Some people forget that it’s not about sliding your browser window around.

1 Pings/Trackbacks for "Improving Responsive Web Design Part 1 – The Problem"
  1. [...] previous articles in our Responsive Web Design series we discussed the challenges associated with Responsive Design that are typically encountered and some simple recommendations [...]

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>