Performance Implications of Responsive Design – Book Contribution

I had the pleasure of writing a small contribution to Tim Kadlec‘s awesome upcoming book “Implementing Responsive Design”. The book is a great pragmatic guide for how to build a responsively designed website, including the basics, advanced use-cases and practical advice on how to overcome the challenges RWD faces today. You can read more about it and pre-order it today here.

The book includes some great contributions from top thinkers in the Mobile Web space, and I was honoured to be included in that list. My contribution is related to my recent “Performance Implications of Mobile Design” presentation from a recent Breaking Development conference, and it’s included below to help you bridge the gap until you buy the the full book!

Performance Implications of Responsive Design

Responsive Web Design (RWD) tackles many problems, and it’s easy to get lost in questions around how maintainable, future friendly or cool your responsive website will be. In the midst of all of these, it’s important to not lose sight of how fast will it be. Performance is a critical component in your user’s experience, and many case studies demonstrate how it affects your users’ satisfaction and your bottom line.

Today, smartphone browsers often get redirected to dedicated mobile websites, known as “mdot sites”, which tend to be significantly lighter in content and visuals than their desktop counterparts. This translates to having fewer images, scripts and stylesheets to download, which helps make those websites faster. The equation is simple – downloading fewer bytes with fewer requests is faster than having more of both.

Responsive websites, however, don’t follow this pattern. I recently ran a performance test on 347 responsive websites (All the websites listed on in March, 2012). I loaded the homepage of each in a Google Chrome browser window resized to 4 different sizes, ranging from 320×480 to 1600×1200. Each page was loaded multiple times using, a web performance measurement tool.

The results were depressing. Despite changing their look across window sizes, the weight and load time of the website hardly changed. 86% of the websites “weighed” roughly the same when loaded in the smallest window, compared to the largest one. In other words, despite the fact the websites look like an mdot site when loaded on a small screen, they are still downloading the full website content, and are thus painfully slow.

While every website is different, three causes for this over-downloading repeated across practically all websites:

  • Download and Hide
  • Download and Shrink
  • Excess DOM

Download and Hide is by far the top reason for this bloat. Responsive websites usually return a single HTML to any client. Even on “Mobile First” websites, this HTML contains or references all that’s needed to provide the richest experience on the biggest display. On a smaller screen, sections that shouldn’t be shown are hidden using the “display:none” style rule.

Unfortunately, “display:none” doesn’t help performance one bit, and resources referenced in a hidden part of the page are downloaded just the same. Scripts within hidden sections still run. DOM elements are still created. As a result, even when hiding the majority of your page’s content, the browser will still evaluate the page in resources and download all the resources it can find.

Download and Shrink is a conceptually similar problem. RWD uses fluid images to better match the different screen sizes. While visually appealing, this means the desktop-grade image is downloaded every time, even when loaded on a much smaller screen. Users cannot appreciate the high quality image on the smaller screen, making the excess bytes a complete waste.

Excess DOM is the third episode of the same story. RWD websites return the same HTML to all clients. Browsers parse and process hidden areas of the DOM despite being hidden. As a result, loading a responsive website on a small screen results in a DOM that is far more complicated than what the user experience demands… A more complicated DOM leads to higher memory consumption, expensive reflows, and a generally slower website.

These problems are not simple to solve, since they’re the result of how RWD and browsers work today. However, there are a few practices that can help you keep your performance under control:

  • Use Responsive Images
  • Build Mobile First
  • Measure

Responsive Images are already discussed in this book at length, and help address the “Download and Shrink” problem. Since images are the bulk of the bytes on each page, this is the easiest way to significantly reduce your page’s weight. Note that CSS images should be responsive as well, and can be replaced using media queries.

Build Mobile First means going a step beyond designing a Mobile First website, and actually coding a dedicated website for the lowest resolution you care about. Once implemented, this website should perform as well as other mdot sites, and be reasonably lightweight. From that point on, only enhance the page using JavaScript or CSS, to avoid over-downloading. Clients that have no JavaScript support will get your basic experience, which should be good enough for these edge cases. Note that enhancing with JavaScript and keeping performance high isn’t simple, and best practices for it are not fully established yet – which brings me to my next point…

Measure. Treat performance as a core part of your website’s quality, and don’t ship without understanding and accepting its performance. If you know your mobile website weighs over 1 MB, you’re likely to delay its launch until you do something about it. Measurement tools vary, but I would recommend Mobitest for testing on real devices and WebPageTest for testing on desktop browsers, resized using the “setViewPortSize” script command.

In summary, Responsive Web Design is a powerful and forward thinking technique, but it also carries with it significant performance implications. Make sure you understand these challenges and design to avoid them, so that users won’t abandon your website before they got to experience your amazing visuals and content.

