You are here

Tips for speeding up a Drupal site on the cheap

Error message

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in _menu_load_objects() (line 579 of /usr/home/mazurr/public_html/sites/includes/menu.inc).

This may seem like an odd page to have on an art site, but don't forget, I put food on the table by being a webdev, and Drupal's my thing right now. I've been doing a ton of tuning on the Harvard SEAS site and want to both document and share some of the things I've found. If it helps someone else, wonderful... if all it does is remind me what worked for me in the past, well, that's wonderful, too.

  • Use your cache

    While this seems like a no-brainer, I see the cache turned off on almost every novice site I've ever dealt with (and made the same mistake myself at first). When asked, the content maintainers will tell you it's because content takes to long to make it out to the public, which is a legit concern. There are ways to mitigate that, though, and I'll talk about that later.

    Meanwhile: You. Must. Use. Your. Cache.

    Currently the Harvard SEAS site has a cache set to Minimum cache lifetime: none and Expiration of cached pages: 1 day -- we use a bit of a trick to make sure that time-sensitive pages escape that long cache life, as you'll see if you keep reading.

  • Use an External Cache

    This isn't exactly "on the cheap", but if you have access to an external tool such as Varnish or Memcached, use it.

  • Use a Cache Warmer

    A cache warmer is simply a script that tries to hit every page (or an important subset of all the pages) on your site before your visitors can -- it gets the slow uncached page to allow your visitors to get the cached page. If you're using Drush, check out the Cache Warmer module as it will do most of the work for you. If you can't use Drush, it's not difficult to code up a quick and dirty PHP script that will do the same thing, though probably less elegantly. Obviously you should schedule your warmer to run after caches are cleared or expected to expire.

    Be careful with how often you set your warmer to run and how much you have it warm -- I once successfully DoS'd my own site with a warmer. You'll need to experiment. I find that frequest refreshes of a limited amount of popular content and less frequent of other content works well.

  • Be careful how often you run system_cron

    system_cron has an unpleasant side effect of clearing your cache -- the more often it runs, the more often your cache is refreshed and the more likely a visitor is to hit an uncached page. This is a tricky one, because system_cron will run every time your overall cron runs and sometimes you need your cron to run fairly often.

    We get around this problem by using Elysia Cron, a module that breaks out your cron hooks into multiple settings so that you can run each on its own schedule. So your scheduler module can run every 15 minutes while system_cron runs once a day. You'll need to play with these settings to find out what's appropriate for your particular site.

  • Use a tool that selectively clears time-sensitive information from your cache

    At SEAS, I use Cache Expiration and Acquia Purge -- note that AP is only useful if you're on Acquia Cloud, but Cache Expiration can be used anywhere. Cache Expiration allows changes to content to immediately propagate out past the Drupal cache (Acquia Purge then hooks into Varnish to make sure it clears, too). It hooks into Rules as well, so that if you have a page that's in a View or Promoted to Front Page you can selectively clear pages other than the changed page as well. This is IMMENSELY powerful as it allowes you to set your cache time very high.

    Note that external caches (local cache, etc), may still hold on to the old content. That's generally not a huge issue, but it can be. Safari seems to be particularly annoying about that.

  • Optimize your page size!

    Yes, I know this is the age of fast internet... except that it's not. Cell network users -- a demographic that simply cannot be ignored these days -- sometimes see speeds not much better than old school dialup and far too many plans have data caps. Don't send people overweight pages.

    I'm not going to go into a huge amount of detail here, because this stuff is already all over the web, but:

    • Optimize your images
    • If you're using image fields in Drupal, also use image styles where appropriate to size down your images. This is especially useful if you're using Views to make News or People listings and want to show a smaller version of an image that needs to be large on its primary page. This is probably the single most important non-cache thing you can do to improve your page load time
    • Compress your pages and CSS/Javascript
    • Write efficient CSS and Javascript (this topic is a book in itself; you're on your own here)
    • Sprite images where you can
  • Carefully set your Views cache

    Views are stupid slow sometimes, but you can't live without them. Always set a cache for your Views in the Advanced section of the settings. If you can't get away with a strictly time-based cache on your Views, check out Views Content Cache a tool for clearing Views cached based on changes made to content of a particular type.

  • Use Authcache

    I'm stretching a bit recommending this because I've never used it (we don't do auth for anything other than editors on the SEAS site), but it bears mentioning. If your site is authenticated and most content is not personalized, this module is supposedly a god-send. Without Authcache, authenticated users will not get cached content -- this is great if you're editing a page, but not so great if you're reading one.

  • Beware of your own custom code

    If you're just starting out in Drupal, it can be exhilarating to write that first custom module, but it's you're not a master at designing efficient code, you may ruin all the work you've done to speed up your site.

    I've got no witty solutions for this. I been doing this for 15 years and have a degree is the subject matter and sometimes I still write code that I should be shot for. Just be aware that sometimes you can be your own worst enemy.