We recently upgraded our intranet that we use for internal planning and communications to Drupal 6. As part of the upgrade, I wanted to redesign the interface to make it faster. From the start I wanted to push the limits of the design within the constraint that every major graphical element should come from a CSS sprite — i.e. a single image that holds all the different graphical components needed. This reduces the number of HTTP requests per page which is a major factor in perceived performance. While CSS sprites are most commonly used for things like buttons, navigation, and icons, I wanted to try something a little more daring – get nearly every graphical component in the theme including the logo, header, default user pictures, and bleeds into a single request.
While it’s actually not technically possible to achieve all design possibilities by using a single sprite, good planning allows you to get away with more than usual. You can see the main image above that gets sliced and arranged in CSS into the final theme clocks in at a modest 29k. By comparison, the standalone jquery library compressed is 15k.
The following are prerequisites for a designer who’s interested in taking this approach:
- You need to have a strong working knowledge of CSS and HTML
- You need to have the DOM and specific markup for implementation in mind at all times while designing
- You need to be willing to make design decisions on the basis of performance factors
I can’t stress #1 and #2 enough. Being intimately familiar with the final medium of delivery is crucial to any designer or artist’s success and planning around the strengths of CSS and HTML and the specific markup that Drupal generates is particularly important. Here are, for example, some performance-oriented decisions that I made while approaching our design:
- Limiting the color palette of our icons to a small set of shared colors and gradients. This allows them to appear sharper and richer when the final sprite is saved as an 8-bit indexed image to increase speed.
- Limiting the number of bleeds, gradients, and other graphical flourishes on the site, and making the shared ones as robust and multi-purpose as possible.
- Using a fixed-width layout with thin (780px) and wide (960px) variants rather than a fluid width theme.
The final theme in action looks like this:
The switch from dozens of images in the theme to a CSS sprite has added a noticeable zip to our team intranet. In an upcoming post, I’ll describe some of the other build decisions and tools we used to increase Drupal’s speed.