19 simple methods to improve the page speed performance of a Drupal site

Site speed is one of the most critical factors when running a site. If a site takes too long to load, visitors will hit the back button and go elsewhere. Google is well aware of this, so slower sites will not rank as well as fast sites (all other things being equal).

Drupal performance optimisation can be a complicated specialisation in its own right. Consultants and Drupal agencies can spend days or even weeks investigating performance issues and fixing them. But there are many quick fixes and simple methods that you can implement right away. You don’t have to implement absolutely everything on this list - you can implement some and monitor the difference it makes to the site speed.

There are two great tools for monitoring the changes you make - YSlow and GTmetrix. Make a record of the key metrics (page load time, page size, number of HTTP requests and the overall speed grade) before you make each change and then afterwards, noting the difference to ensure you are moving in the right direction. You can also try tools like JMeter and Apache Bench.

Core caching and aggregation

Turn on core page caching

It might sound obvious to enable the default caching, but a lot of people miss this. This caches the entire rendered page in the cache table. So when each page is served, it is served from just the single cache table without all of the numerous queries being run. This is a significant performance boost. This only works for anonymous (non-logged in) users because pages for logged in users is dynamic and can be different for each user, so caching the entire page is a lot more difficult.

You can enable page caching in the core performance settings page, which can be found under Configuration -> Performance (admin/config/development/performance).

Turn on core block caching

While page caching caches entire pages, block caching caches individual blocks. This is useful for two reasons: 1) blocks will be cached if you have page caching turned off and 2) even if you have page caching on, it will not work for authenticated (logged in) users, so block caching will represent a performance boost for them.

You can enable page caching in the core performance settings page, which can be found under Configuration -> Performance (admin/config/development/performance).

Enable built in CSS and JS aggregation

In the same admin form as the default caching, you can enable CSS and JS aggregation. If aggregation is left off, there will be many CSS and Javascript files. Each one represents a separate HTTP request and having that many requests can slow page loads down. Enabling aggregation converts all of the many CSS and Javascript files into just a few files, reducing the HTTP requests by a lot.

You can enable page caching in the core performance settings page, which can be found under Configuration -> Performance (admin/config/development/performance).

Views caching

Enable Views caching

Views is the most popular Drupal contributed module (and will be in core in Drupal 8) and is used on most sites.

Without caching, every time a user requests a page with a View on it, a database query is done. These database queries can add a lot of time to page loads. If you enable Views cache, the result is stored in the Views cache table and that is used for the duration of the cache, rather than the query being run every time.

Views caching is great for logged in users (authenticated) because the output of the View is still cached even if the rest of the page is not.

Enable Views Content Cache

The downside of Views caching is that results are not real time. If you set the cache time for 10 min, the results will be the same for the next 10 min. If the content returned from a View changes, a new cached version of that View is not triggered. You simply have to wait for the full 10 minutes.

Views Content Cache fixes this problem. It will monitor the content that the View is returning and clear the cache if that content changes.

To use it, after enabling the module, go to basic settings for the View. Under Page: Caching options, select the events that you’d like to use to update the View.

Enable Views block cache

Drupal has built-in block caching. Blocks that are generated from Views are excluded by default, but can be included with Views Block Caching.

For a given View, head to the advanced settings. At the bottom, you should see Block caching. You will choose to either cache the views block once or more granularly such as per page, per role, per user.

Enable Views Litepager

If you have the default pager or Mini Pager enabled on views, COUNT queries need to be executed for first, page number and last. This adds extra processing time and is especially expensive when using MySQL’s InnoDB engine (InnoDB is recommended for high traffic sites).

Views Litepager removes the need for these COUNT queries by displaying only the previous and next links. You lose some functionality, but you gain in page speeds.

Flat HTML files

Enable Boost

Boost turns all Drupal pages into flat HTML files and stores them in a cache folder. When a user visit the page, the server returns the cached file from disk and there is no PHP and MySQL processing. This makes a huge difference to page speeds. Boost is especially good for smaller sites on shared hosting where Varnish (Varnish caches pages to memory instead of the file system and is even faster) is not an option. Boost works for anonymous users, but users that are logged in (authenticated) will still get normal Drupal pages.

Faster 404 errors

Enable Fast 404

