High-Speed Cache

Drupal is great and makes a lot of difficult tasks easier; however, that comes at the price of a slower website as a lot of processing must happen before the page can be rendering and displayed. Most web pages are static and don’t change very often, though, so we can add front-end caching to Drupal so that it only needs to do that work once and can reuse the results for subsequent page requests.

Install the Modules

These are the modules that must be installed. See the Drupal online handbook for details on how to do this.


This is the actual front-end caching module. It configures mod_rewrite to check a cache directory first when a request comes in. If it hits then the user gets the pre-rendered cached version very quickly. When the cache misses, it passes through into Drupal itself which renders the page, sends it to the client, and saves it as an .html file in the cache for the next time it is requested.

You will want to use the development version. There are bugs in the current suggested version that render Boost useless under certain common setups.

Cache Expiration

This module purges cached copies of webpages when changes are made to them. This way, changes appear immediately as is normal Drupal behavior rather than having to wait until the cached version expires of old age.

Global Redirect (optional but highly recommended)

There are numerous different ways to access the same page in Drupal. (Clean URLs, aliases, trailing slashes, etc.) Since the Boost cache operates before Drupal is ever consulted, it must treat these differing URLs as calls to entirely different pages – even if Drupal considers them equivalent. The result is wasted disk space, increased cache misses, inconsistent expiration times, and various other unpleasant side effects.

This module ensures that requests made to one of these alternates is redirected to a standardized preferred format prior to the request being processed by Drupal. It is not mandatory but it is highly recommended.

HTTP Parallel Request Library (optional)

Boost includes an optional crawler module that will scour your website and pre-cache webpages. This prevents the initial performance hit incurred by whomever is unlucky enough to be the 1st to request an uncached page. This module is a dependency of that crawler and is also optional as the Boost cache itself does not need it.

Configure the Modules

Configuration of the front-end cache. For optional modules, please see their respective documentation. If a setting is not mentioned then you can assume the default value is also what we suggest.

Once you have installed and activated the modules, sections for them on the ‘Configuration’ page will appear. Here are the suggested settings for Web Hosting broken down by the tab they appear on:

Clean URLs

Boost requires that Drupal’s ‘Clean URLs’ feature be enabled.  This should be enabled by default on recent versions of Drupal; however, Boost fails is strange and mysterious ways without this so you really should double-check just in case.

HTTP Parallel Request Library (HTTPRL)

Set the IP Address field to -1.

Do not enable ‘Use httprl to handle drupal_http_request’ regardless of your version of Drupal – something has recently changed in Drupal that breaks this module’s ability to properly override it.

Global Redirect

Enable ‘Menu Access Checking’ and ‘Set Content Location Header’ in addition to the options already enabled.

Cache Expiration -> Module Status

The module is disabled by default.  Switch to ‘External expiration’ for the reasons explained below the setting.

Cache Expiration -> Node Expiration

These define what activities should result in a cache expiration. At least ‘Node update’ and ‘Node delete’ should be checked. You will also want to check the “Front page” box so changes to the node set as the front page will properly expire.

Cache Expiration -> Comment Expiration

Check all actions as any of them could change the host page and require it be re-rendered.

Cache Expiration -> User Expiration

Each user has a profile page and these are cached as well. This is like the node expiration – check all of them except possibly ‘User insert’.

Cache Expiration -> File Expiration

Check all actions.  Also check the ‘File url’ option.

Cache Expiration -> Menu Links Expiration

Check all action options.

When a page is configured to appear in a top-level menu like a sidebar or quicklinks section, all pages on the site that display that top-level menu must be expired. If you know exactly how deep these menu changes will affect the overall site then you can choose these depths in the 2nd section. If you don’t know, though, then the safest option is to just choose the deepest option the dropdowns offer. (currently 9)

Boost -> Boost Settings

Ensure that Boost is configured to cache all pages except those listed in the text field. Add the following page to that text field: /httprl_async_function_callback

Consider carefully the gzip compression setting. Compression helps speed transferring the website data; however, if you expect a lot of mobile device traffic, it can actually slow things down. Mobile device are usually designed to prolong battery life as much as possible and, as such, either don’t include very powerful CPUs or throttle them way back. The time is takes to decompress a gzip’ed webpage on a mobile device may entirely offset any speed gains in transferring it.

As the Boost module only suggests using Cache Expiration and doesn’t mandate it, it includes a ‘Maximum Cache Lifetime’ value to purge cache files after a certain period of time. Otherwise changes to a cached page would never show as the older version in cache would never be replaced. As we are using Cache Expiration, though, this option can be increased significantly. The default is an hour but we generally raise this to a week or more.

You may notice that you can set this quite high but not actually disable it.  This feature of the Boost cache acts as a sort of ‘safety net’ just in case a page is changed and, for whatever reason, Cache Expiration fails to work properly.

Boost -> Crawler

If you have installed the necessary dependencies for the Boost Crawler feature, you can enable it here. It is disabled by default.

Boost -> .htaccess

Provides the Apache configuration required to try the cache first and only fall back to Drupal when it misses. You must change the last option to use +SymLinksIfOwnerMatch instead of +FollowSymLinks as the latter has been globally disabled for security reasons.  You will also need to uncheck “Bypass the boost cache for ssl requests” if your site is configured to use SSL for everything.

Activate the Boost Cache

Now that everything is configured, it should be safe to actually enable the cache. Go to Configuration -> Boost -> .htaccess and switch from ‘.htaccess Settings’ (which we just configured) to ‘.htaccess Generation’. This will produce the exact settings needed by mod_rewrite to serve cached pages if they exist and defer to Drupal when they do not.

Copy this configuration data to your clipboard and then open the .htaccess file in the Drupal root directory with a text editor. Below the setting’s text box are instructions stating exactly where to put them.  Save the altered .htaccess file and test your website. Cached pages should begin to appear in your Drupal root directory under cache/normal/mywebsite.osu.edu/.

Need More Information?

Is OSU Web Hosting right for you? Check your eligibility.

More questions? Check the support section or contact us.

Ready to get started? Request hosting now!