Responsive Retrofitting

We recently had the opportunity to revisit the Cooke Orthodontics site we launched in March, 2010. Ethan Marcotte was still a couple months away from publishing his first article about responsive web design in A List Apart at that point, so not at all surprisingly, the site was built with a fixed-width, centered layout. Dr. Cooke and her team were recently seeing a noticeable increase in non-desktop visitors to the site and asked if we could make that experience a little better. We agreed, of course, because we like good, device-agnostic web experiences as much as the next geek, but also because taking an existing design and retrofitting it to work across devices and screen sizes poses a number of interesting and fun challenges. (Well, what we call fun around here, anyway.)

Planning

For the better part of the last year, all of our new projects have started with a responsive mindset. Typically this means we’re building from scratch, content-out, starting from the smallest screens and working our way up to whatever we feel comfortable calling the high-end screen size for the project. How we structure our HTML and handle assets like stylesheets, javascript files, and images is based on that initial decision that we’re starting small.

As there’s absolutely nothing wrong with the existing Cooke Orthodontics site, there was no reason for a complete rewrite of the existing site using our usual mobile-first approach. And because we wanted to keep the process as efficient as possible, we decided to only focus on screen sizes below that of the existing site. We typically go quite a bit larger than those 960 pixels at the high end of our fluid layouts—1200 pixels at least—but the client specifically asked us about improving the mobile experience, so we kept our attention where it should be: on small screens.

First things first: page diet

With a focus on small screens comes the assumption that people will be visiting the site on their phones, using cell networks rather than wi-fi or broadband. Those data networks are probably slower than what most visitors would be able to get on desktops. That’s usually a safe assumption, but the exceptions are not at all hard to find. (There are numbers on this, but I don’t need them to be convinced: at home I get faster speeds up and down on my phone over LTE than I do over wifi.) There’s also no reason to assume that desktop users necessarily have fast connections. The bottom line is that we need to make sites smaller and faster for everyone. Even sites we wrote a few years ago when none of us were really thinking about these things too hard. (See this recent post by Luke Wroblewski for some actual numbers about page sizes.)

As for the Cooke site, it was seeing pages that averaged about four seconds and change to load, weighed about 600K, and made in the ballpark of 75 HTTP requests. There were six separate stylesheets and five separate javascript files each being loaded individually, icons (for social media links, search boxes, etc) all loading individually, and no caching of any kind.

So what does this mean? It means the site was a bit more overweight than we’d prefer. Not obese by any means, but three years later and it’s looking a flittle flabby around the middle. It happens to the best of us. But our standards have gone up in the meantime—we like a site to be lean and quick. Each of those HTTP requests is a call from your machine to the server—the less of those the better. And while 600k maybe doesn’t sound like much when you’re looking to download a movie, it’s a pretty hefty payload to expect a phone to make just so you can find the address to your daughter’s orthodontist while you’re sitting in your car in the parking lot outside her school with the sun pouring in through the windshield and she’s in the backseat asking for a snack and you just need the address so you can drive to the appointment you already know you’re gonna be late to. Those four seconds are going to feel like an hour and a half minimum in that scenario. We can do better.

First things first, get the site mirrored and running locally, get all of those CSS files copied into Less files ¹, and get the whole thing set up in Codekit, where we can automatically concatenate and minify those files together. (We love Codekit around here. You should too.)

Next up, add a new central site.less file where we @import all of the rest:

@import “reset.less";
@import "screen.less";
@import "style.less";
@import “dropdowns.less";
@import "media-queries.less";
@media print {
    @import "print.less";
}

Those are Less imports, so all they’re saying is, “Please pull the contents of those other files into this one before it’s all saved and converted to a CSS file.” (Less imports are polite.) This means we’re left with a single stylesheet to load rather than six. That’s a pretty good start. And if we want (which we definitely do), we can have Codekit minify the file for us as well, which means it strips out all of the white space and comments and line breaks and makes the file even smaller.

We can do the same for the javascript files using one of Codekit’s coolest built-in features, javascript imports. Putting @codekit-prepend “file.js” in a comment block at the top of a new javascript file, we can basically do to the javascript files what we just did with the CSS: combine them all into a single file, minify it, and go from four files to one. Not bad.

The other thing Codekit can do right off the bat: compress all of our image files. This obviously isn’t going to have an impact on anything the client adds through the WordPress editor, but anything we’re using for the design can and should be mashed down a bit. (Yes, mashed down is the professional term.)

All of this takes an hour or two to set up and gets our page size way down. We also added a caching plugin to the site, which will further limit all of those HTTP requests we were trying to pare down earlier. When we finally launched the responsive version, we were seeing load times less than one second, HTTP requests down to about 25, and a total page weight of about 30K. That means we were able to shave a few seconds off load times, drop the HTTP requests down by two thirds, and lessen the total page size by 80%. Just by limiting and compressing our assets. Not bad.

The rest

After that, it was pretty straight forward responsive building. We unset the original grid below the desktop size and rebuilt it as a simple fluid grid. We also introduced some helper classes to help deal with some of the content we couldn’t change but needed to hide or show depending on the screen size:

@media all and (min-width: 60em) {
    .tablet-up {
        display: block;
    }
    .tablet-down {
        display: none;
    }
}

@media all and {max-width: 60em} {
    .tablet-up {
        display: none;
    }
    .tablet-down {
        display: block;
    }
}

No, not best practice, we know, but totally viable given the circumstances. We were also very conscious of limiting the use of these helper classes to text elements and not using them to hide big assets like images that might be downloaded by a visitor but never seen.

One of the main areas where we were using this was with navigation. Of the dozens of pages on the site, the client pointed to five they wanted to highlight on small screens. To do this, we wrapped the original, full menu in a .tablet-up wrapper, created a second menu in the WordPress admin with just those five highlighted pages, and called that menu in the theme wrapped in a div with the .tablet-down class. Because we didn’t want to keep people from being able to get around the rest of the site, we also added that full menu again as a pull down off the top of the canvas. This is a common design pattern we’re all getting familiar with that allowed us to highlight the pages we needed to highlight without punishing visitors or cluttering the page.

Lastly, to help you get from the parking lot at your daughter’s school to her orthodontics appointment even faster, we added some contact information and a link to the location on Google Maps right at the top of every page. No more long waits, no more hunting around, and it looks pretty good to boot. Sounds about right.