Speed is a core value for 37signals and it’s easily Basecamp’s most important feature. When you have the luxury of that kind of focus, decisions about the product are easier to make because you have something to measure against. Will this feature make Basecamp slower? Is it worth that trade-off? So when we designed the mobile web version of Basecamp we knew that speed would be just as important as it was in the full desktop version. What was different was how we got there.

On the desktop, Basecamp’s speed is the result of some nifty tech that minimizes network requests, reduces page rendering and aggressively caches content. Moving through a Basecamp project is nearly instant as new content appears in real-time without re-loading the page. It’s great! I typically keep Basecamp open in my browser all day long as my co-workers’ activity streams in on the Progress screen.

When it came to the mobile version the goal that Basecamp should be super-fast was the same, but there were new forces at work: low cellular bandwidth, small touch-enabled screens, slow JavaScript performance, and context considerations (what’s useful and functional on mobile). It was tempting to turn to responsive design techniques on this project. Basecamp was already functioning fine on mobile browsers, but it required a lot of pinching, swiping, and zooming. CSS media queries would have let us craft a mobile layout for all kinds of devices with a limitless array of screen configurations. We’d be on the exact same codebase with all the same features – and new features would automatically be available on mobile when they launch as long as we remembered to test and optimize them.

Only using responsive design for Basecamp mobile would have been like fitting a Prius body to a Hummer… under-the-hood it would have been all wrong.

On the surface it sounded great, but there were some big problems. The JavaScript that powers the real-time feel of Basecamp is heavy both in terms of file size and resource usage. This is no problem on the desktop where bandwidth is abundant and CPUs are excessively fast, but mobile browsers aren’t nearly as capable of processing JavaScript and the initial download would have been oppressive.

Not only would the browser have to download and process all that code, but much of it would have gone unused. Making a design responsive generally means taking things away. You hide features, menu items, sidebars – anything that isn’t needed in the mobile context. They’re still present in the document and the mobile browser still has to download and load into memory all the CSS and JavaScript that defines them. Not to mention the additional CSS overrides that you added to the stack in order to define the responsive layout in the first place. Only using responsive design for Basecamp mobile would have been like fitting a Prius body to a Hummer. It might have looked like a mobile web app, but under-the-hood it would have been all wrong.

Basecamp mobile web views

As I covered in the announcement post we took a different approach. Basecamp mobile sits right alongside the full version in our codebase. It has access to all the same models, controllers and helpers but each view template has been re-thought for the mobile context and redesigned with its own mark-up, styles and behaviors.

Making it fast required us to rebuild every view to include precisely what was relevant to the mobile experience and nothing else – not only in terms of design and features, but resources. There’s no extra mark-up, no unused styles, and we kept JavaScript usage to a minimum. That means no jQuery – in fact, no framework at all. We distilled the most common operations to a handful of helpers (about 70 lines of CoffeeScript) and the rest we wrote using the plain old DOM API. (What was most surprising to me is how much you can do without a framework when you don’t have to support Firefox and multiple versions of Internet Explorer!)

And to give the mobile version an extra speed boost we dropped in Turbolinks, a tiny JavaScript library that converts regular page loads into Ajax requests using HTML5 pushState. With Turbolinks, all the heavy lifting – JavaScript and CSS downloading, parsing, execution, and behavior installation – happens once, the first time you load the app, instead of on every page load. It’s a huge win for performance.

So what does this all mean? Let’s get to some numbers. I took a typical discussion from our Basecamp account and used Safari’s web inspector to compare the desktop and mobile versions.

Compare web and mobile

Here’s the how they compare:

Desktop Mobile
Load time: 3.84s1.39s
HTML: 42.92KB16.90KB
CSS: 515.79KB38.91KB
JS: 273.80KB14.73KB
Fonts: 192.35KB

Web inspector screenshots: Desktop | Mobile

That’s just about 1MB of bandwidth on the desktop. When you factor in the images on the page (mostly user avatars), it’s more like 1.2MB. No sweat on a laptop, but a serious burden on a 3g connection. So how did our mobile version stack up? The mobile version not only renders faster but offers a huge savings in bandwidth usage. The HTML, CSS, and JavaScript weigh-in at about 70K. Images increase the total cold-cache download for this screen about 222KB (125KB of that is avatars). All said, it loads more than 2 seconds faster in real time (both on wifi) and is about 1MB lighter.

Another screen in the app had actually been using responsive design techniques to deliver a mobile-friendly layout. Converting it to a dedicated mobile web view showed similar results slimming from 1000.3KB to 123.49KB. That screen looks and functions identically in both versions of Basecamp.

More than just download speed

Of course it’s difficult to quantify but these lightweight pages offer more than just bandwidth savings on mobile. The leaner mark-up, JavaScript and styles give the mobile browser less to process and use less memory. That means scrolling is smooth, taps are crisp, and the next page loads even faster because the assets are cached. We’ve already observed that many customers using iPad favor the mobile version over the desktop (which works quite well on iPad) because it’s just so much faster.

The purpose of this post is not to suggest that responsive design isn’t useful. Not only is it useful, but we’ve employed a fair amount of CSS media queries to adjust our mobile design up into tablet layouts. What responsive design isn’t is a magic bullet. A layout that looks great on mobile, may not perform well. And while it’s compelling to think that by layering some CSS on top of a web app intended for the desktop we can turn it into a great experience on mobile, that’s probably not the case for all but the most simple of apps. As designers it’s easy to forget that fast > beautiful. Applying the same care and craft to what users can’t see might be the difference between a great design and a great experience.