Responsive Design – Why are we doing it wrong?

@guypod did an excellent presentation at the recent @bdconf and discussed his concerns on Mobile Web performance. According to his presentation choosing mobile design paradigm is hard, and performance is an often overlooked parameter in this decision process.

I have always been a strong proponent of performance. For me it is not important what methodology is used, mdot or rwd, but how the site performs for an end-user. @beep revolutionized the way we look at website development with his Responsive Design methodology. When done right, it provides excellent benefits over mdot websites. However, I am a bit disappointed to see the design choices made by the community while developing Responsive Design sites. In my previous article, I talked about how you can be successful with Responsive Design. As @brad_frost eloquently put it in his recent article, it does seem everyone is still trying to out-mediaquery each other to create Responsive Design websites. Using Media Queries and writing styles for each break point is not hard, in fact it is quite simple. The harder part of Responsive Design is Information Architecture, Creative Design and how you collaborate to make smart decisions to create creatively rich, user friendly websites that perform highly.

According to a new article published by Google, Mobile websites are 1.5x slower on average. This is definitely a bit disappointing. Users expect Mobile sites to be faster or at least as fast as their desktop counterparts.

This brings me to the highly publicized Responsive site of the week by @wilto.

He tweeted.

  • Not that I’m excited to have this live at last, but: – Responsive, CSS Animated, & Design led.
  • Thanks to @viewcreative for a cracking new website…awesome! Check it out.
  • Good week; praise from Zeldman, and my latest site build got lovely comments too. – responsive, css animated.

So, I did my usual analysis.

Total Size Scripts CSS Images
Desktop 1.23MB 123KB 84KB 930KB
Mobile 854KB 123KB 84KB 522KB

I also did a MobiTest to double check my results.

Both these tests show disappointing results. Page weight of 800+ kb with a load time exceeding 8 secs in my opinion, is not a good performing site.

There were few simple things done incorrectly that could have improved the performance of the website significantly:

  • GZIP compression is not enabled.
  • CSS and JS files are not minified.
  • Modular design is mising. Everything is tightly coupled to each other and the DOM. What if we want to add another tab to the “tabbed area.” You have to edit JS and add lines for each item.
  • Prepend is used to add images. Prepend is expensive (memory-wise) and img tags in the JavaScript are worse than the markup alone.
    /* add the images */
       $("#game").prepend("<img src='/assets/images/game_bg.png' alt='' />")
                 .prepend("<img src='/assets/images/game_1.png' alt='' class='q_1' />")
                 .prepend("<img src='/assets/images/game_2.png' alt='' class='q_2' />")
                 .prepend("<img src='/assets/images/game_3.png' alt='' class='q_3' />");
       /* add the 'controls' */
       $("#game").prepend("<div class='controls q1'><span class='a_1'>one</span><span class='a_2 correct'>two</span><span class='a_3'>three</span></div>")
                 .prepend("<div class='controls q2'><span class='a_1 correct'>one</span><span class='a_2'>two</span><span class='a_3'>three</span></div>")
                 .prepend("<div class='controls q3'><span class='a_1'>one</span><span class='a_2'>two</span><span class='a_3 correct'>three</span></div>")
  • Lack of reuse:
    $(".controls.q1 span").click(function(){
    		var clicked = $(this);
    		$(".controls.q1").hide(); // immediatly hide controls
    		if(clicked.hasClass("correct")){ score = score + 1; }
    	$(".controls.q2 span").click(function(){
    		var clicked = $(this);
    		$(".controls.q2").hide(); // immediatly hide controls
    		if(clicked.hasClass("correct")){ score = score + 1; }
    	$(".controls.q3 span").click(function(){
    		var clicked = $(this);
    		$(".controls.q3").hide(); // immediatly hide controls
    		if(clicked.hasClass("correct")){ score = score + 1; }
    		$("#game").append("<span class='score'><b>"+score+"</b> out of <b>3</b><br/><span>Play again?<span>");
  • Waiting for onload? Might never happen. Better to use domready or scriptready:
    =events to run after the entire page has finished loading */
    $(window).bind('load', function() {
  • Massive CSS file size with browser prefixed animation keyframe code. Probably better to add the CSS transitions via JavaScript or conditionally load the browser-specific CSS.

What is more disappointing is that it was done by @wilto, who in my opinion is a leader in the Responsive Design community. @rwd even tweeted about it. If leaders make mistakes, community will follow. Inorder for us to showcase the power of Responsive Web, we need to discourage sites like these.

Contributions from: @JohnnyReading, @mutootum

Posted in Blog, Responsive+ Design, UI Performance, Web Development
1 Comment » for Responsive Design – Why are we doing it wrong?
  1. Matt Wilcox says:

    Hi there,

    Thanks for picking this up :) A lot of what you say is good advice. Unfortunately however, you’re missing a bit of context as to *why* certain decisions were made…

    The site is indeed too large for my liking in terms of file size – however the client specifically wanted the look to go with the established brand, and the purpose of the site was to push visual design as far as possible in a responsive medium. The increased weight of the site was the compromise the client and design team were willing to go with in this case.

    GZIP is a good point, I do not know why that server is not sending GZIP assets, because it should be.

    The JS and CSS are left uncompressed deliberately. Given the size of the site, compressing them makes no practical difference – except that it makes it impossible for other people to learn from. And I’m a big fan of commenting and letting people inspect intelligible source material. So it’s left like that as an implementation decision.

    Modular design is irrelevant here. The site was conceived from the start as a single page which would not be expanded in any way. It is this which allowed us to go to extremes on the visual design.

    I’d be interested in what you’d suggest instead of prepend for the images. Bare in mind that these images are only ever added if the device has JS enabled and is also capable of translate3d animation. They should not be in the mark-up raw.

    Lack of reuse is a fair comment, but for such a tiny part of the system, not really worth the effort (I’m not yet a JS guru and the time taken for the benefit of a few saved bytes didn’t seem worth it).

    There is nothing wrong with onLoad. It does exactly as wanted, because I don’t want domready or scriptready. I am waiting for the images to finish – which is why it uses that and not the others.

    Massive CSS size; yep, that’s what happens when you support as many engines as you can in a design intended explicitly to push the boundaries. And it’s done in CSS for performance, JS could never hack the animations on mobile devices.

    The problem with your criticisms here are that you were not aware of the important parts of building a website: the needs of the client and why the design decisions were made. You’ve just done a simple tear-down – which is of no relevance when the goals of the site are not the goals you assume.

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>