Tips on How to Make Your Drupal Site Lightning Fast

Having a fast website is critical to retaining visitors and keeping them engaged. Slow-loading pages are a drag and, one of the top reasons users could leave your site—even if it has exactly what they need. While the release of Drupal 10 is right around the corner and it comes with many performance improvements for Drupal sites, there are still ways you can make yours faster for your visitors. 

You can use a variety of methods to keep your Drupal website cache primed and always ready to serve your audiences. Whether you use an external CDN like Cloudflare, Fastly, or CloudFront—or even if you don’t—the following tips will make your website snappier and your users happier.

At Velir we go the distance on Drupal projects to ensure you get the highest possible performance from the front-end and back-end of your site. We also ensure that you get the most out of the server hardware and that both your users and content editors are happy. All the tips in this article come from real projects we’ve worked on. They’re techniques you can employ on your Drupal sites to make them lightning fast.

Use a Memory-Based Cache Store

The number one thing you can do in Drupal to cache data and improve performance is to use a memory-based cache store instead of the default method of using the database as a cache store. Drupal has deep integrations with both Memcache and Redis so enabling it to use either of them is very simple. The immediate impact on your site’s performance is drastic. This is because the database can be a major bottleneck. 

If you’re an Acquia, Pantheon, or Platform.sh customer, you have Memcache or Redis server software installed on your instance already. All you need to do is enable either one of these modules and configure them. If you only make one change to your website based on this post, make sure it’s this change.

Set a Long Cache Lifetime

The next thing you can do to improve your Drupal site’s performance is to set a long cache lifetime of content.

For most sites, setting the maximum age to 1 month is good enough. When using the Purge module that we talk about next, you can set this even threshold higher. With the Purge module, any given content can be cached for whatever length of time you configure.

Setting it to something low like 3 hours means that every 3 hours, the sitewide cache is invalidated and the application must serve fresh requests again. If your content isn’t frequently changing, this is too low. It’s also problematic to set this low if you have a high volume of content. Essentially, if this value is too low you aren’t getting the performance benefits of your cache system.

Setting a higher cache lifetime is perfectly fine even on higher-traffic websites. We can ensure that the content being delivered is always the latest version by using the Purge module.

Implement the Purge Module

The Purge module is an invaluable tool to help expire URLs through the cache layers, so users never see outdated content. When content is saved Drupal invalidates all relevant cache tags and administrators can see changes immediately. Anonymous users don’t, however. They won’t see any updated changes until the cache max age has elapsed (from the previous section). That is because we need to signal to reverse proxy layers on the server to expire or purge the relevant URLs from their cache so the next time a user requests this page, they get a fresh response with the updated content (which is then cached again until the next save).

Like the Memcache or Redis modules, the Purge module is very easy to install and configure. There are a variety of add-on modules for the Purge module that support all the popular cache proxies and external CDN systems like Cloudflare, Fastly, Akamai, and of course, Acquia Cloud.

The Purge module has Drush support (a command line tool), so it is easy to set up a scheduled task on your web server to automatically process URLs to be “purged” every five minutes. This is what allows editors to keep updating content and have your site visitors see it right away—no more telling site admins to “go clear the cache,” which is like going after a fly with a sledgehammer. Now, every time you update a page, its URL goes into the queue to be processed, and your scheduled task will process the queue for you to keep things moving.

Use the Warmer Module

The Warmer module allows you to define a source or list of URLs to keep warm—or ensure they are always cached and ready to serve. Out of the box, the module supports entity warming (nodes, taxonomy, media, users, etc.), using a sitemap as a URL source (Simple XML Sitemap module or the XML Sitemap module), or by manually specifying a list of URLs to warm. The module will periodically view these URLs behind the scenes using an HTTP client to keep them warm—i.e., simulating a human user visiting the page. 

Without this module, the first visitor to view a page that was recently updated must wait for the application to fulfill the request and render the entire page since it has no cache entry—also known as “cold cache.” With this module, however, you can ensure or greatly reduce the chance of this happening for your site’s visitors.

Like the Purge module, Warmer comes with Drush support so you can set up scheduled tasks to periodically process the queues of URLs to keep warm. In most cases, pointing it at your sitemap is good enough since your sitemap typically represents the most important pages on your site to visitors. On top of that, the Warmer module has an easy plugin API for defining your custom URL sources programmatically.

Bringing It All Together

There is one last thing you can do to bring these tips full circle. When deploying code to your web server—before you can see any of the changes in that code—you typically need to clear the cache. When you do that, your site content is now 100% uncached, or “cold.”

Fortunately, managed hosting platforms like Acquia, Platform.sh, or Pantheon provide an API to interact with during deployment events on the server. You can provide a simple script that will run on every deployment automatically. Since modules like Purge and Warmer come with built-in Drush commands you can take advantage of those features.

Here’s an example. Imagine you have an existing script that is run on deployment. Its job is to run any pending database updates for Drupal, import configuration, and clear the cache (so deployed changes are reflected). After you bring the site back online (out of maintenance mode), you can tell it to purge all URLs and then warm the site cache.

This is an example of a deployment hook in an Acquia environment:

#!/bin/sh 

site="$1" 
target_env="$2" 

docroot="/var/www/html/$site.$target_env/docroot" 

DRUSH_CMD="drush10 --root=$docroot @$site.$target_env" 

$DRUSH_CMD state:set system.maintenance_mode TRUE 
$DRUSH_CMD cache:rebuild 
$DRUSH_CMD updatedb -y 
$DRUSH_CMD config:import -y 
$DRUSH_CMD updatedb -y 
$DRUSH_CMD cache:rebuild 
$DRUSH_CMD state:set system.maintenance_mode FALSE 
$DRUSH_CMD p:queue-add everything -y 
$DRUSH_CMD p:queue-work --finish 
$DRUSH_CMD queue:delete warmer 
$DRUSH_CMD warmer:enqueue sitemap 
$DRUSH_CMD queue:run warmer 

After adding that, every deployment will now expire all content URLs and then immediately warm the cache—in this case, using the Sitemap plugin of the Warmer module. When you factor in the scheduled tasks we mentioned earlier for Purge and Warmer, this all but ensures your site will have a warm cache ready for your visitors. 

Of course, depending on the size of your site (dozens of URLs, or thousands) your expiration and warming strategy will vary by the processing load you can handle at any one time. In our experience, the above method was fine for sites with up to 1,000 URLs in their sitemap or otherwise important pages.

We Can Make Your Site Fly

In need of a site audit, performance assessment, or application monitoring for your Drupal website? Our team of experts can assist you! Contact us today to learn more about our Drupal services and to find out more ways we can help you improve your website’s performance.