• 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 (mobitest.akamai.com) 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.

  • http://twitter.com/sergio_caelum 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 http://www.mobify.com/mobifyjs/ are developing possible solutions that might bridge this gap. 

  • http://www.mobileappsdevelopmentteam.com/ 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 “http://www.guypo.com/technical/responsive-web-design-is-bad-for-performance-there-i-said-it/” – 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.

  • http://twitter.com/skipvanderburg 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 ! :-)

Back to top
mobile desktop