Page speeds will be significantly slower if your site has broken images or CSS file paths. Drupal will still attempt to load these paths for every page in which they are included but they will return a 404 error (page not found). Drupal will do a full bootstrap when serving a 404, so this consumes a lot of resources.

The Fast 404 module changes the way 404 errors are handled, delivering fast 404 error messages.

Disable bad core modules

Uninstall the Statistics module

The Statistics module collects similar data to Google Analytics such as how many times content is viewed. This adds multiple database writes per page load.

It is recommended that you use Google Analytics (or a similar analytics system) instead to save these database writes. You can use the Google Analytics Reports module to such the Google Analytics data in so you can still view it within the Drupal interface.

Disable PHP Filter

The PHP Filter module allows you to use a PHP text format. This means that you can store PHP in the database and run it on page load. This is both a security problem and a performance problem and should never be done. All code should be in modules, not in the database.

To remove it, simply disable the PHP Filter module. Don’t delete the module itself though, because it is a core module.

Disable Update Manager

The Update Manager polls Drupal.org to check for modules that are out of date and ready for an update to be applied. While it is essential that you know which modules need updating, it does add load to the server to check.

If you have a staging or dev site, you could run update manager there instead of your live site.

Reducing the number of modules

Limit the number of modules in use

Every module you have installed and enabled will add to the page execution time. So don’t just install every module you think you might need - really think about what modules you actually need.

In many cases, it is better to create a custom module to do exactly what you need than it is to install a large module and only use 10% of its functionality. This is especially true if you find you're having to use multiple modules together to get your desired functionality.

Disable and uninstall unused modules

You (or your developers) might remove modules without disabling them first. This means that they are still enabled in the database even though they are missing from the file system. This can have a huge negative impact on performance.

You can find these modules using Clean Missing Modules or Missing Module and then disable them.

Images

Resize images

Images with large file sizes take a long time to load. Wherever possible, you should resize images so they are not larger than they need to be.

For image fields, you can use image styles (admin/config/media/image-styles) to resize images to the desired size.

The Image Resize Filter makes this a lot easier for inline images that are inserted via a WYSIWYG editor like tinyMCE or CKeditor. If you set the height and width of an image, Image Resize Filter will automatically resize it to match.

Install ImageAPI Optimise

Even when using image styles (ImageCache in Drupal 6) and Image Resize Filter to scale images down to the correct size, images still contain data that slow down load times. The ImageAPI Optimise module removes this data without affecting the quality of the image.

The ImageAPI Optimise module does require certain utilities to be installed on your server. If you don’t have access to your server, you can use Yahoo’s Smush.it, which you can select in the settings.

Advanced caching

Install Entity Cache

Content, users, taxonomy terms are all Entities in Drupal 7. Most entities have fields and when each entity is loaded, queries are performed to load the fields to. The end result is a lot of queries!

Entity Cache helps address this by caching the fully loaded entities into a cache table. Each loaded entity is a row in the cache table.

Using this module is as simple as it comes. Just enable it. No configuration required.

A word of caution. I have seen significant performance improvements on complex sites with large sets of fields, Field Collections etc. Your mileage might not be as great if you have a simple site. Also, I have found that there is an incompatibility between Ubercart Price Per Role and Entity Cache.

Install Advanced CSS/JS Aggregation

While built in core CSS and Javascript aggregation does a decent enough job at reducing the number of requests that the browser needs to do by aggregating it into one file, the Advanced CSS/JS Aggregation module does this in a much more intelligent way.

Limit the number of times cron is run

Drupal 7 has a feature that allows cron to be run automatically without having to set it up on the server. The downside is that it is run when a real user hits a page. By default, it will run every 3 hours. This means that the first user to hit a page after that 3 hours will trigger cron, making the page very slow for them.

The best solution in terms of performance is to disable this and set cron on the server so that it is run in the background.

Wrapping up

This represents a run down of some of the easier solutions to boost the performance of Drupal sites. As mentioned at the top of the post, monitor the changes to be sure there is actually an improvement (there is no point in using something if it doesn’t actually help).

Let me know in the comments below if you can think of any more quick wins to improve performance of a Drupal site.

Need help?

If you would like an experienced Drupal developer to improve the performance of your site, get in touch.

Comments

