It always happens. Our websites get to be too slow. We keep adding features and graphics, and JavaScript doodads on our sites, and the website performance slows to a crawl. That’s an embarrassment for any web developer, especially one that is proud of creating responsive sites. Before you can speed up the website, you have to figure out exactly what’s causing the bottleneck.
The first step in any sort of performance optimization is to know what is running slowly and using up resources. Fortunately, many tools are available to help you with this measurement task. In this article, I discuss four tools and techniques for measuring your website's performance, using my own blog as an example.
Start with command-line tools
The easiest way to get started is by taking advantage of tools you probably already have installed, either on your Linux- or Unix-like server or on your Mac OS X system (these may be available for Windows as well, but that’s outside my area of expertise).
wget is a Swiss Army Knife of command-line tools for interacting with remote web and FTP servers. It can fetch a single page, or spider an entire site and mirror it on your hard drive, and just about everything in between. Instead of wget, your computer may have curl, which is a similar tool with different options. The ideas that follow apply in either case.
The simplest way to use wget is to just ask it to retrieve a single page:
$ wget http://petdance.com/
--2012-10-13 16:28:26-- http://petdance.com/
Resolving petdance.com (petdance.com)... 72.14.176.61
Connecting to petdance.com (petdance.com)|72.14.176.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 86630 (85K) [text/html]
Saving to: ‘index.html’
100%[===================================>] 86,630 --.-K/s in 0.1s
2012-10-13 16:28:27 (652 KB/s) - ‘index.html’ saved [86630/86630]
wget downloaded a copy of the home page of my website, and saved it to my local computer. I don't know how long it took to download, though. The "in 0.1s" on the progress bar line is a leftover artifact of the progress bar and does not tell us the download time. I could run it again and count "one one-thousand, two one-thousand," and that may be accurate enough for playing hide & seek on the playground, but it is not for measuring performance.
Instead, I use the time command to call wget for me. Now, when I run wget, time tells me at the end how long it took.
$ time wget http://petdance.com/
--2012-10-13 16:39:59-- http://petdance.com/
... previous output omitted ...
real 0m0.620s
user 0m0.002s
sys 0m0.004s
The "real" time is what we're interested in, sometimes called "wall clock time" as opposed to your computer's internal system clock, which is represented by "user" and "sys".
So 0.620 to load a page gives us an idea of how long it takes to load the page. It's not Google speed (load times of 0.114 for me), but it's not awful.
The thing is, it's not accurate yet. We've only downloaded the HTML page, but not the rest of the stuff that the page needs to load.
I need to use the -p or --page-requisites option to download the rest of the files needed to display the page. I also use the -nv or --no-verbose option so that I don't get all the intermediate diagnostics and progress displays during the download. The -H option retrieves content from other hosts, such as a JavaScript file from speakerdeck.com. Finally, I use --delete-after to tell wget to delete the files it creates; I don't need them cluttering up my system.
Once I run wget with these command-line options, I have a better idea of what is going on in my page. (I modified the output to fit page width and make it easier to pick out the important parts.)
$ time wget -nv -p -H --delete-after http://petdance.com
2012-10-13 23:18:44 URL:http://petdance.com/ [86630/86630]
2012-10-13 23:18:44 URL:http://petdance.com/robots.txt [44/44]
2012-10-13 23:18:44 URL:http://speakerdeck.com/robots.txt [204/204]
2012-10-13 23:18:44 URL:http://petdance.com/.../style.css [1977/1977]
2012-10-13 23:18:44 URL:http://petdance.com/.../jquery.js?ver=1.7.2 [94861/94861]
2012-10-13 23:18:44 URL:http://petdance.com/.../smoothscroll.js?ver=1.0 [2665/2665]
2012-10-13 23:18:45 URL:http://speakerdeck.com/.../embed.js [9968/9968]
2012-10-13 23:18:45 URL:http://petdance.com/.../icon_sad.gif [171/171]
2012-10-13 23:18:45 URL:http://petdance.com/.../twitter-120x120.png [11365/11365]
2012-10-13 23:18:45 URL:http://petdance.com/.../rss-120x120.png [10658/10658]
2012-10-13 23:18:45 URL:http://petdance.com/.../google-plus-120x120.png [10104/10104]
2012-10-13 23:18:45 URL:http://petdance.com/.../email-120x120.png [14565/14565]
2012-10-13 23:18:46 URL:http://petdance.com/.../algh_150x225.png [16019/16019]
2012-10-13 23:18:46 URL:http://petdance.com/.../style.css [32765/32765]
Downloaded: 14 files, 285K in 0.4s (747 KB/s)
real 0m2.071s
user 0m0.005s
sys 0m0.013s
From these results, I see that I downloaded 285K of data in about 2.1 seconds. I can look at each of those files and make sure that I know what's being downloaded. That’s the first place to look for trouble. For example, just now, I found myself wondering what is causing that smoothscroll.js to be downloaded, because I haven't knowingly enabled anything like smooth scrolling on my blog. The best diagnostic tests are the ones that make you say "Hmmm...."
Simple command-line tools like this are fine for getting a rough sense of how fast things are. However, they don't give any detail of the bottlenecks, and they don't analyze the content or the traffic. wget also can't execute dynamic content. In the case of my blog, that speakerdeck.com embedded JavaScript fetches more data from the speaker deck website if the page is loaded from within a browser. Fetched from wget, however, we miss the true user experience of loading the page in a browser.
For that level of analysis, you need to use a browser plug-in, such as Page Speed or YSlow.
Browser plug-ins
There are many browser-based plug-ins, but the two most popular are YSlow and Page Speed. Both are excellent tools with many similarities, but they emphasize different areas. In this article, I use them in Firefox, embedded in the Firebug plug-in. (Firebug is itself an indispensible plug-in for web developers.)
Page Speed is by Google. It's only available for Chrome and Firefox.
YSlow is Yahoo's tool, and is available on Chrome, Firefox, Safari, Opera, and even the Unix/Linux command line.
Both tools load a page from within the browser and analyze various aspects of the page loading and page presentation against a set of rules. The report is presented in a debug window below the main browser window. YSlow assigns a letter grade, from A-F; Page Speed shows a color code of green, yellow, or red. The page reports included links to detailed discussion of each rule and why it's important. Just reading these rules is an education for any web developer, even if he doesn't always follow them.
Both these plug-ins can run automatically on every page load. That is handy, because you can click around your website and see the report colors change on different pages.
Both tools provide an inventory of components on the page, such as the images and scripts that were loaded. Where the example with wget above shows just the size of each component, both Page Speed and YSlow also give details about how long it took to transfer the component. This is great for discovering, for example, which of your social media "Share This" buttons are dragging down performance. You can also click individual components to see a dump of the HTTP response headers for that component.
Page Speed
Page Speed covers some transfer-level checks like "Enable Keep-Alive," but most of the checks relate to the content once it hits the browser, such as:
- Inline small JavaScript
- Defer parsing of JavaScript
- Minify HTML
- Specify image dimensions
- Avoid CSS @import
- Combine images into CSS sprites
- Put CSS in the document head
- Optimize the order of styles and scripts
Page Speed's content analysis gives detailed explanations of how to fix the problem, or can even fix it directly. Clicking through a "Remove unused CSS" rule gives a list of CSS selectors that are not used to render the page. Click on "Minify HTML," and Page Speed creates a minified version of the HTML file with unnecessary whitespace stripped, which you can then save for your use. It can also do this for CSS and JavaScript.
YSlow
YSlow's distinct checks are more about the page transfer than the content itself. For example:
- Make fewer HTTP requests
- Enable compression
- Use a CDN (content delivery network)
- Reduce DNS lookups
- Avoid URL redirects
- Configure entity tags (ETags)
- Add Expires headers
- Reduce cookie size
YSlow's Tools tab has features similar to Page Speed's minifiers, as well as tools like JSLint that check JavaScript code for potential errors.
It's surprising that both of these tools are so text-heavy, with few graphic representations of the data being presented. One handy chart is YSlow's graph of the breakdown of which component types are taking up the most data on the pipe. Even then, it's frustrating that the colors are so indistinct.
GTmetrix
Page Speed and YSlow are fantastic tools, complementing each other rather than being in competition. Both are worth installing. For those who don't want to deal with browser plug-ins, however, a site called GTMetrix has you covered. When you submit your site to GTmetrix for analysis, it runs both Page Speed and YSlow and reports the results from each tool in different tabs on a single webpage.
Certainly the prettiest feature of GTmetrix is its timeline report. It looks like a big Gantt chart; but instead of tracking project tasks, GTmetrix shows how long individual components took to load. In this view, slow third-party components stick out like a sore thumb.
While GTmetrix combines the features of Page Speed and YSlow as well as adding its own, it's not perfect. It takes longer to analyze your pages than it does to do it in your browser, and since it's a service with a queue, you are at the mercy of how many people are using the site at the time. Also, GTmetrix won't work for websites not available publicly, such as a development website behind a corporate firewall.
Wrap-up
I discussed four ways of checking your web site's performance, but I only scratched the surface of what's available. Steve Souders, probably the biggest name in web speed analysis today, as well as the creator of YSlow, recently wrote a blog post listing about 40 different Web performance tools.
Dig in, play around, and find the tools that best serve your needs. Don't get discouraged by what you discover; not every site has the money of a Google or a Yahoo! to throw at speeding things up. Instead, see each data point as an opportunity to make your sites just a little bit faster.
See also: