Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Opinion Column Why Responsive Web Design Has To Win Out

When considering a mobile Web strategy and weighing responsive Web design against a separate mobile website, the most important metric is how functional the website is for the user. This goes beyond better content organization for smaller screens. Mobile (and desktop) websites should be easily found, easily shared, fast loading, easy to maintain and easy to build on.

If we keep that in mind, considering where the Web is today and where it looks to be going, there are many compelling arguments for responsive Web design.

Further Reading on SmashingMag: Link

Setting The Stage Link

Consider something as simple as Google Doodles5. These small updates create major buzz for Google, and they offer a bit of surprise on an almost daily basis. Then consider how websites like Facebook update their code base twice a day6. Both cases hint at a future where users will expect content and features to evolve faster than ever.

On top of new content demands, people are also sharing information more than ever, creating the need for centralized, up-to-date content and a reliable way to access that content.

Unfortunately, those aren’t the only challenges created by this evolving Internet. Those problems can, however, be solved using responsive Web design.

Before I get into the specifics of why I believe responsive is better now and in the future, I’d like to clear one thing up.

The Content Myth Link

To frame this whole debate, it’s important to forget an old myth7. It’s the belief that content should be restricted, dumbed-down or eliminated for mobile users based on their goals and intent.

Up until now, limiting content made some sense. Especially in the early days of the modern mobile Web browser. Today, however, it is widely accepted that we don’t know anything about our users’ goals based on which device they are using. Users need and expect full functionality on their mobile device, because they could be using it anywhere, for any reason. 28% of American adult smartphone owners now access the Internet mostly on their mobile device. That means that many of your users literally require all of the same functionality on mobile that they would otherwise get on a desktop.

We can’t eliminate content or functionality, but we also can’t show everything at once on a small screen. This means we need to redesign and reorganize content into smaller “views” and hide or hint at secondary content in smart ways. This isn’t necessarily easy, but it’s necessary.

Quartz's menu is hidden and hinted at on small screens.
Quartz’s menu is hidden and hinted at on small screens. Larger view9.

Now that we know the facts — that we have to restructure content, but not eliminate it — there are two ways to achieve this. One is with responsive Web design, and the other is a separate, mobile-focused website.

Consistent URL Structure Link

URL structure is very important on the Web today. Your website and its content get shared in many different ways, from different places, on different devices. People find your URLs in search results, they click on your ads, they get to your blog from Facebook and they get information about your company emailed to them from a friend.

The device that your users share a link from will dictate the specific URL they share, and if that doesn’t match the device the link is viewed on, there’s a chance that the user receiving the shared link will see a confusing or misleading layout. We can fix this with redirects, but as we add more complexity and functionality into mobile websites, this becomes a serious task to manage. It’s often not done correctly.

We’ve all clicked on links from a search engine, an email or a tweet that take us to the wrong version of a website. For example, your friend wants to email you a Wikipedia article. They’re on a phone, so they email you the link, and you open that link on your laptop. You’ll see a single column of copy that spans the entire length of your 13 inch screen. This is annoying, but more importantly, it confuses and discourages visitors.

Wikipedia Mobile viewed on a laptop is a single column of copy that spans the entire length of the screen.11

Wikipedia Mobile viewed on a laptop is a single column of copy that spans the entire length of the screen. Larger view12.

SEO Link

Furthermore, and are different URLs. If redirects aren’t structured properly, search engines and analytics may not realize that two URLs serve the same content on different devices. Search relevance and analytics reporting can easily get splintered.

Even more detrimental is a URL structure that’s completely different for mobile. Instead of just adding the m. prefix to the URL, some mobile websites have a completely different page structure for mobile. This should absolutely be avoided, separate website or not!

Google, just one search engine, is taking measures to index and serve up the correct versions of websites, but we can’t rely on a computer to realize that two different URLs with the same content should be indexed, ranked and weighted as the same page. So to make sure Google indexes your different URLs properly (and fairly), you need to follow their guidelines and add extra code. Google shows you how in a tutorial13, but at the top of the page, they make it clear that for SEO, responsive design is “Google’s recommended configuration.”

Google recommends responsive Web design for optimal search indexing.
Google recommends responsive Web design for optimal search indexing. Larger view15.

Load Time Link

We need to keep the same page structure and the same URLs, but we should organize the display of the content based on the device. That presents a specific challenge for responsive design, though. Load time.

When using one code base to reorganize content, we inevitably create extra divs and other elements that get hidden. On mobile devices, over data networks and with limited processing power, this is an issue because whether they’re hidden or not, your phone loads all of the elements in your code.

Smart and efficient coding can minimize this load time. Sometimes people mistake responsive Web design for “time-saving” development, but in reality, coding responsive websites correctly is hard. Minimizing load time requires expertise in coding and a solid knowledge of how code and browsers work. But for the most part, a good developer can achieve speedy loading when it comes to text and other “light” content.

Images, however, are a much more serious challenge. Today, there isn’t a great answer.

Images Link

Images on responsive websites need to be large enough for a huge screen, even though they get sized down visually for small screens. So we create them large, but then our mobile websites suffer because we still have to load that full-size image. With bandwidth, cache size and processor limitations, this is not ideal.

