The Responsive Web Design War Strategy

It seems like everyone is hailing Responsive Web Design (RWD) as the savior for the mobile site development in 2013. That’s reasonable too, since RWD is currently the only sounding approach that deals with any device resolution universally and effectively. It tries to unite this chaotic browser-based universe littered by the fragmentation resulted from hardware business competition.

responsive web design war
(Image Source: Michael Schmid, Subtle Patterns)

But alas, Responsive Web Design is not the messiah you’re seeking, for it has its own range of imperfections. Yet it is too prominent for the future of web design, and so the conflict incites a flame war among web designers.

Since we strictly practice the philosophy of ‘Make Design, Not War’, today we are just here to explore 5 core disadvantages of Responsive Web Design, and the respective arguments and solutions to lessen the destructive consequences that designers and clients are forced to bear. If you wonder if RWD is the path you seek, be enlightened here.

1. It Burns time to load

The first rule to successful web design: make it as fast as possible. And this is even more important for the mobile user who has comparatively slow Internet connection on the go. However, Responsive Web Design is clearly against fast loading speeds.

That means that if you own a responsive website, there’s a great chance that your competitor’s mobile-optimized website will be way faster than yours. The delay is because to access a responsive website, you have to load all images and scripts of the website first, even if some of them are not required to display on mobile device.

This results the dramatic decrease of site loading speed, taking 7 times longer than a dedicated, mobile-optimized website. Truly a catastrophe especially if you’re doing an e-commerce website, or if your website does not possess enough popularity to risk testing your visitor’s endurance.

website speed influence
(Image Source: Seth Waite)

On the supportive side

Implementation is the problem here. If you don’t want the content, you either don’t load it, or selectively load it – that’s what the conditional tag is for. There are also many engineered solutions available to optimize the loading behavior of the script, such as Adaptive Images which detects screen size and dynamically delivers appropriately scaled images to the website.

Another clever method is to use Lazy Loading, a technique that commands the site to load image content on a later stage, thus putting the text content as the highest priority.

In other cases, you could also switch to a separate stylesheet to prevent any loading of unnecessary or oversized elements.

2. It Breaks A Feature-Driven Website

When a user visits a website on any device, the user expects every core feature – from search to navigation, category to action button. That’s when the problems come in, as the most common approach of the responsive website is to squeeze and pile them into a long, tedious list of functions, sometimes even hidden somewhere. Prepare to see navigation menus crowd your entire screen, or not being able to find a button you actually need

Hide unnecessary features? That’s not an ideal solution, too, since every user has their own preference on certain features, and removing any of them will definitely break usability.

That said, Responsive Web Design is better for a content-focused site, not a feature-driven site. You have to trade your usability for flexibility, while a mobile site development framework such as PhoneGap can solve all the problems mentioned above.

mobile optimized website

On the supportive side:

Although RWD is pretty limited compared to mobile site development framework, there are actually numerous techniques to optimize the usability for responsive web design. For navigation menu, it can be transformed into drop-down menus for mobile devices, and the same method could also be applied to the category section, or you can even implement Accordion layout for subcategories.

Best of all, you could even hide them into a button resting on the top right side of the screen and it will only pop up when it’s required, hence leaving more space for action buttons. All of these can be easily achieved with traditional CSS and JavaScript. No need for complicated development framework.

3. It Disrupts the Advertising Model

Unlike any other web element, advertisement is not something that we, as the publisher, have full control over in the display. Even if we could tweak the ad size to fulfill the requirement of the Responsive Web Design, it will break the deal with the advertiser, as most web advertisement businesses are built on ad placement.

web advertisement placement
(Image Source: Fahrenheit Marketing)

This forces advertisers to re-think about the value of advertising on your site since everything is bound into a pre-defined resolution, and their top positioned ads will possibly be forced to different position of the site, or it will break the layout.

Damned are those websites that rely on advertisement networks such as Google AdSense that do not offer responsive ads. Don’t expect that they will solve the problem for you either. The implementation is rather complicated on their end.

