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.
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.
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.
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:
|Boing Boing||E (55)|
|The New York Times||E (52)|
|Daring Fireball||C (74)|
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.
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?
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
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
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.
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.
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.
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).
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.
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.
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.
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.