There are plenty of responsive image solutions in the works for the future, like the picture element16, and there are groups like the Responsive Images Community Group17 (RICG) who are looking for long-term, standards-based solutions. Still, there are no great solutions today to make sure that your images get served at an efficient file size or that they crop well when screen real estate is limited.

There are some workarounds, though. There’s Adaptive Images18 to swap images out at breakpoints. There’s jQuery Picture19 and Picturefill20 that simulate the functionality of the proposed picture element. For the proprietary platform my company builds on, we’ve created a jQuery plugin (released open source at Responsive Img21) to efficiently handle switching images at different screen sizes. Although it solves load time issues, it still relies on JavaScript and isn’t a permanent, long-term solution.

At some point, there will be a solution. Today, 90% of the time, this issue is more of an annoyance than a complete roadblock. As data connections get faster and mobile phones get more powerful, it becomes even less of an issue. That, combined with the promise of future code standards for responsive images, means someday we won’t worry as much about load time issues with images, and we’ll have even less reason to do anything but responsive Web design.

I don’t want to downplay the load time issue, though. There are cases — certain websites that are too image-heavy or where complexity exaggerates the load time issue — where a separate website may still be smarter. Just like adding load time through responsive design, using a separate website is a compromise. It needs to be a calculated decision. Most responsive websites, especially with the help of JavaScript, can still squeak by with acceptable load times and reap all the additional benefits of responsive Web design.

Content Updates And New Features Link

What won’t change in the future is the increasing need for agile websites that improve and adapt based on user and Internet trends. We’re updating both content and functionality more and more frequently. With responsive design, we only need to add functionality to a single code base, saving time and creating focus. The amount of time it takes to maintain separate versions of the same website is often underestimated.

Furthermore, iteration is a growing key to successful modern websites. It’s becoming a necessity for websites today to get regular feature updates and add-ons, especially for e-commerce and Web apps. There’s so much data available on how people use your website that it’s an oversight not to adjust your user experience based on that data. At some point, maintaining and improving multiple versions of the same website means that time and money either go toward adding fewer features to both versions, or more features to only one (probably the desktop version). My company has a client that serves as a perfect example.

We’re retained to maintain and update a website we didn’t build, which has a completely separate mobile version. This large, corporate client has good analytics data, so they have lots of improvements and new initiatives for the website in the pipeline. Since we only have so many hours in our monthly retainer, and because the wish list of fixes and features exceeds those hours, we typically end up adding all the great new functionality to the desktop version only.

Right now, the mobile experience is far behind the desktop experience, and it doesn’t look like that will change anytime soon. There just aren’t enough hours. Yet, they’ve run campaigns based around QR codes and have promoted mobile use of their website at events.

In some ways, this is a huge oversight. In another way, it’s just an unavoidable problem caused by having a separate mobile website. For our client, it’s hard to argue that it’s smarter to release fewer new features for more website versions. They’d rather see initiatives go live then spend time and money maintaining the mobile version. With good reason, but with bad results.

This All Adds Up To One Link

To summarize, we know a few things. We know that all content and functionality needs to be available for mobile users. We know that today, URL structure is important. We know that load time is important, but it will one day be less of an issue. We know that websites need to always evolve, and that it takes time to implement changes and new features.

If you look at those factors in total, responsive Web design has to win out.

That said, coding technique and mobile strategy should still be considered individually for each project. There are times when images are too important, when functionality is required to be very different or when target user demographics prohibit responsive design. In my opinion this rarely happens, but it’s good to remember that responsive isn’t a blanket solution that fixes all of the Web’s issues.

One last thing. Don’t forget that for every separate mobile version you’re building and maintaining, a separate tablet version and TV version are right around the corner.

No matter how many versions you support, if you’re using separate websites, you’re supporting too many. Ideally, you should only have to support one. Responsive design makes sense today. It makes more sense tomorrow.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8 /wp-content/uploads/2012/11/qz.png
  9. 9 /wp-content/uploads/2012/11/qz.png
  10. 10
  11. 11 /wp-content/uploads/2012/11/m.wikipedia.png
  12. 12 /wp-content/uploads/2012/11/m.wikipedia.png
  13. 13
  14. 14 /wp-content/uploads/2012/11/googleRecommends.png
  15. 15 /wp-content/uploads/2012/11/googleRecommends.png
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21

↑ Back to top Tweet itShare on Facebook