Posted on July 11th, 2012
  • Christopher Galvin

    Oh c’mon. Responsive design was never promoted as or intended to be a mechanism for having a correlating increase or decrease in load time based on screen size, just a way to move the same content around in the space provided so users can consume it instead of having to manipulate it into a usable form first. The CSS and thus bandwidth required to do this should be negligible on a regular Wifi or 4G cell connection–if yours isn’t, or God forbid you’re creating 1MB-weight pages, the design (responsive or not) should be reconsidered anyway. The perceived speed with which a reasonably sized page loads on a desktop, tablet or phone has more do to with number of people using the network or whether your idiot neighbor is chewing up the neighborhood cable with torrents or online gaming than whether you’re hiding a headline or JPG. If you really care about milliseconds, then sure, do an MDOT site if you have the resources. Otherwise, responsive design is still a lovely and cheap way to have your content ready to consume on pageload.

    • Guypo

      While I agree responsive design isn’t meant to help performance, most people lose sight of the fact it can hurt it. And I disagree with your statement about what matters for page load time – the makeup of your page, including its weight and layout, has a dramatic impact on how quickly it loads. 

      When you’re in a bad network, like a 3G connection or when your neighbour is playing online games, the make-up of your page matters even more to its performance. This delta is measured in seconds, not milliseconds, and a properly designed responsive site can easily be 4x faster on a high-latency mobile network than a naively designed one. Just run a quick test on Smashing Magazine’s page through Mobitest ( and you’ll see.

      All that said, the purpose here is not to keep you from using responsive design. I’m a fan of RWD, and think it’s the way of the future. I’m just looking to raise awareness to the problems it creates, and suggest solutions to those.

  • Sérgio Lopes

    Hi Guy! Nice idea to bring the performance issue to the rwd community.

    I only disagree with your initial argument: “In other words, despite the fact the websites look like an mdot site when loaded on a small screen, they are still downloading the full website content, and are thus painfully slow.” This statement seems bogus to me. RWD is exactly about bringing the same content to mobile and desktop.

    The problem isn’t the same page size in mobile and desktop. The problem is that this size is usually very big. All my pages have the same size (bytes) on mobile and desktop. But, in my case, it’s usually ~150KB for both scenarios. I mean, the problem isn’t the same content; the problem is to deliver old-big-desktop-like sites to mobile. Mobile first should solve many cases here.

    I think we should talk about web performance in general, and advocate in favor of Mobile First. If you optimize your page to mobile, this improvement should be available to desktop users too!


    And I missed some advanced discussions about performance. Like RESS, mobile first and conditional loading. 

    • Guypo

      I agree that what really matters is the actual weight and load time of the page. However, I see a difference between having a heavy page for the sake of rich graphics and functionality and having a heavy page where 90% of it is hidden. Some would make the claim the rich functionality provides enough value to justify the performance hit, but I don’t think anyone actually chooses the latter…

      In addition, smartphones would often access your website over slower (cellular) networks, meaning the cost of a heavy page is higher for those clients – more so than for a desktop client. 

      There’s definitely a lot more to say about RWD performance – this is just an excerpt I contributed to Tim’s book, I’d highly recommend buying the book for a more comprehensive list of techniques and code samples.

  • Keith

    Great article, I’ve been looking for another view on this for a while now. Coming from an e-commerce background where slow site performance means a loss of sales this is a crucial part of the picture that shouldn’t be neglected just because responsive design is the cheap option.

  • Enej

    Great Article, I am glad to see that projects like are developing possible solutions that might bridge this gap. 

  • Madt Team

    Great things, I tried a different point of view on this issue for a while ‘time. The advent of e-commerce website fold gradually yields indicates a decrease in income is an important product of the image that should not be ignored just because Slim is a convenient alternative.

  • micahgodbolt

    Hey Guy, great to see that you address the idea of “Build Mobile First” rather than just designing the mobile layout first. I’m a huge fan of this idea, creating an experience for the lowest common denominator and then using conditional loading to enhance the page if viewport or device capabilities allow for it.

    I’m a bit surprised that you left this conversation out of your most recent article “” – I think my biggest beef with that article was the omission of this “Build Mobile First” idea.

    Regardless, thanks for keeping this great conversation moving forward.

    • Guypo


      I didn’t completely leave it out of the other post, I did link to it. That said, my intention in the new post was to clarify that while you can – and should – make responsive websites dramatically faster, there *is* an inherent performance penalty you can’t entirely shake off.

  • Skip Vanderburg

    Mobitest worked great for our responsive web mobile test. Thx!

  • Conrad Kleinespel

    Great article, Guy ! I have read a lot about “mobile first” but the performance aspect is often a afterthought. I like how you’re seeing performance as a feature here. In particular, this sentence made me think:

    “From that point on, only enhance the page using JavaScript or CSS, to avoid over-downloading.”

    That seems like a logical thing to do, but I tend to forget about it when coding, because I’m always testing in Chrome on a good laptop first. By the time I get to the mobile device, everything is done and it’s hard to re-do everything.

    I guess what I’m trying to say is: thanks for the reminder not to let mobile users become an afterthought ! :-)