Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to “design for the ebb and flow of things.”
With those two sentences, Ethan closed the article that introduced the web to responsive design. Since then, responsive design has taken the web by storm. Seemingly every day, some company is touting their new responsive redesign. Large brands such as Microsoft, Time and Disney are getting in on the action, blowing away the once common criticism that responsive design was a technique only fit for small blogs.
Certainly, this is a good thing. As Ethan and John Allsopp before him, were right to point out, the inherent flexibility of the web is a feature, not a bug. The web’s unique ability to be consumed and interacted with on any number of devices, with any number of input methods is something to be embraced.
But there’s one part of the web’s inherent flexibility that seems to be increasingly overlooked: the ability for the web to be interacted with on any number of networks, with a gradient of bandwidth constraints and latency costs, on devices with varying degrees of hardware power.
A few months back, Stephanie Rieger tweeted
“Shoot me now…responsive design has seemingly become confused with an opportunity to reduce performance rather than improve it.”
I would love to disagree, but unfortunately the evidence is damning. Consider the size and number of requests for four highly touted responsive sites that were launched this year:
- 74 requests, 1,511kb
- 114 requests, 1,200kb
- 99 requests, 1,298kb
- 105 requests, 5,942kb
And those numbers were for the small screen versions of each site!
These sites were praised for their visual design and responsive nature, and rightfully so. They’re very easy on the eyes and a lot of thought went into their appearance. But the numbers above tell an inconvenient truth: for all the time spent ensuring the visual design was airtight, seemingly very little (if any) attention was given to their performance.
It would be one thing if these were the exceptions, but unfortunately they’re not. Guy Podjarny, who has done a lot of research around responsive performance, discovered that 86% of the responsive sites he tested were either the same size or larger on the small screen as they were on the desktop.
The reality is that high performance should be a requirement on any web project, not an afterthought. Poor performance has been tied to a decrease in revenue, traffic, conversions, and overall user satisfaction. Case study after case study shows that improving performance, even marginally, will impact the bottom line. The situation is no different on mobile where 71% of people say they expect sites to load as quickly or faster on their phone when compared to the desktop.
The bottom line: performance is a fundamental component of the user experience.
So, given it’s extreme importance in the success of any web project, why is it that we’re seeing so many bloated responsive sites?
First, I adamantly disagree with the belief that poor performance is inherent to responsive design. That’s not a rule – it’s a cop-out. It’s an example of blaming the technique when we should be blaming the implementation. This argument also falls flat because it ignores the fact that the trend of fat sites is increasing on the web in general. While some responsive sites are the worst offenders, it’s hardly an issue resigned to one technique.
To fix the issue, we need to stop making excuses and start making improvements instead. Here, then, are some things we can do to start improving the state of responsive performance, and performance in general, right now.
Create a culture of performance
If you understand just how important performance is to the success of a project, the natural next step is to start creating a culture where high performance is a key consideration.
One of the things you can do is set a baseline. Determine the maximum size and number of requests you are going to allow, and don’t let a page go live if either of those numbers is exceeded. The BBC does this with its responsive mobile site.
A variation of that, which Steve Souders discussed in a recent podcast is to create a performance budget based on those numbers. Once you have that baseline set, if someone comes along and wants to add a something to the page, they have to make sure the page remains under budget. If it exceeds the budget, you have three options:
- Optimize an existing feature or asset on the page
- Remove an existing feature or asset from the page
- Don’t add the new feature or asset
The idea here is that you make performance part of the process instead of something that may or may not get tacked on at the end.
Embrace the pain
This troubling trend of web bloat can be blamed in part on the lack of pain associated with poor performance. Most of us work on high-speed connections with low latency. When we fire up a 4Mb site, it doesn’t feel so bad.
When I tested the previously mentioned 5,942kb site on a 3G network, it took over 93 seconds to load. A minute and a half just staring at a white screen. Had anyone working on that project experienced that, you can bet the site wouldn’t have launched in that state.
Don’t just crunch numbers. Fire up your site on a slower network and see what it feels like to wait. If you don’t have access to a slow network, simulate one using a tool like Slowy, Throttle or the Network Conditioner found in Mac OS X 10.7.
Watch for low-hanging fruit
There are a bunch of general performance improvements that apply to any site (responsive or not) but often aren’t made. A great starting point is to refer to Yahoo!‘s list of rules.
Some of this might sound complicated or intimidating, but it doesn’t have to be. You can grab an .htaccess file from HTML 5 Boilerplate or use Sergey Chernyshev’s drop-in .htaccess file. You can use tools like SpriteMe to simplify the creation of sprites, and ImageOptim to compress images.
Just by implementing these simple optimizations you will achieve a noticeable improvement in terms of weight and page load time.
Be careful with images
The most common offender for poor responsive performance is downloading unnecessarily large images, or worse yet, multiple sizes of the same image.
For background images, simply being careful with where and how you include the image can ensure you don’t get caught in the trap of multiple background images being downloaded without being used. Don’t count on display:none to help. While it may hide elements from displaying on screen, those images will still be requested and downloaded.
Content images can be a little trickier. Whatever you do, don’t serve a large image that works on a large screen display to small screens. It’s wasteful, not only in terms of adding weight to the page, but also in wasting precious memory. Instead, use a tool like Adaptive Images or src.sencha.io to make sure only appropriately sized images are being downloaded.
The new <picture> element that has been so often discussed is another excellent solution if you’re feeling particularly future-oriented. A picture polyfill exists so that you can start using the element now without any worries about support.
Conditional loading
Don’t load any more than you absolutely need to. If a script isn’t needed at certain sizes, use the matchMedia polyfill to ensure it only loads when needed. Use eCSSential to do the same for unnecessary CSS files.
Last year on 24 ways, Jeremy Keith wrote an article about conditional loading of content in a responsive design based on the screen width. The technique was later refined by the Filament Group into what they dubbed the Ajax-Include Pattern. It’s a powerful and simple way to lighten the load on small screens as well as reduce clutter.
Go vanilla?
If you take a look at the HTTP Archive you’ll see that other than image size, JavaScript is the heaviest asset on a page weighing in at 215kb on average. It also boasts the fifth highest correlation to load time as well as the second highest correlation to render time.
Much of the weight can be attributed to our industry’s increasing reliance on frameworks. This is especially a concern on mobile devices. PPK recently exclaimed that current JavaScript libraries are just “too heavy for mobile”. “Research from Stoyan Stefanov on parse times supports this. On some Android and iOS devices, it can take as long as 200-300ms just to parse jQuery.
There’s nothing wrong about using a framework, but the problem is that they’ve become the default. Before dropping another framework or plugin into a page, we should stop to consider the value it adds and whether we could accomplish what we need to do using a combination of vanilla JavaScript and CSS instead. (This is a great example of a scenario where a performance budget could help.)
Start thinking beyond visual aesthetics
We love to tout the web’s universality when discussing the need for responsive design. But that universality is not limited simply to screen size. Networks and hardware capabilities must factor in as well.
The web is an incredibly dynamic and interactive medium, and designing for it demands that we consider more than just visual aesthetics. Let’s not forget to give those other qualities the attention they deserve.
Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
07/12/2012
Tim and Scott,
I’d like Scott’s feedback since he’s dealt with these issues while working on Respond and the like.
This is a pretty timely post for me. Javascript performance with media queries is why I began working on a project to support those browsers that don’t perform well with polyfills. I also wanted to support more of the media features that modern browsers do, while keeping the file size down. For examples of what I mean by ‘don’t perform well’, I was doing some testing on jsPerf and jsFiddle using matchMedia.js polyfill.
1. iPhone 4.3.3 gets 2 – 6 Ops/sec
2. IE <= 9 gets 40 – 90 Ops/sec
3. Chrome, Firefox, Safari and Opera fair much better 900 – 2500 Ops/sec
Testing the same media query with native matchMedia in Chrome, Firefox, Safari and Opera get 36,000 – 110,000 Ops/sec.
So now we know what we have and what’s possible. With the project below (Media.match), I was shooting for somewhere in between but hoping for much more. In short I got better than I expected. In Chrome, Media is more than 50% faster than native matchMedia but in Firefox, it’s 50% slower. I’m really excited about the results in IE and iOS as well but need more testing data. I’m not sold just by the numbers alone either, IE <9 feel like they can actually handle media queries. Again, I’m really pleased with the results and would like to share what I’ve been working on.
I’d love to see if we can make these even better, feedback is surely welcome.
matchMedia like support
https://github.com/weblinc/media-match
Testing data
http://jsfiddle.net/wV9HZ/1/
http://jsperf.com/matchmedia/4
Test page using JSLitmus (native matchMedia vs Media.match)
Some incredible numbers. Media.match is faster or rivals native matchMedia. Check out Chrome.
https://github.com/weblinc/media-match/tree/master/test
Respond like project
https://github.com/weblinc/nonresponsive
Vote Helpful or Unhelpful
06/12/2012
We came across a lot of these performance issues whilst developing our new company site over at etchapps.com.
I’ll be first to admit we’re running 50 something requests and a 3.2Mb total page load on our heaviest page on desktop (ouch!), but we’ve done a lot to mitigate that pain.
The site is fully responsive (with a touch of adaptive) from around 290px all the way up to 1600px or so with a lot of imagery and so serving up those images in a nice way was essential to download speeds.
We lazyload our images with JS so the user can get hold of the content as fast as possible. They’re also resized at the server end so we don’t send any wasted pixels and smushed with ImageOptim. If the user resizes the window and hits a breakpoint, we check if there’s a more appropriate image size to serve up to maintain image quality.
On the JS side, we’ve tried to keep plugin usage to a minimum and written our own where appropriate to keep filesize down.
We’re also using the lovely HTML5 boilerplate htaccess file (as you suggest!) and it does a great job of caching files for faster downloads where appropriate.
Based on your article we’ll be diving into conditional loading for CSS and JS as I think we could squeeze a few more Kb off the site size by not loading some of our more complex JS on mobile.
Our own performance optimisation attempts have given us the same number of total requests on mobile but total page size on the heaviest page (3.2Mb desktop) is down to 1Mb on mobile. As the images are loaded with JS, initial download is only 15 requests and 400Kb.
Great article! I’ll be using it as a reference checker for further projects to help make sure we’ve got everything covered.
Cheers
Gav
Vote Helpful or Unhelpful
05/12/2012
Shaun,
Andy Wickes has wriiten an nice article about that issue. But judging on the comments below the article it seems like it really depends on the carrier if they compress the image or not.
http://boagworld.com/dev/how-should-we-handle-responsive-images/
Vote Helpful or Unhelpful
05/12/2012
Very instructive, thank you. Regarding conditional loading for CSS, wouldn’t it be more appropriate to use the media property with a proper fix for IE – media=“screen and (min-width: 40.5em)” – even if it adds a HTTP request instead of a 2kb script like eCSSential ?
Vote Helpful or Unhelpful
05/12/2012
Some nice points here, Tim.
A note on the image loading part:
It might be worth clarifying that in its current state, Picturefill is not a polyfill of the <picture> element, but rather a div-based pattern that mimics picture in ways that are safe to use today and moving forward. Also, by using media queries, client-side solutions like Picturefill offer levels of control that can’t be mimicked on the server, where only default known values such as device screen dimension can be derived.
Thanks!
Vote Helpful or Unhelpful
05/12/2012
Thanks for all the awesome comments!
@Yara – I haven’t used it, but Sloppy looks like it might do the trick.
@Shaun – As others have mentioned, you can’t rely on that. Some networks compress, but others don’t. Those that do, often only do so in certain situations (and some do a horrible job). If you’re interested, I actually wrote a bit about the unpredictability of carrier networks last year’s Performance Calendar.
@Andy – I had the same thought about eCSSential initially, but the initial (though informal) testing I did actually showed pretty good improvements. I know WebKit does handle it rather smartly (at least some versions of it) but I haven’t seen any information yet about how many other browsers do it as well. I’d love to see more formal benchmarking. :)
@Jacques – Unfortunately the media property doesn’t stop all those extra CSS files from downloading. See Scott Jehl’s tests for a bit more on that.
Vote Helpful or Unhelpful
05/12/2012
Shaun:
Not all mobile operators ‘optimise’ images and in my experience even those operators that do only seem to re-compress JPEGs.
For example, in the UK, O2 do re-compress JPEGs but Vodafone don’t even on really low throughput connections.
Even if all operators did re-compress images would you really want to leave the final quality of your images to the operator?
For some operators e.g. O2, you can disable the re-compression of images by adding @no-transform@ to the @cache-control@ HTTP header.
Tim:
Great post Mr Kadlec!
I’ve got some concerns with eCSSential, as using JS to determine which CSS files should be downloaded interferes with the browsers ability to pre-fetch and prioritise the order resources are downloaded.
Browsers are already making choices on which resources they should download first, for example in this waterfall for enochs.co.uk, the stylesheets that are not applicable are deferred to the end of the page load
http://www.webpagetest.org/result/121205_G8_9079577333c6bffac22fcbc6480e7220/1/details/ (requests 35, 36, 37)
I guess what we in the performance community needs to do is a bit more work on benchmarking approaches like eCSSential vs multiple CSS resources vs a single merged CSS resource.
Vote Helpful or Unhelpful
05/12/2012
Great post!
There are very much articles about responsive webdesign but only few handle performance.
As i redesigned my site i was looking for possibilities to test the loading time on mobile and i came across weblenz, it’s available in the app store. The lite version is free and tests time, items and the size of a website. I like it because i do not have to simulate latency, i can test in the “real world” on my iphone.
Thank you!
Vote Helpful or Unhelpful
06/12/2012
Many thanks for this article, and the thinking behind it.
To the many fine incentives for lightening the (down)load given in the article itself, I’d like to add another. Please consider the millions of people in the developing world for whom infrastructure is a precarious thing.
I spend significant time in south-central Africa. Even in university departments where one might expect decent connectivity, web performance can be woeful.
The “world wide web” really is the world wide web! The more the kind of ethos advocated in this article can be grown, the greater the benefits will be for the most technologically challenged parts of the planet.
Vote Helpful or Unhelpful
05/12/2012
Great article man. It seems like design think they have carte blanche when it comes to responsive design, and page speed is an after thought. Might I add, DEATH TO THE HOMEPAGE IMAGE SLIDER, its a design crutch that has seen its day!
Vote Helpful or Unhelpful
07/12/2012
Absolutely spot on, responsive shouldn’t mean reduce functionality or just hide images. Too many I’ll thought out irresponsible responsive experiences… Obviously it’s not that “irresponsible” it’s not like getting your dog to take the wheel as you crack open a beer, but you get the point.
Vote Helpful or Unhelpful
05/12/2012
Timely article, well done. One question: aren’t mobile networks generally going to optimize the images prior to delivery, even if your own site isn’t?
Vote Helpful or Unhelpful
28/12/2012
Diving into responsive design is extremely painful at least, especially when you have to deal with ads, as they are not ready for responsive and the TOS can be quickly violated.
Not loading ads scripts is part of mobile performance of course!
Vote Helpful or Unhelpful
05/12/2012
Exactly. Having responsive sites that pump just as many or even more bytes than usual kind of defeats the whole purple of serving a “mobile-optimized” site, doesn’t it? I’ve always wondered this, and the article provides a great answer and great tips on cutting down on resource load. I’ve learned a lot this year already, and it’s only been the first week!
I just thought to add: making performance an essential component is great, but as always, spend time only on things that matter.
To wit: I really hope nobody confuses things like eliminating unnecessary HTTP requests and compressing resources, for nonsensical notions of premature optimization in code such as keeping everything in tight loops or avoiding using descendant selectors ever. Notice how this article doesn’t mention the latter at all. That’s because that sort of stuff hardly ever matters, and I dare say not at all on a mobile site, where less is more.
Vote Helpful or Unhelpful
20/12/2012
Performance has been a concern since broadband connections allowed us to serve larger and larger assets. Just because our connections CAN handle more HTTP requests doesn’t mean we should stuff them to the gills. I’ve found YSlow absolutely invaluable for trimming the network fat. It goes without saying to always, always compress and gzip your assets, minify your CSS, and concatenate and minify your JavaScript.
Principles like OOCSS and its natural expansion (SMACSS) have come along to keep our stylesheets lean and mean, which on a site that leverages a lot of CSS3, can be critical. Furthermore, we have Modernizr to aid with conditional loading of scripts only when we need them. ‘display: none’ should be used sparingly, if at all as that markup still adds page weight and it makes no sense to punish mobile visitors.
Think about whether you really need a library or framework before you use it, as even a small file size can be a death by a thousand cuts with enough of them. Again, if you don’t need it on every page, don’t load it on every page. If you do use a library, try to use native JavaScript as much as you can and limit dependencies. Dump your objects when they’re no longer in use to reclaim that memory.
Above all, I think responsive design encouraged us to really think about our content and embrace web design in its own medium rather than as an offshoot of print. It’s a sign that the web industry has matured beyond its print-inspired design roots to have its own idioms and conventions. And that’s what makes it so awesome. I’m happy to be a part of its growth.
That said, the mobile web networks aren’t as blazing fast as their broadband network siblings, and we should be planning for that from the onset. We’re not designing for 56k anymore, but performance shouldn’t suffer for our advancement. In print, it only has to work from a design perspective; in web it should work even better than it looks.
Vote Helpful or Unhelpful
05/12/2012
Great points made. Particularly like the part on not just plugging in frameworks as they come and the mention of testing with apps like Slowy.
Shaun: Not all mobile networks compress images/data and the ones they do seem to do it to different extends. I got my hopes up when I recently read the article on Boagworld about this topic, but unfortunately it does not seem to be as straight forward as we’d like. I hardly every is, isn’t it?
Vote Helpful or Unhelpful
05/12/2012
Sweet article as it lines out a problem I ran into a few weeks ago.
I’m working on a huge site with a lot of different layouts and markups (it’s almost as if every site has its own markup and css).
So shredding the site down to a good performance was the very first step, which then was completely ruined after we started to make the COMPLETE site responsive.
This article was very very helpful. Thanks and greetings from Germany. =)
Vote Helpful or Unhelpful
05/12/2012
You are right. Responsive design is a mode (as was the mobile application, social networks …) and “developers” or “agencies” offer cheap responsive design, but no more responsive…
I use Network Conditioner every day (brilliant tool!) and Steve Souders advices to evaluate if a new features can be added.
Vote Helpful or Unhelpful
10/12/2012
Thanks for this post, Tim! In addition to your framework comment, the proliferation of plug-ins has made it too easy to increase the number of HTTP requests for a page. Learning how to consolidate CSS and JavaScript and minifying will need to be part of most of my future workflows. Performance, I agree, is too often an afterthought.
Vote Helpful or Unhelpful
10/12/2012
This was a great article, Tim! I think along the line of frameworks adding bloat is the proliferation of plugins, each of which creates another server request. Cons
Vote Helpful or Unhelpful
05/12/2012
“Create a culture of performance” Absolutely true!!
Vote Helpful or Unhelpful
06/12/2012
Great tips, I always find so much stuff I can strip away from a website towards the end of the project to increase load times with mobile in mind.
Thanks
Vote Helpful or Unhelpful
12/12/2012
http://zeptojs.com/ is a minimalist JavaScript library for modern browsers with a largely jQuery-compatible API. It makes a good alternative to full jQuery for mobile websites.
Vote Helpful or Unhelpful
08/12/2012
This article is dead-on on how responsive design is not enough, and web performance needed to be considered at the design, not just development levels. My suggestion for a meta-design principle, embodied over at http://sustainablevirtualdesign.wordpress.com, is to include web performance and responsive design (part of inclusive design) as Sustainable Web Design. Other disciplines (architecture, industrial design) already include adaptive design with performance, measured by carbon footprint and energy use. Similar ideas can be applied to web design. WPO needs to be pushed into the earliest layers of design, including UX wireframes and stuff done in Photoshop prior to prototyping in code. If we leave WPO to engineers, we get “streamlined hippos” – klunky, energy-wasting websites that a site engineer can only partly fix.
Vote Helpful or Unhelpful
06/12/2012
Thank You for the great read and advice when it comes to designing for repsponsive. Our company is just getting started with responsive design so your blog was really helpful.
Vote Helpful or Unhelpful
09/12/2012
This article is dead-on on how responsive design is not enough, and web performance needed to be considered at the design, not just development levels. My suggestion for a meta-design principle, embodied over at http://sustainablevirtualdesign.wordpress.com, is to include web performance and responsive design (part of inclusive design) as Sustainable Web Design. Other disciplines (architecture, industrial design) already include adaptive design with performance, measured by carbon footprint and energy use. Similar ideas can be applied to web design. WPO needs to be pushed into the earliest layers of design, including UX wireframes and stuff done in Photoshop prior to prototyping in code. If we leave WPO to engineers, we get “streamlined hippos” – klunky, energy-wasting websites that a site engineer can only partly fix.
Vote Helpful or Unhelpful
05/12/2012
Good stuff, Tim! Keep spreading the word that performance is part of the user experience!
Vote Helpful or Unhelpful
05/12/2012
I don’t agree with
> Whatever you do, don’t serve a large image that works on a large screen display to small screens.
I want to be able to zoom in on an image and see a reasonable quality. Obviously it shouldn’t be 600KB, but 40KB is not much at all and can be a decent size, both for desktop and mobile. All the ‘responsive image polyfilling’ is NOT good for performance. Every bit of JS you can skip, skip it.
Vote Helpful or Unhelpful
05/12/2012
Great article,
An alternative Slowy app for Windows ? ;-)
Vote Helpful or Unhelpful
05/12/2012
<blockquote>Don’t count on <code>display:none</code> to help. While it may hide elements from displaying on screen, those images will still be requested and downloaded.</blockquote>
That’s not true.
Vote Helpful or Unhelpful
Impress us