Best overview I ever seen! Thanks Blair! I have used the Advanced CSS/JS Aggregation module when Boost for some reason didn't work well. Do you think it's good to combine them?

Blair Wadman's picture

Thanks Henrik! I haven't used Advanced CSS/JS and Boost on the same site (have used them separately), but don't see any reason why you can't combine them. If you do try it, let me know how you get on.

We use boost and advagg on phonedog.com without any issues. In fact, we go one better and tell nginx to find boost files and CSS/JS aggregates without touching the PHP layer if it can, via the try_files $uri directive. I wouldn't hesitate to use this combo elsewhere.

Also dblog is a module that should be disabled for better performance. Especially for sites with a lot of activity.

Thanks for the article.

Blair Wadman's picture

Thanks Theodoros for mentioning dblog, I'll add it to the list.

Great post! Thanks.
I was wondering about large site with lots of loged on user at a time, uploading content and so. So in this case, does the activity of the views cache content will cause performances issue as for multiplied cache clearing?

Blair Wadman's picture

Thanks Amir!

If I am understanding the question correctly - Views Content Cache will result in more cache clears and the act of clearing cache can in itself cause a performance issue on a really busy site. However, you can set a minimum lifetime, which will prevent the caches from clearing too often.

Great list, thanks! Good idea to disable the Update manager on live and have it enabled on dev. Will also try Entity Cache.

Most of the time, I just use Boost that is because, to this point, the sites that I have created normally don't have too many people logging in to the site, so I haven't needed this sort of optimisation until this point. It's good to know that there are a lot of tweaks that we can do to reduce the load on the database.

Blair Wadman's picture

Boost is great - for these kinds of sites it is the biggest performance gain you'll get.

Hi Blair (and others who read this). Do you know if there is benchmarking software to test page speed with out there? I saw you mentioned GTMetrix and I found a few other decent similar websites like that myself (http://webpagetest.org and http://giftofspeed.com for instance) but I am looking for software which can do these tasks. Especially software which can test multiple pages at once. Anyone knows if that's out there? Fantastic article by the way.

They are very useful but we should note some imcompatible, such as Turn on core page caching, I remember Boost is imcompatible, right?

By the way, when our server support Varnish, does it need to use Boost module, please?

The speed of your website also depends on hosting and stack you are using. It would be even better if you are using PHP 7 on your website. I have hosted my website on AWS with Cloudways platform (https://www.cloudways.com/en/php-cloud-hosting.php ). I am using Apache, Varnish, Memcached and Nginx stack with Cloudflare CDN. Couple all this up and it becomes a perfect recipe for getting a fast website. I ran benchmarks on my website and got 4ms of response time with 250 concurrent users, which is faster than any other website I have build.

Hello, Blair!

My note is about Google analytics plugins.. Java-scripts implemented in Google analytics-related plugins really slow down the perfomance of the blogs and could deprive you of 5-10% of Google Speed Insight Score which is influential for the SERP results now in 2016..

Thanks Blair for the tips.

I was running Drupal and it was a bit slow (3.1s loading time). I did almost all the steps provided in this tutorial and I got my loading time down to 2.7, but it's still a lot.
What I later found out is that the hosting really does make a difference. On my previous host, TTFB was 0.7s, which I thought was normal after all.
Finally, I switched hosting providers and I improved my loading time at 1.6s, which is great for a Drupal site. TTFB is now improved. I'm running on a SSD server from https://www.rosehosting.com/ which also improved the speed. I was on HDD previously. I have no downtime now. Switching hosts made a big difference.

Anyway. Long story short: get better (SSD) hosting and do all the tips in this article.

Blair Wadman's picture

Good to hear that you got it down so much. Totally agree, a good host with SSD makes a huge difference.

Great Post with detailed information.

I am facing this problem for my Ease Bedding Niche Site and every time I see that the number of executions are increased.

So I searched in the google and found your article, understand a bit.

Thanks.

Like many others have mentioned, the web hosting provider makes a BIG difference. I had a client with a Drupal site hosted on an overstuffed shared hosting account. By switching to SSD VPS hosting I got the loading time cut in half.

"SSD hosting" is not enough by itself though. There are slow SSD shared hosting providers. Even some SSD VPS providers are slow if they are OpenVZ and they are overselling. So you need to choose the right SSD VPS provider.

Add new comment