Drew Thomas is an entrepreneur, a consultant, and an ecommerce expert. He's currently working on an ecommerce platform called Really Simple Store. He previously cofounded and ran Brolik, a digital agency, as CCO and then CTO. He lives in Austin, TX.

  1. 1

    Great points made Drew. This has really just changed my perspective on pitching clients with mobile vs responsive. The opening argument about not knowing what the mobile user’s intent when browsing a website just clicked with me. The closing statement concerning supporting multiple [mobile] sites vs ONE responsive site is so true and so important in the long run.

    For me responsive just requires more planning up-front for a better experience and the longevity of a site. But I would much rather commit to more planning, than having to update 5 (or more) versions of the same site and make sure they all function appropriately.

  2. 2

    Great job taking a common sense approach to a complex subject.

  3. 3

    Well put together article. I am also trying to argue in favor of responsive design instead of mobile for the same reasons that you have outlined. Unfortunately, many larger corporations are slow to respond.

  4. 4

    Thanks everyone. Glad it connected.

  5. 5

    Agrodut Mandal

    February 18, 2013 9:26 pm

    These days, everyone is jumping on the responsive bandwagon. Apart from responsive layouts, everything is going responsive: sliders, lightboxes, galleries, you name it!

  6. 6

    I agree with a lot of what you are saying. However, i also feel it relates mostly to Simple content web sites. when you are dealing with complex web applications, not placing all the content also makes sense. Obviously users will not perform complex tasks on their mobile. In addition responsive design may result in a very complex UI.
    What is your take on complex web applications?

    • 7

      Joining the conversation late but…

      Actually… users will do complex tasks on a mobile device if they feel it’s secure, and they can accomplish what they need to do within a simple, intuitive workflow, (even if that work flow is more taps/clicks than what would be needed on the desktop site).

      For content – you may not want all of the content displayed the same way as a desktop site, but you do want to allow the user to drill down if they want to. If you omit content the user will have no choice but to leave your site and go to another.

    • 8

      Drew Thomas

      March 7, 2013 6:36 am

      That’s a great point about a more complex web application.

      I’d argue that, while it would be more challenging, it’s still beneficial to build a complex web application responsively. I think it brings up another issue, which is that responsive design is hard to do well. It seems like people forget that and think of responsive design as a “magic” solution.

      When a complex web application is built responsively (and built well), it will present challenges upfront, but it will have serious benefits down the road. Site maintenance is often overlooked, especially when working on “one-off” projects for clients, but the ability to add and adapt features easily is a huge advantage. Especially with a web app.

      That said, if the developer codes the app poorly, you’re right… responsive design could definitely hurt the user experience.

  7. 9

    Why does responsive have to win out? Sounds like a whole world of dev pain to me. What happens when the paradigm shifts again and responsive ends up being a dumb solution? Responsive may seem smart, but is it really?

  8. 10

    Thanks, Drew, That was a good and informative article!

  9. 11

    Drew, thank you for such a sophisticated article! Would be great to hear your opinion on a responsive design tool called Froont we are developing! We are launching a private beta to signed up users and you can sign up at, or ask me for an invite directly.

  10. 12

    Even if I am not a big fan of using JavaScript for layout concerns, I have to say your approach is pretty impressive.

    It seems not only to work like a charm but also to give solutions to complex issues.

    Very well done

  11. 13

    Thank you so much for great article. This article opened my mind for the possibilities.The concept of a responsive design really got me, I had to play around with it on my recent work.I think Responsive website design might turn out as a great way to progressively enhance even small budget projects for mobile devices.

  12. 14

    Had a chance to play with responsive web applications recently. This articles summarises most of my learnings.
    Content management, less code maintenance due to one code base and feature enhancement in agile way are quite helpful.
    Liked the article very much.

    How about device detection strategy? Would like to know your views.

    • 15

      Sorry for the really late response. I just saw this comment.

      Thanks for the kind words.

      To answer about device detection… in an ideal world, device shouldn’t matter. That’s one of my favorite things about responsive… it will work everywhere no matter what the device is. As humans and technology evolve, there will always be new devices and new use cases, so detecting and developing for specific devices isn’t super sustainable.

      There are situations, however, when device detection is necessary. I would consider that equivalent to any other “one off” or “custom” feature that a website might need, and I’d just research what’s out there as far as browser detection scripts, and then implement one for whatever specific reason I needed it.

      For the most part, though, I try to think in terms of screen size, not device.

  13. 16

    I like the main ethos of this article, but I think you should stress even more strongly the “response to device type” part.

    I’m feeling increasingly frustrated at the effect smartphones are having on websites – they were becoming as rich and full of functionality as windows applications as the languages and technology matured.1

    Now they’re increasingly simple and resorting to much plainer interfaces, because they’ve got to be smartphone friendly. A lot of things are possible on the PC that just don’t work on a phone.

    On a website for a paint manufacturer, there used to be a wonderful interactive grid of colours with hundreds of shades available at the click of a mouse. Now it’s been made smartphone friendly,you have to navigate up and down through pages of colour sections, and the whole site looks large and blocky.

    A lovely web site spoiled by the smartphone – or should it be the “dumbphone”

  14. 17

    Hi – nice article, but yet again, design seems to be an ‘also ran’. Why not do what the BBC have done – have one site for desktop/tablet where you can control the design/experience for all users, and a responsive mobile site to cater for all other mobile devices specifically designed with these users in mind. If using a single CMS why couldn’t this be used to populate both sites content?

    You could use a fork to eat soup with but a spoon gives a better experience. Ok bad analogy but you get my point!

  15. 18

    I always tell my clients they should seriously consider responsive! If they don’t want to, or can not pay we offer them to do it later but way more expensive.

    By the way, the Porsche website is a great example for a complex, responsive, yet intuitive site. :)


↑ Back to top