On the supportive side:

It’s quite ‘fortunate’ that most advertisers do not understand much about Responsive Web Design, but here’s a brilliant suggestion for you if they start questioning about the issue – sell the ads as a package.

Simply put, instead of selling a leaderboard ad on desktop version of website that will disappear on certain resolution, include other types of ads exclusive to a set of different device resolution, and sell them as a package.

The whole point is to become responsive with your web advertising model too.

web advertising - responsive model
(Image Source: Mark Boulton)

For Google AdSense, you can switch between the Google ads based on device resolution, for instance leaderboard ad for iPad, banner ad for iPad Mini, and text ad for iPhone. It’s safest to say that this is the only way since you will be potentially breaking Google AdSense’ Terms of Service if you change any portion of the advertisement code, so deal with it.

4. No compatibility for IE 8

On the first day you submit your responsive website to your corporate client, expect him to contact you and ask why the website does not work on his computer. Ask what browser he is using and there is a chance he ran the site on IE.

How do you inform him that his website is not compatible to the browser that currently holds 24% of browser usage share across the world? That totally sounds like the worst decision you can make, but it’s a painful fact that CSS3 media queries, the foundation pillar of RWD, is not supported by Internet Explorer 8 and below.

On the supportive side:

At the time the RWD made its debut, IE8′s compatibility is a huge drawback for the approach, but you can solve this seemingly doomed issue within hours by now, using the Respond.js developed by Scott Jehl.

The script’s effect is pretty straightforward, it supports min-width, max-width and all media types for IE8 and below. Alternatively, opt for CSS3-Media-Queries that supports similar set of features.

There are surely flaws for every script, but it’s far better than seeing the sky falling on your head. It’s not the end of the world though, as only a minority of mobile users browse the Web with Internet Explorer 8.

5. Experience-, Time- and Cost-Intensive

We often tend to hold very high optimism over any technological buzzword that is trending on the Internet (I’m staring at you, HTML5), until we actually apply it to the product. From 4 disadvantages discussed above you can understand that implementing Responsive Web Design requires extensive experience of web technologies and design pattern. It’s insane to reach the goal with trial-and-error method.

device testing
(Image Source: Webmonkey)

On top of that, the approach works under the assumption that the browser will display the design perfectly without bugs. And that, of course, isn’t true. Given the fluid nature of the RWD, there will be unforeseen bugs every time the layout changes its structure according to the screen resolution and orientation.

That means you need to test every resolution on every mobile browser to make everyone of them render correctly. Kind of an overkill for a feature, no?.

On the supportive side:

Unless you are going to display the desktop version of the website for mobile device, any other considerable approach, either mobile-optimized website or hybrid app, will burn as much experience, time and cost as with RWD. And thanks to the effort of all brilliant developers, RWD is now the easiest one to bake and test with relatively low learning curve.

twitter bootstrap

Prevention is better than cure, and preventing browser bugs nowadays could not be simpler, with so many tutorials, frameworks and tools existed to aid the web designers. For beginner, you could kickstart Bootstrap from Twitter to integrate responsive layout brainlessly, and avoid most well-known browser bugs.

For the testing phase, although it’s important to note that it’s always better to test on a real device, online testing services have also improved well enough to significantly reduce your workload, try for example. It even allows you to simulate the view of landscape mode.

Responsive Web Design is not just a feature. Improvements on frameworks, development and testing tools over these 2.5 years positively show that majority of web designers truly believe the Responsive Web Design is the future.


Nothing is more credible than the words of the author who coined the term, Responsive Web Design:

In the end, it’s just an approach, and an approach works best with this good ol’ piece of advice: it depends.

The development flow of RWD should be to figure out the type of website you will be forging, measure the needs and don’ts from your client, inspect the worth and outcome of each mobile approach, then finally decide if the RWD is best suited for the site.

Are you a zealous follower of Responsive Web Design? Or have you implemented the approach before, and discovered that there are in fact more deficiencies lying within this promising approach? Either way, we’re eager to hear your opinion and feedback!