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:http://www.enochs.co.uk – 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. http://enochs.co.uk – responsive, css animated.

So, I did my usual analysis.

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; }
  
  		$("img.q_1").fadeOut();
  		$(".controls.q2").show();
  		$("img.q_2").fadeIn();
  	});
  
  	$(".controls.q2 span").click(function(){
  		var clicked = $(this);
  		$(".controls.q2").hide(); // immediatly hide controls
  
  		if(clicked.hasClass("correct")){ score = score + 1; }
  
  		$("img.q_2").fadeOut();
  		$(".controls.q3").show();
  		$("img.q_3").fadeIn();
  	});
  
  	$(".controls.q3 span").click(function(){
  		var clicked = $(this);
  		$(".controls.q3").hide(); // immediatly hide controls
  
  		if(clicked.hasClass("correct")){ score = score + 1; }
  
  		$("img.q_3").fadeOut();
  		$("#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() {
  </li>
  

• 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