Making Client Sites Faster

This past weekend, I had the opportunity to speak at WordCamp Chicago. The topic I presented, “Making WordPress Faster: Front-end Performance Tips,” was a introduction on how to analyze and speed up websites built with WordPress. Though, the talk itself was WordPress-specific, the underlying concepts are applicable to any client site, whether it be coded in WordPress, Expression Engine, MovableType or none-of-the-above. At Weightshift, we have made performance tweaking a standard part of our development cycle on all projects. I’d like to take a moment to share our process, and some of the tools that we use.

Before delving into the topic, I’d be remiss if I didn’t mention that much of what I’ve learned about this topic has come from Steve Souders. Steve is a bright (and incredibly friendly) individual, who has occupied the role of web performance guru at both Yahoo! and Google. Steve has a gift: the ability to take complex topics — like website performance — and distill them into very simple, usable practices — like those found in his book, High Performance Websites. Among his many accomplishments, Steve is the creator of Yahoo!‘s YSlow, a Firefox/Firebug add-on that grades web pages based on a ruleset of performance criteria. While there are many performance analysis tools (including Google’s Page Speed), I’ve chosen to center both my presentation, and this blog post, around the results of YSlow.

80/20 Principle

If we take a look at the network activity of a website, we can see that the actual HTML page accounts for a very small percentage of the page’s total load time.

In general, we say that ≤20% of the page’s load time is attributed to downloading the HTML document (seen in orange above), and the remaining ≥80% is spent retrieving images, stylesheets, scripts, etc. (seen in red above). The 80/20 rule states that if you’re looking to improve a site’s performance, then you’ll have more luck looking at things which affect the 80% than you will looking at the 20%. In other words, server and database optimizations are important, no doubt, but you’ll have an easier time speeding up your site if you look at the images, scripts, etc…

Based on the 80/20 principle, YSlow examines factors that affect the 80%, and returns with a letter grade to denote how well or poorly your site performs.

Why should we care?

Recently, Google announced that they are starting to use page speed in their calculation of Page Rank. Also, improvements to your YSlow score can help with reducing bandwidth costs (for high-traffic websites), improve user experience and impact conversion rates.

What’s a typical YSlow score?

In my experience, sites with little or no web performance tweaking get a D or worse. Let’s take a look at a few sites out there:

Website YSlow Score
Boing Boing E (55)
Dribbble D (66)
The New York Times E (52)
Daring Fireball C (74)
Zeldman.com D (60)

It’s not my intention to pass judgment on these sites or their creators. The list merely serves to highlight that this issue affects sites of all types. The truth is, as an industry, website performance isn’t high on our list of best practices, and it’s not something that just happens by itself. Case in point: right before WordCamp, I realized that I had never performed these techniques on my personal website, and it had scored a D. Whether it’s a huge commercial site like the New York Times or your personal WordPress blog, this is something that we all need to build into our workflow.

At this point, I recommend installing Firebug/YSlow, and taking a look at one of your own sites. How did you score?

Assuming that you fared like the others, what can you do to improve a site’s YSlow score? More importantly, what can we do, as a designers and developers, to make sure that our clients’ sites perform well?

3 Basic Concepts

YSlow itself contains 14 rules, and Google’s Page Speed contains 26. All of these rules and practices are important, but for simplicity’s sake, we’ll condense them into 3 basic concepts:

1. Make fewer file requests
2. Download files concurrently
3. Keep things in the cache as long as possible

Make fewer file requests

Summary: If you request fewer files, it will take less time to load the website.

Let’s take a look at tools we can use to reduce the number of stylesheets, scripts and images that we download:


What if instead of listing multiple <script> tags in a row, you could list a single file that merged all of the other files into one file, removing extraneous characters? That’s exactly what minification is. Using software like PHP Minify, we are able to take all of our JavaScript or CSS files, and concatenate them into one file, preserving the correct order.

