Time your website speed with simple command line tools

When doing some initial, rough performance evaluation of a website's code, we can use some common tools which should be available on most desktops. Whether on Mac or Windows, you should have access to a command line (Terminal on Mac, git bash or Cygwin bash on Windows) with the regular "Unix" (POSIX) command line tools or GNU versions of them. You should also have 'curl' (and 'wget'), which is non-standard but very common and useful.

In the following examples, replace example.com with your website and page you want to test.

Step 0: ping example.com

This will show you a typical roundtrip time for network traffic between you and the server. Any other times will be more than this minimum time. This has nothing to do with how you code or configure your website or even configure your server. Ping time is a measure of the physical cable distances between two points, plus the time spent in optical switching hardware. A hard limit is the speed of light directly between two points (usually having to travel across the surface of the Earth rather than a more direct line going though the Earth's crust).

Step 1. Test server response: time curl -I http://example.com

This command tells curl to return only the http response headers, without waiting for all of the html to finish sending. You want this to be within 100-200 ms more than the ping response in step #0. Part of this step, if you skipped step 0, is to do a DNS lookup of the domain name, but after the first time, the IP address should be cached.

Step 2. time curl http://example.com > /dev/null

Now we are loading the whole page, although we aren't requesting all the dependencies - like images, css, javascript, fonts, etc. You want this to be just slightly above the time in #1, not more than 100 ms more. You can run this a few times to see how close the numbers are to each other. You are testing each run sequentially (in order) not in parallel so you are not yet testing how your web server handles many simultaneous requests.

Step 3. DOM Loading

Now we should be ready to do an integration test, meaning testing the server's response, receiving the full html response, and then the browser parsing the html then fetching all dependent resources, and finally painting the completed page and triggering the DOM 'ready' event. This step could be done on the command line using some more exotic tools like Selenium IDE or PhantomJS but we'll skip that for the kind of ad hoc timing we are trying to get here.

Load up Chrome and open the Developer Tools. Switch from Elements to the Network pane. If you haven't already loaded the page, do so now in the URL bar, otherwise reload the page. You will see a bunch of rows and lines show when files/urls were requested, how long they took to fetch, and finally how long it took for the page as a whole to become 'ready'.

Note that some factors besides your own website will affect performance and speed here, e.g. any JavaScript libraries you include from external servers or CDNs like jQuery or Google Analytics or Facebook.