The performance of your site – the speed with which it loads and responds to user actions – is crucial to its success. There’s a lot you can do to improve this.
Why performance is important
The importance of performance in human-computer interactions has been recognised since the late 1960s, decades before the World Wide Web emerged. Faster is always better. There are three key time thresholds which affect the user’s perception of the system’s speed.
-
One tenth of a second.
If a system (or a web page) responds to a user action, e.g. clicking or scrolling, in less than a tenth of a second, the user perceives it as instantaneous. No problem there!
-
One second.
If the system takes a second to respond, it’s no longer instantaneous, but the user’s thought flow is uninterrupted, and the experience feels seamless.
-
Ten seconds.
Much over a second, and the user perceives a noticeable delay; the experience is no longer seamless. After ten seconds, the user’s concentration is broken, and they need to restore their focus when the system finally responds.
Even if an action takes longer than ten seconds, all is not lost. If you signal to the user beforehand that the action may take some time, and if you can provide a progress indicator while the action is taking place, the user is less likely to abandon the page. Still, an action that takes ten seconds is seriously testing your user’s patience.
Users abandon slow websites
Unlike conventional desktop programs, which the user perceives as “theirs”, websites receive far less tolerance for sluggish performance. Users spend most of their time sites other than yours, and will look for what they need elsewhere if your site doesn’t perform satisfactorily. A wealth of studies confirms this:
- In 2009, Bing and Google both demonstrated that, for every fifth of a second increment in server response time, a measurable percentage of users abandoned the page entirely.
- Amazon found that it increased revenue by 1% for every 100 milliseconds of improvement (Greg Linden, 2006).
- In 2010, Google introduced a Site Speed metric: all else being equal, faster sites rank better in searches. Given the near-religious devotion to search engine optimisation (SEO) in many quarters, this got a lot of people’s attention!
Testing your site
There are several online services that will test your site’s performance and give you a detailed report, for free. Google’s Page Speed and Yahoo!’s YSlow are considered the leaders. I use GTMetrix, which combines the two.
A GTMetrix report will show a rating from each service, both as a report-card-style letter (A to F) and as a percentage. Some notes:
- You should aim to get an A and 90% or better from each service.
- Each service runs 20 to 30 tests, listed in descending order of importance. If you get poor grades on the first 5, top grades on the remainder won’t help.
- Don’t be surprise if you get wildly different grades from each service. Google and Yahoo! are in broad agreement about performance, but vary in the priority they attach to each item.
- If you get bad grades from your first test, take heart. Take any random selection of well known websites, enter their addresses, and see how bad most of them are. Then feel encouraged by the thought that, with a little work, a top grade is within your reach.
Tips to improve performance
The web is awash in recommendations to improve your site’s performance, many of which are highly technical, borderline obsessive, or both.
Recognise that some recommendations are easy to implement and generate a large return, while others are hard to execute, and only offer marginal gains. Apportion your time accordingly. Here are some tips, based on my own experience, starting with the most worthwhile.
-
Deploy a proper .htaccess file.
This is one of the easiest improvements you can make. In a matter of minutes, you can take care of caching, gzip compression, and other valuable configurations. You can knock a third or more of the effective size of your pages, and you'll get an A grade on several of the more important tests.
You can copy and paste code from several good examples around the web. Feel free to use the example below as a starting point.
-
Optimise your JavaScript.
Except for large libraries such as jQuery, consolidate all your JavaScript into a single file. Instead of placing this file inside the
<head>
section, where it usually lives, move it to the end, just before the closing</body>
tag; this will prevent it blocking other resources downloading. -
Minify your JavaScript and CSS.
If using a CSS preprocessor such as SASS, you can have this done automatically every time you edit the original file. With both JavaScript and CSS, you can accomplish the same thing with a utility such as Minify. If you’re deploying your CSS and JavaScript without a automatic minification tool, you can still minify your files using one of the online services, although you must take care to preserve editable originals of your files. Note that JavaScript typically compresses better than CSS because many tokens (variable and function names) can be replaced by single letters, while all CSS tokens must remain unchanged, so CSS minification is limited to the removal of whitespace and comments.
-
Optimise your CSS.
Except for large library files, consolidate all your CSS into a single file, and place it in the
<head>
section of your document. Avoid@import
and CSS expressions. Be frugal with descendant selectors; long selectors such as#main .content .sidebar .first p span.callout
can nearly always be pruned without any ill effects. -
Compress your images.
Even the latest version of Photoshop is not the best tool for making your PNGs, JPEGs and GIFs as small as possible. Online tools such as Smush.it and TinyPNG will reliably shave worthwhile extra bytes off your images without sacrificing quality. Even better: see if there are any images you can do without entirely. Removing just one photo is a far more effective strategy than endlessly optimising and minifying your JavaScript and CSS. The self-explanatory One Less JPG movement is dedicated to this pursuit.
-
Pay attention to off-site assets.
If you're running a content management system such as WordPress, Drupal, or Joomla, there's a good chance you'll be using functionality that's stored on a third-party site. Even if you're not, you're probably using an analytics program such as Google Analytics. PageSpeed and YSlow will likely pick up on this, and recommend that you change various server settings, consolidate multiple files, optimise images, and so on. In most cases, you won't have access to the server in question, so you won't be able to address these. Don't beat yourself up over these, but at least take the time to evaluate if the functionality is worth the performance hit.
-
Deploy a CDN … maybe.
Several experts recommend placing all your static assets – typically, JavaScript, CSS, and image files – on a content distribution network, or CDN. Not only are CDNs tuned for performance, but they will distribute your content over a worldwide network of servers (hence the name), and serve up files from whichever server is closest to the end user.
You'll notice that YSlow is big on CDNs – once you've taken care of everything else, you'll see a big "F" at the top of your YSlow score sheet if you don't have a CDN. But unless you're running a high-traffic site with a worldwide audience and are fearful of your site slowing down at peak times, don't sweat this. CDNs can be expensive – the big names such as Akamai and Edgecast can run you thousands of dollars a month – but you can also be up and running for pennies a gigabyte, so shop around if you decide to go this route. I'm currently using KeyCDN on this site. It works well, it's inexpensive, and, once it's set up, needs no care and feeding.
When you’ve taken care of all of these, you’ll likely be over 90 for both tests, and you’ll be ahead of most if not all of your competition. After that, any remaining wins will be small and hard fought.
Downloads
Download the example code. Instructions are at the start of the file.