The main benefit of using a minifier is that you now reduce the number of file downloads (which, in turn, increases your YSlow score). But, there’s also a secondary benefit: the minifier does not alter your original files, rather it creates a new, combined file, on-the-fly. So, you are still able to alter your client’s website by editing the individual files, and the minifier will automagically create a new, combined file.

This is an important concept: as design studios, we must make sure that the sites we hand off to clients are maintainable in our absence. Whatever we code, it must be easy for the client, or future developers, to read and edit.

With Minify, all of the original files remain in tact, and can be edited individually. It’s very maintainable.

CSS Sprites

Spriting is a technique in which multiple background images are combined into a single image. That image is then used by many CSS rules, wherein only part of the image is shown as needed.

Typically, creating and maintaining CSS sprites has been a real pain. That is, until SpriteMe.org came along (also a Steve Souders creation). SpriteMe does all of the heavy lifting for you. With the click of one JavaScript bookmarlet, you’ll have the combined image and associated CSS styles.

Note: I recommend that you use this tool judiciously. The use of sprites may, down the road, make it difficult for a client to update images. At Weightshift, we rarely use sprites on client sites. Though, we did use them on SitBy.Us. If you do decide to use sprites on a client project, I recommend creating a README file which outlines the process of how they were created, and how they may be updated.

Download files concurrently

CSS at the top, JavaScript at the bottom

Summary: Download as many files as you can at the same time. Avoid situations in which JavaScript blocks parallel downloading.

Browsers, by default, try to download as many files in parallel as they’re allowed (~2 in older browsers, ~6 in newer, per hostname). However, while the browser is downloading a script, it won’t download any other files (seen in orange below).

By placing CSS files at the top, and JavaScript at the bottom, you allow the browser to download and present content to the user more quickly, without blocking.

Note: It is especially important to put third-party scripts, such as Google Analytics, widgets or ad tags, at the bottom of a page, as delays in delivery can have a serious impact on page rendering.

Google-hosted jQuery

Weightshift is a jQuery shop. When including the jQuery library, we link to those hosted on Google’s CDN (content delivery network). This provides two benefits: if a user has already visited a website which links to the Google-hosted jQuery, then it will already be in the user’s cache — we save 24KB of page weight. If it’s not in the user’s cache, then we get the benefits of a CDN: a faster download from a server which is geographically closer, and a parallel download from a second hostname.

Note: Google hosts a multitude of JavaScript Frameworks in addition to jQuery.

Keep things in the cache as long as possible

Summary: If you’ve downloaded something once, and it hasn’t changed, don’t download it again.

With a very small bit of code added to your .htaccess file, you can tell the browser to cache files for a long period of time, so your client’s users won’t have to re-download files on subsequent visits.

The snippet above sets the expiration date for images, stylesheets and scripts to 30 days from the current date. In addition, it tells Apache to remove ETags, an identifier which often complicates the caching process. Both of these settings can be set in the Apache configuration files, but typically modifying the .htaccess file is an easier process.

Not only does this improve the page’s speed, it can also help save on bandwidth costs for high-traffic websites.

Note: if you decide to use far-future expiration, you and your clients will need to rename files if they are changed, like stylesheets. Or, you can choose to exclude those rules from your .htaccess file.

March Forth and Optimize

All in all, these tweaks take ~1 hour to perform, and should yield you a B to B+ on the YSlow grading scale (about as high as you can expect for non-CDN client sites).

What I’ve covered here only scratches the surface of what you can do with respect to website performance. Think of this as a least-you-can-do memo. If this sort of thing piques your interest, I highly recommend reading Steve’s book and the Yahoo! Developer website. Implementing the full suite of performance rules will make your clients’ sites sing.


Hi. You can or work with us. We're based in San Francisco.


Say Hello

Drop us a line via email:

Work With Us

If you’d like to work with us, complete the Project Inquiry.

San Francisco

7 Hallam St. #2A
San Francisco, CA 94103


We don't have any positions.
Thanks for looking.