Responsive web design has come a long way in just a few short years since being introduced. It has allowed development shops like ours the ability to help out clients reach their end user regardless of what screen size the device they are using is. Responsive design takes an interesting approach to the problem mobile has caused for many sites in the past. Up until recently it was considered that having a desktop site codebase and a separate mobile site codebase was the way to handle this situation. While it still is the best approach for a few scenarios, the majority of of use cases can benefit from responsive design. However the biggest problem with responsive design is when it is created by the wrong hands. Many web developers have moved into the responsive space after being used to the fixed width sites of the past. However responsive design requires an entirely different mindset when prototyping sites and creating an amazing experience. While many have figured out how to make responsive work while changing the width of their browser window, fewer have understood the impact or performance on a real mobile device. While today’s smartphones are amazing, they still are slower in terms of hardware performance as well as mobile network performance. Things are getting better with each new phone released but we should always consider that performance plays a huge role in our end user’s experience. According to Internet Retailer, a 1-second delay in web site page load time translates into a 7% loss in conversions, according to research firm Aberdeen Group Inc. So if an e-commerce store owner makes $100,000 a day from its mobile site, a 1-second page delay could mean around $2.5 million in lost sales every year. Here are some of the tips and tricks we’ve learned over the last few years to ensure we have a great performing website regardless of which device or the speed of the user’s connection.
Mobile first has drawn a ton of attention over the last few years. It is the best method to take when designing responsive applications because it allows you to focus on the smallest screen and work your way up. Typically working the other way around yields “mobile” experiences that feel clunky and are hard to navigate as well as sometimes impossible to use on a mobile device. Using Foundation we’ll typically create our sites 100% in code first to get an idea of the prototype.
Media & Content Conditional Loading
We use Foundation’s interchange component to help us deal with the appropriate content for a variety of screen sizes. The number one error we see in other responsive sites is that many don’t take into account that users on mobile connections can’t support the same huge media that desktop users have taken for granted. Interchange allows us to easily handle that for a variety of screen sizes from smartphones on up. With just a small change to your HTML markup, you can conditionally load not only images of different sizes but any HTML content including something like Google Maps.
While this may a bit more generic of a tweak, it is something I always like to keep in the back of my mind. A great user experience starts with giving the user exactly what they came for. While this may be obvious, I can’t tell you how many times I use sites that have all types of animated effects, color, and media yet have no clearly defined (of functioning) mobile navigation or it is hard to find given all the other features they’ve spent their time on. From when I start with a prototype up until final testing and even launch, this is a moto I like to kepe in the back of my mind. I’m not trying to avoid using new features and/or well placed animations, but just head over to themeforest and try some of those themes on a mobile phone and I think you’ll understand why reducing bloat is so important. Our goal is to try and keep sites under 500kb regardless of screen size and even smaller for devices that are likely to be using mobile broadband. I personally try to reduce size wherever possible.
We’ve recently converted all of our boring, annoying redundant tasks over to Grunt tasks. What and why use grunt? Automation. Every project we start begins with setting up a Gruntfile and specifically the compressed obfuscated JS and SASS / CSS components but we’ve found we can automate almost any redundant task at all. We’re even using grunt to run shell commands to do a variety of tasks for us every day. For those of you who have not heard of grunt, stop now and go check it out. Also check out the livereload feature of grunt-contrib-sass. With livereload you can connect multiple devices to your same development site and easily watch every device with each page refresh, scroll and update.
Minimizing HTTP Requests
By using gzip or deflate you can reduce the number of bytes sent of the network. While the specifics to enabling compression on your site and server are undoubtedly different for each case, compression in general is one of the easiest ways to boost performance.
Use a CDN version of jQuery and other libraries
Definitely make use of Google’s hosted libraries for jQuery and other popular platforms. While this MAY goes against the above rule for minimizing HTTP requests, typically it will only help. When you use the Google hosted version of jQuery you are not only helping users on your site but other webmasters and users. Let’s say it is the first time a user visits your site in a newly installed browser or they just cleared their cache and cookies. If you have the hosted version setup, this means that yes, they will have to download the jQuery version from the Google Hosted library. But from then on, it’ll be cached for not only your site, but any other website using that same version. Chances are (for jQuery at least) a user already has a cache version when they come to your site.
I hope these tips, tweaks and best practices help some of you. Use the tools available to you and make sure you aren’t overlook the performance of your site. Test your site at http://www.webpagetest.org today.