The Great American WordPress Hosting Speed Test, pt. 2: Front End

written by: Andrew Martin | October 20, 2014

00305

In part one of this series, I signed up for, and set up an identical test WordPress site on, five popular web hosting packages, each being specifically marketed to WordPress users.

As physical proximity plays a key role in determining page load time, I was interested in the physical location of each hosted test site. Here’s what I found by typing the IPs of my hosting accounts into ip2location.com:

I found the above information very interesting in that three of the five tested hosting companies don’t appear to handle the physical hosting of sites under the tested packages. Instead, they provide management software and support, and contract out the hardware responsibilities to others. This is not a criticism in any way; great support and a well-designed admin UI are valuable assets.

Even more interesting to me was noticing that my Media Temple and GoDaddy accounts actually had the same IP address, which would seem to suggest that the sites were hosted on the same server, despite the companies appearing to have no connection to one another. Make of that what you will.

The Test Procedure

I wanted to test each hosting package in a variety of situations, so I used three testing computers: one in Milwaukee, WI, one in San Diego, TX (not a typo - it exists), and one in Orlando, FL - each of which ran the test four times per hosting account. Each computer ran the test once on a weekday morning, once on a weekday afternoon, once on a weekday evening, and once on a weekend afternoon. The result was each hosting package being tested a total of 12 times (3 test computers x 4 test times). The server cache (as well as the browser cache) was cleared immediately prior to starting each test.

As WordPress is a database-driven CMS, server-side caching is commonly used in an attempt to increase performance. In fact, a caching system optimized specifically for WordPress is one of the main selling points for WordPress-specific web hosting plans. Server-side caching, combined with the client-side caching typically done by the user’s web browser, generally results in faster page loads as a user’s session grows in duration (i.e. when a user visits multiple pages on the site in the same visit, they tend to load more quickly than the first). Therefore, I felt the test most accurately representing “real world” use of a WordPress site would include visiting the home page, then several internal pages in succession. This click path was used for each test:

1. Home page
2. Main blog archive
3. Single blog post
4. WooCommerce shop overview page
5. Single WooCommerce product
6. Adding the product to the cart
7. Viewing the cart
8. Proceeding to checkout
9. Completing the checkout process

To time the loading of each page, I used Firefox’s Network panel (located under Tools > Web Developer), which displays a timeline of each asset loading. To prevent one (or a few) slow page load from skewing the test results, I used the median of all page loads for each hosting account, rather than the average. In total, each host loaded 108 pages (12 tests x 9 pages per test).

The Results

While all the hosts performed reasonably well, Flywheel was the clear winner. In fact, Flywheel was the fastest host on eleven of the twelve tests. Prior to signing up with Flywheel to perform this test, I’d had no experience with them (apart from high-fiving one of their reps at WordCamp) - we don’t host our site on Flywheel, none of our clients are hosted on Flywheel, and I’m not a Flywheel affiliate (they don’t even have an affiliate program). Although speed isn’t even close to the only important factor when choosing a web host, I’ll admit I was really impressed with Flywheel’s speed.

Given the (seemingly) single server hosting both the GoDaddy and Media Temple installs, it wasn’t at all surprising that the two had nearly identical load times.

What about proximity? Logically, a hosting company would have an advantage in the test if their server happened to be closer to my testing computers than the servers of their competitors. By calculating the approximate distance between the servers and the testing computers, and averaging them, I found that it appears that proximity didn’t have a significant effect on the test rankings; SiteGround’s server was, on average, the closest to the testing computers, but performed the slowest of the five tested hosting companies. The GoDaddy/Media Temple data had about 27% further to go, on average, than the New York-based Flywheel server’s data, but took about 51% longer to arrive.

Now What?

Do my test results mean that your website would definitely run faster being hosted on Flywheel than it would on SiteGround? Absolutely not. In the real world, no two websites are alike; they have different content, different images, different plugins, different themes, different everything. It’s possible that one hosting package’s caching configuration handles sites with a lot of database calls better than another’s. Some hosts also offer built-in CDNs; these would oftentimes be a good solution for image-heavy sites. Finally, these tests were performed on a site that was receiving essentially no traffic. It’s certainly possible for a host to perform better than another on low-traffic sites, but perform far worse once the site becomes more popular. The bottom line is that to truly know which hosting solution is the best fit for your site, you’ve just gotta try them.

Site speed for the front end user is obviously a hugely important piece of the puzzle, but it’s not the only piece. How do these WordPress-tailored hosting plans perform on the back end? After all, when you’re performing a large number of administrative functions in the WordPress admin area, seconds add up fast, and a slow experience can quickly become frustrating. In the third and final installment of this series, we’ll test basic administrative functions on the five hosting solutions as well as put them on the clock when restoring a full site backup.