If you haven’t heard of “Responsive Design” before this point, I want you to do something for me. If you’re reading this on a desktop, please reach over to the side of your browser window and resize it. Scale the width to about half. Then scale it down further. Keep going until you can’t scale it down any more.
Don’t just read on ahead to see where this is going. Seriously, do it right now.
Pretty cool, huh?
Since I’m assuming you’re reading this on www.loadstorm.com, you may have noticed something interesting happen to the page elements as you scaled. Everything shifted around to fit within the new width and the navigation changed to a drop down menu.
Okay, what’s the big deal? So it changes when I resize the page, who cares? It’s a big deal because this means our website is device independent. No matter what screen you view it on – mobile phones, tablets, desktops, laptops, old machines, new machines, portrait, landscape, anything – our site will react to that device and automatically change the layout to best suit its screen size. This is the principle behind responsive design: Creating fluid layouts and using media detection to give the user a website fit for their screen.
Here’s a site that lets you see this concept in action: http://mattkersley.com/responsive/
That’s cool and all, but what does this have to do with performance?
I’m getting to that. Prior to this approach, web designers would use an “mdot” website which would redirect the user to a “mobile” version of the website they wanted. It’s called mdot because it typically has a subdomain “m.example.com”. I’m going to throw this statement out there because I don’t think anyone will dispute me on this: mdot websites are almost always awful. With some exceptions, most of them are very poorly designed and don’t have even half the functionality of what the desktop site has. What’s worse, when on 3G latency, a redirect to a mobile version of a website can take up to 2 seconds. That’s an extra two seconds before your mobile page even starts to download. I don’t care how optimized your mobile site is, that redirect will forever color my perception of your website.
40% of American mobile users abandon shopping if the site isn’t loaded in 3 seconds, according to performance-testing.org based on research at Forrester. So why in the world would you want to add 2 dead seconds to your load time?! It seems obvious to me that an mdot approach is a horrible business decision.
By sending all devices to the same site, you avoid these time consuming redirect problems and all the headaches they can cause. Responsive design keeps everything centralized and allows your website to work on nearly everything without needing specialized content delivery for every type of screen.
Any downsides?
Only if you aren’t thinking about your graphics and visual appeal. Since everything is on the same site, every device loads the same content. While this is great for a number of reasons, this can also be a bad thing if you have, say, HD images on your website. Why? Because now you’re forcing mobile devices to load those HD images over a slower connection speed. It can also be bad if you hide certain elements of your page at smaller resolutions, since those hidden elements are usually still downloading and still creating HTTP requests even if they don’t show up on screen.
If your site isn’t properly optimized, mobile devices can have a hard time loading it. What’s worse, if your site is bloated and large and your user loads it on their mobile connection instead of WiFi, it can seriously cut into their monthly data plan if you’re not careful.
This is why responsive design is often paired with another design principle called “Mobile First Design”. Mobile first design is just that – design your website for mobile first, and scale up from there. This forces you to focus on what content is most important to your visitors, and how it can be organized efficiently.
Okay, so how can I make my responsive design faster?
All the usual page optimization tricks
Responsive design is a fundamental change to the way sites are designed, but most if not all of the usual page optimization tricks like minifying CSS and JS, forcing script files to download in the proper order, and image optimization will still work.
Conditional Loading
Loading a 700×700 pixel image for a desktop website and displaying it at 700×700 makes sense. What doesn’t make sense is downloading that same 700×700 image and displaying it at 300×300 for a mobile device. Conditional loading can help solve this.
In CSS2.0, you have the ability to detect screen sizes through @media queries. This lets you tell the stylesheet to download and display different images depending on what the screen size is. So going back to our 700×700 example, you can set up a media query that asks the screen size before this image gets downloaded. If it’s a mobile screen, download the 300×300 image. Otherwise download the 700×700 image.
There are some great tools that let you automate this process, such as Adaptive Images. Adaptive Images is a single php script that automatically scales and caches images within your website with no need for tedious extra code on every page. Picturefill is a similar tool that’s written in JavaScript. It uses media queries to detect the size and resolution of the screen it’s using and select the proper image to download from a list of images. It only makes one request, and only downloads once. And yes, it can detect the difference between a retina display versus a standard screen.
Images aren’t the only things that benefit from conditional loading. CSS sheets can also be conditionally loaded, so you can separate your stylesheets by screen size.
There are two rules you need to follow with conditional loading, though:
- Never download a resource twice
- Never download a resource that the user cannot (or does not) use.
The reasons for this should be obvious. It makes no sense to download resources more than once, and it’s a waste of bandwidth to download a resource that the user never sees or uses such as an image that appears on large monitors, but is hidden on mobile screens. Use conditional loading wisely – it can be a tool for both good and evil depending on how it’s implemented.
Scalable Images (SVGs)
I don’t think I can stress just how amazing SVG images are for performance in responsive design. SVG graphics can be scaled on the fly with no extra downloading or loss of quality, which fits perfectly with what responsive design is attempting to accomplish. It may be a good idea to put any graphics in your web pages into SVG format to allow them to easily scale with screen size.
Conclusion: Treat Performance As A Design Element
Performance is a big part of user experience design, but it’s often overlooked because it can’t be made to look pretty with a screenshot. By treating performance as an element of design early in development rather than just something the tech people can take care of later, you will end up with a website that ultimately performs better.
More Information:
If you’d like to read more about performance as a design element, or how to focus on responsive design performance, Brad Frost has some excellent material on the subject here:
http://bradfrostweb.com/blog/post/prioritizing-performance-in-responsive-design/
http://bradfrostweb.com/blog/post/performance-as-design/
If this idea of responsive design has piqued your interest and you’d like to take a stab at it, I recommend http://responsivedesign.ca/blog for everything you could possibly want to know on the subject. If it’s learning material you’re looking for, www.lynda.com has a few great courses on the specifics involved in responsive design.