Reflecting on the Revamped Sherpa

Every now and then, it’s good to take a critical eye to the work you’ve done and look for ways to improve it, so this review is going to turn the microscope around and focus on the Web Standards Sherpa site. It’s a tough thing to make time for on a largely volunteer project when your team is pretty much flat-out on client work, but we carved out some time in the first few months of this year to revisit this site and make some changes that would help our content go further.

Best Practices Change

We launched Web Standards Sherpa on March 13, 2011. At the time, CSS Media Queries were relatively new and, though we put a lot of thought into how we could use them, we hadn’t really put much collective thought into how we should use them.

As such, our approach for this project ended up tracking Ethan Marcotte’s concept of Responsive Web Design (RWD) — fluid grids, flexible media, and media queries — but it did so from a ”desktop-first“ perspective, using primarily max-width-based media queries:

@media screen {
    /* Desktop Rule Sets (universal) */
}
@media screen and (max-device-width:480px) { 
      /* Small Screen Rule Sets */
}
@media screen and (min-device-width:481px) and (max-device-width:1024px) {
    /* The Squishy Middle Rule Sets */
}

At the time, it just made sense to take that approach: We had been designing, prototyping, and building the site for several months before media queries even became a viable option, and we had no interest in maintaining a separate mobile site. So we added RWD into the project in the final month and made it work.

The result was decent. If you used it on mobile, the site worked, but it was clear that the mobile experience was an afterthought. You could use the site in all the then state-of-the-art mobile browsers — Safari, Android, Dolphin, Opera Mini, and Opera Mobile — but interactions were more than a little clunky.

A screenshot comparison of how the old site looked in the current Opera Mini incarnation (left) versus how the current site looks (right). Obviously, the new site is far more usable. Part of the reason the old version didn’t age well was the shift from use of the “viewport” meta tag to CSS-based rules around how browsers should determine width for media queries.

Fast-forward two years and the mobile experience was falling apart. Browsers had gotten a little more savvy — or picky, depending on how you look at it — in how they were handling media queries and viewport-sizing instructions, and Web Standards Sherpa just looked haggard. It needed a makeover.

From “Mobile Friendly” to “Mobile First”

Design-wise, the site is still pretty amazing: Dan Cederholm crafted a timeless look and feel for the site and Steph Troeth’s and Kelly McCarthy’s information architecture was still quite solid. All we needed to do was make mobile a first-rate experience from a styling and interaction perspective.

I wrote on the Easy Designs Blog about making the switch from a “mobile-friendly,” desktop-first site to a “mobile first” one. In it, I discussed how looking at a site from the mobile perspective first is a great way to integrate progressive enhancement:

“[Y]ou optimize your site for use in a mobile context, and then layer on extra styles, JavaScript and content as you find you have more real estate to work with or a more capable device.”

In practice, that lead to quite a few changes:

We Swapped Pixels for Ems

We adjusted our media queries to use em units) instead of pixels to provide the most appropriate reading experience based on the user’s font-size preference. That means if my aunt has her font size increased to 2x, but is on a larger screen, she will get a more linear layout more akin to a tablet view at 1x.

Min-width Instead of Max-width

We migrated most of our media queries to reference min-width rather than max-width so that they would start with the smallest screen first and build up from there:

/* Mobile-first Base Rule Sets */

@media only screen and (min-width:20em) {
    /* 20em and up media query-aware browsers */
}

@media only screen and (min-width:30em) {
    /* 30em and up media query-aware browsers */
}

/* And so on… */

We did not throw out a lot of the original CSS, but instead broke it apart and moved rule sets (or parts of them) into the new queries as appropriate. That saved us a lot of time.

We Have Lots of Breakpoints Now

Whereas the original site only had three breakpoints, the current incarnation has a whopping nine. Some follow somewhat typical conventions (20em, 30em, 48em), but others are pretty site-specific (34.375em, 42.5em, 51.25em, 61.25em). The reason for the change is pretty simple: we wanted to provide a solid reading experience across the board. We tweak the design a fair bit in the squishy middle between small screens and large ones.

An “onionskin” representation of the nine breakpoints employed on the refresh of Web Standards Sherpa.

We are More Touch Friendly Now

Dan’s original design had some pretty chunky buttons, so they were quite easy to tap with your finger. Links, however, not so much. We needed to increase the tappable size of the links and the spacing around many of the navigational links to improve tap accuracy. In particular, the links in the footer are quite small and narrowly spaced on desktop. We corrected that on smaller screens where tapping is the more likely interaction model.

A close-up look at how we enlarged our links to make them larger and more touch-friendly on smaller screens. On the left is the large-screen view, on the right is the small-screen view.

