Drupal Performance: A Real Life Example

Posted: April 1, 2013 under Drupal, Web Performance

I thought it would be fun to do a little experiment. I have a project for a client that is wrapping up and one of the final things I'm doing for them is optimizing the site's performance. The client is a good candidate for this little demonstration because they have their Drupal site in a shared hosting environment, something that's quite common, but often limiting with regard to what you can do to improve performance. 

So here's how this will work, I'm going to step through a series of basic performance tweaks and then run the site through the Pingdom Tools page load tester. This will give us a good idea of what sort of improvement we get with each step.

At the end of the post we'll talk about a few other things you might be able to talk your host into providing that will help take your site's performance to the next level.

Getting a Baseline

Let's start by getting a baseline of where things stand with no performance optimization at all. Take a look at the screenshot of the first test result below.

Drupal performance test result 1

You'll see that the load time was 4.09 seconds and the page size is 1.4 MB. This site has a large image slider and several views on the home page, and those things definitely add bulk. It's interesting to note that the average size of a web page is now over 1MB. There is a lot of talk about mobile first, yet we keeping adding things that end up increasing page size. There are always trade-offs, I suppose.

Anyway, let's start optimizing by enabling the basic Drupal performance options.

Drupal performance settings

For an explanation of what these settings actually do, check out this post by Albert Skibinski. Now that we have these enabled, let's head back to Pingdom tools and re-run the test. If you're following along using your own site, be sure you look under the settings and select the server you want to test from. If you don't, the test results may vary considerably due to server location. 

Here's the results of our second test.

Performance test 2

Wow, pretty good! We've shaved off almost three seconds from the load time and decreased page size by 300 MB. Obviously this is a big improvement, but let's take this one step further. We're going to enable and configure the Boost module to see if we can get the page load time down even more.

Rather than get into the nitty gritty of installing Boost, I'll just refer you to the this set of instructions, but I do want to leave you with a couple of tips. First, remember to uncheck "Cache pages for anonymous users" under Drupal's performance settings or Boost won't work properly.

Also, if you have any pages you want excluded from Boost's caching, be sure to list them on the main Boost configuration page. Good candidates here are things like shopping cart pages. I learned that one the hard way!

Let's go ahead and see what sort of effect Boost had on the page load time.

Performance test 3

The change this time is less dramatic, but the difference of .18 seconds actually represents an improvement of 14% for very little effort. Definitely worth it. Now you may be wondering what the difference is between Drupal's default caching and Boost. With default caching your pages get stored in the database. Boost, on the other hand, stores your pages as static HTML files.

In the case of my client, they're using a cPanel shared hosting environment provided by their university, so they're getting a much better set up than most commercial web hosts will provide. With the $7 a month commercial packages you see offered, the sites are jammed in like sardines. If this is your situation, you'll probably see a bigger improvement with Boost than we did in this example.

Taking it to the Next Level

If you're using shared hosting, the next suggestions might be tough to pull off, but it never hurts to ask! I think that perhaps the most likely thing you'll be able to have implemented is gzip. By using gzip you can significantly decrease the size of your pages - smaller pages = shorter download times.

Another thing you may look into is Memcached. If your host agrees to do this for you, be sure you have the module installed first and let them know you're working with a Drupal site.

Unfortunately, I think these two might be the only server side things you'll get with a basic web hosting account, but there may be exceptions. You can get your own managed virtual server for about $30-$40 per month and in that case you'll likely be able to implement these plus a whole lot of other cool things like APC and Varnish.

Another suggestion is to look for a host that specializes in Drupal. There are some large hosts offering the $7 per month deals that say they specialize in Drupal, but I think that's wishful thinking. I don't want to get into listing web hosting companies in this post, but let Google and your good judgement guide you.

A final thing that may help you out is an article Tim Millwood recently wrote for .NET magazine. It has some good Drupal performance tips that expand on what I've discussed in this post.

If you'd like to comment about what I've written, you can do so here.

About the Author

John Hannah

I’m John Hannah, a front end developer at Lullabot . When I'm not building websites, I travel as much as possible and enjoy hanging out with my wonderful family. My favorite place to spend my coffee breaks is Twitter, so please feel free to connect with me there.