Responsive Web Design Performance tweaks for e-commerce and applications

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

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.

Reduce Bloat

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.

Reduce Unnecessary DOM JavaScript – KISS

This is probably the worst type of bloat. While JavaScript is the programming language of the web and most all modern HTML pages are using it, overuse can negatively affect a user’s opinion of your site. I like to use the KISS ( Keep It Simple Stupid ) approach and minimize DOM access. DOM is one of the most complex APIs that slows down the code execution process. We’ve all experienced websites that overly manipulate the DOM. They are jumpy, slow, and feel buggy. Try to reduce it unless it provides a direct and measurable improvement to UX.

Use Grunt

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

Whether responsive or not, I think this is one of the most overlooked tweaks that has significantly reduced our total load times. By using Grunt coupled with grunt-contrib-concat you can move all your JavaScript into one file and all your CSS into one file. That single file will take longer to download but as a whole will reduce the overall load time of your page. Combining scripts into as few files as possible cuts down on RTTs and delays in downloading other resources. The same practice can be used for CSS as well as the use of CSS sprites. The overall fewer number of total requests, the better. Start using Google Chrome’s Developer tools and Network tab to begin diagnosing and cutting back. There are always exceptions so having only 1 JS or 1 CSS file may not be feasible but it is a great goal.


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 today.


Otreva is a custom software product development company focusing on user experience, responsive web development, & mobile application development.

Interested in seeing what it costs to build an app?

Start Quote See Stats
224 Wyoming Ave. #100
Scranton, PA 18503

You've found the secret footer!

Tweets about @Otreva

Or check us out on:

Shopify Experts