We Put CSS and JavaScript on the Same Page

A major headache in most responsive designs is getting CSS and JavaScript to work together. It’s easy to swap styles using media queries, but adjusting JavaScript-based functionality is a little more complicated.

Sure, you could use matchMedia to determine if certain conditions are met before generating or destroying a given JavaScript-based user interface. However, doing that requires that you duplicate your media queries in your JavaScript code, and keep them updated along with any CSS changes you make. To avoid that potential maintenance headache we chose a different solution.

Back in 2012, I had written a little JavaScript called watchResize to track the browser window dimensions (and changes to them) to simplify the authoring of screen-size dependent JavaScript. A few months later, taking a cue from Jeremy Keith’s post about using clever CSS to inform JavaScript of breakpoints, I built a little jQuery-based helper called getActiveMQ to generate a hidden div and then track the font-family CSS property that was set on it. That meant that on the CSS end, all we needed to do was assign each breakpoint a name:

#getActiveMQ-watcher {
      font-family: "break-0";
}
@media only screen and (min-width: 20em) {
      #getActiveMQ-watcher {
            font-family: "break-1";
    }
}
/* And so on… */

And we could get the currently applied value back via JavaScript:

var current_mq = window.getActiveMQ(); // break-X

Combining watchResize with getActiveMQ, it became simple to track the current media query in a global variable that any JavaScript in the site could reference:

// Create a global Sherpa JS Object
if ( !( 'WSS' in window ) ) { window.WSS = {}; }

// capture the current breakpoint to WSS.screen_size
window.watchResize(function(){
    window.WSS.screen_size = window.getActiveMQ();
});

// Use that value in a lazy-loading images script
window.watchResize(function(){

    var $img = $( '' ),
        $els = $( '[data-image]:not([data-imaged])' ),
        curr_break = window.WSS.screen_size.replace( 'break-', '' );

    // loop through all elements with a data-image attr
    $els.each(function(){

        var $el = $(this),
            // do they have a min-breakpoint set?
            // if not, use break-4
            bp = $el.data('image-min-breakpoint') || 'break-4';

        bp = bp.replace( 'break-', '' );

        // if the current breakpoint is >= the one
        // we are testing for, lazy-load the image
        if ( curr_break >= bp )
        {
            $img.clone()
                .attr( 'src', $el.data('image') )
                .prependTo(
                    $el.attr( 'data-imaged', '' )
                 );
        }

    });

});

Done and done.

Getting Serious About Performance

With our styles working a bit better and our JavaScripts able to follow CSS’ lead on the breakpoints, we focused our attention on download speeds.

As I’m sure you can guess, most of our page weight comes from image content. We optimize every image on the site before it even get onto the server, but each one adds up. We didn’t want to sacrifice the rich visual design of the site or the helpful screenshots in the articles, so we looked for other ways to speed things up.

We Migrated to SASS

In the years since we built this site, our team has moved over to using SASS to speed up our CSS authoring. On smaller, less complicated sites like Sherpa, we’ve found Jake Archibald’s respond-min/respond-max mixin set quite useful.

Jake’s mixin allows us to identify media query blocks but also gives us the ability to strip the rules out of the media queries for older browser that don’t understand media queries (like IE 8 and below). We combined those mixins with a set of variables that defined our breakpoints to ensure consistency across our CSS. Here’s a sample of what that looks like:

$break-1: 20em;
$break-2: 30em;
/* And so on… */

#getActiveMQ-watcher {

    font-family: "break-0";

    @include respond-min($break-1) {
        font-family: "break-1";
    }

    @include respond-min($break-2) {
        font-family: "break-2";
    }

    /* And so on… */

}

We were using a similar technique for concatenating JavaScript files via the CMS, so we opted to abandon that as well. With the move to SASS, we’d become pretty familiar with running build commands via the command line, so we decided to use Uglify to perform the concatenation and minification. And we employed Grunt to orchestrate all of that and to bring our other build step — image optimization — under one roof.

We Moved our CSS and JavaScript into the CDN

With actual static CSS and JavaScript files, we finally had the opportunity to move these files into the CDN (which we were already using for article images). That meant users around the globe would get these files faster.

If you are not familiar with CDNs, they are a great way to skirt browser limits on parallel connections.

We Got Lazier

In the original version of the site, we were using a technique called “lazy loading” to inject the markup for the homepage carousel only when the user was using a large screen and had JavaScript support. We opted to take that route because, while we wanted the carousel to enable a user to move backward and forward in time to see every article, we didn’t think the carousel would provide a good experience on small screens, we knew loading all of that content would not be very bandwidth-friendly, and we also knew that without JavaScript the carousel would not actually work.

In the interest of being more bandwidth friendly throughout the site, we opted to use lazy loading for more pieces of content.

We rolled article comments, which were once in their own section of the site, into the article pages themselves to provide a more integrated experience. As supplementary content, though, they were a great candidate for lazy loading. We did want to keep the comments available to non-Javascript users too though, so we used a slightly customized version of Scott Jehl’s anchor-include pattern to turn a direct link to an actual, separate comments page into a trigger for loading the comments asynchronously:

<a href="/reviews/curing-the-jetblues/comments/#comments"
    data-include-on-tap
    data-replace="/comments/curing-the-jetblues/"
    data-include-size="5">View comments on 
    this entry and add your own</a>

The data-* attribute-based instructions here tell JavaScript to replace this link with the HTML retrieved from /comments/curing-the-jetblues/ if the breakpoint is “5” or larger or if the user is on a smaller screen and taps on the link.

We chose a slightly different tactic for managing images. Since article images are fairly useful for illustrating points made in the prose, we felt they were first-rate content important enough to have available to users even if JavaScript was not available. For that reason, we chose to implement Sebastiano Armeli’s jQuery Asynchronous Image Loader (JAIL).

The JAIL markup pattern is pretty simple:

<img class="jail"
    src="data:image/gif;base64…"
    data-src="/r/5-3.png" alt=""/>
<noscript><img src="/r/5-3.png" alt=""/></noscript>

The markup includes the data URI version of a 1x1 alpha-transparent GIF with a data-* attribute indicating the location of the real image. JavaScript will load that image asynchronously when they user scrolls to within a certain (configurable) distance of it in the flow of the document. This means you don’t actually download an image unless we’re pretty sure you’re going to see it.

The noscript is there to provide a non-JavaScript alternative.

We Removed the Share Widgets

Well, that’s not totally accurate. We didn’t remove links to share our content on your favorite social and professional networks, but we did jettison the JavaScript code provided by these networks and went with good old fashioned links instead. We did so for a two primary reasons:

  1. Using third party widgets allows those third parties to track your users and regardless of whether they admit to doing anything with the knowledge that you are viewing our content, we don’t like the fact that they could.
  2. Even though CDNs deliver these widgets, they are an additional resource to download and, moreover, an additional JavaScript to execute. Numerous sites have seen third party widgets drastically slow page rendering and we wouldn’t want that.

The Numbers

You’re probably wondering the overall impact of these changes. The table below has the details, but the changes generally dropped the page size by a third or more.

A Comparison of Page Weights on WebStandardsSherpa.com Before the Overhaul and After
PageScreen SizeJavaScript?Original SizeNew SizeSavings
Homepage Small No 313 kb 181 kb 42%
Yes 376 kb 259 kb 31%
Large No 313 kb 189 kb 40%
Yes 810 kb 470 kb 41%
Curing the Jet Blues Small No 532 kb 258 kb 52%
Yes 720 kb 515 kb 28%
Large No 532 kb 189 kb 50%
Yes 756 kb 263 kb 28%

And then there’s the added benefits of fewer asset requests overall and better use of the CDN and caching. So in addition to better serving mobile users from a visual design standpoint, we are also improving things when it comes to experience design. And we’re making it cheaper to read our content for those of you on a metered internet connection.

Author’s Note: Credit where credit is due, Jeff Bridgforth implemented the vast majority of these changes. Thanks for all your hard work Jeff!

Going the Extra Mile

As with any project, there’s always more ways to improve the experience. We can (and probably should) do more to decrease our overall page weight through use of sprites and SVG. Additionally, I’m sure there is more content we could inject asynchronously. And, on the server side, we could be far more aggressive with caching to improve the speed of server responses.

The truth is that no matter how good you get at optimizing performance, there’s always more you can do.

Pitfalls to Avoid

  • Don’t wait until the end of a project to consider the experience of users on small screens and devices on mobile networks.
  • Don’t structure your media queries desktop-first. If you go mobile-first, you can greatly reduce the download for small screen devices since most browsers will not download any background images that reside in media queries they aren’t applying
  • Don’t use display: none to hide images on small screens; they will still load the images, the user just won’t be able to see them.
  • If you’re using multiple style sheets or JavaScript files, consider concatenating the crucial bits into single files and then lazy-load the rest.

Things to Do

  • Follow the philosophy of progressive enhancement: star with a solid, universally usable experience and layer on usability and design improvements for larger screens and more capable devices.
  • Use lazy loading to asynchronously inject any supplementary content (including images).
  • Minify everything!
  • Banish 3rd party widget code.

Further Reading