Part 2: Site builder
Drupal is a powerful content management framework but it's even better when you take into account the 20000+ modules and themes provided by the community. Whatever you are building, you will most likely find a module to help you. When you embrace the wonderful world of free and open source code, keep in mind that end users and search engines actually prefer fast websites. In this article we will discuss some common pitfalls that should be avoid, and will give some suggestions for site builder to create light and fast websites. This post is part of a multipart series. The first instalment was related to performance for back-end developer.
Disable unused modules
Drupal has thousands of contributed modules but remember that each time you enable one you will increase your PHP foot print and will slow down potentially your application. This is particularly true for authenticated users. Over time it's easy to download and enable modules during your development but before you go live clean up your build. The missing module is a very handy tool to list modules that are activated in your database but missing from your file system. "Orphaned" modules can have a negative impact on your page load.
Disable development modules
It's recommended to turn off the user interface of common modules like Views UI, Rules UI or Field UI for efficiency. It is also best practice to do so as it will make you think twice before amending a view or a rule on a production website. You should really use features and a source control system to improve your deployment process.
The Drupal community has built amazing development tools (Devel, Xhprof, Site Audit, Security Review, Search Krumo, Stage File Proxy, Hacked, Coder) but they should never be enabled on a live environment. They should be enabled locally after each database refresh. We use a script to prepare our local database whenever it has been synchronised with our live data.
Disable bad performing modules
Drupal has some brilliant core and contributed modules but also not so great modules that should be switched off to avoid a sluggish site experience.
For example, disable the statistics core module1, which will hit your database on every single request. Google Analytics will definitely do a better job. It will give you more information about your traffic without impacting your server performance.
Another good practice is to disable the update manager module on production as it will eat your server resources when it's fetching data from drupal.org. This is particularly painful for low traffic sites set up to use the internal cron. Keep the update manager active on your staging, test or dev server if you want to stay aware of any incoming security updates.
Disable the overlay module. For many drupalistas it was a Drupal 7 mistake. Luckily the overlay has been ditched in Drupal 8. You can also turn off the toolbar module and use the contrib administration menu module instead.
Drupal’s default database logging is very practical for developers, but because it writes logs to the database, it can be a potential resource hog on a high traffic website. So instead enable Syslog, which is more adapted for medium and large sites and offer a better "enterprise" integration.
Finally, avoid using the PHP Filter module, which has also been removed in Drupal 8. Indeed, on top of having performance issues as the PHP code cannot be cached properly, it's a potential security hazard if misused.
Fewer Modules Is Better
Adding an extra module often means more code to execute, more memory to consume and more database queries to execute. Every single module on your website should be evaluated and only enable if they add a real plus value. More important, the more module you have the more complex your application becomes, making it harder to develop and maintain.
Drupal out of the box config
Caching is often the quickest way to solve your website performance issues. Drupal provides built-in cache mechanisms to store either the full page for anonymous user or block of content. Contributed modules like panels or views will extend Drupal default caching capabilities. Make sure to define your caching strategy and configure your website accordingly.
Set up a cron job
Avoid using Drupal internal cron as it will run alongside a http request. It's better to set up a cron job or use a more advanced job scheduler, such as Jenkins or Travis CI. Another best practice is to use tools like Elysia Cron or Ultimate Cron which allow a fine grain control over the cron jobs.
Configure the file directory for file fields
Files should automatically be uploaded to directories based on a token to limit the number of files by directory. It is a well known fact that uploading thousands of files into a single directory will have performance issues on your Drupal system.
Take care of your 404 requests
Drupal has by default a very expensive 404 errors. Indeed 404 for a .css or .jpg file causes a full Drupal bootstrap. So you should enable fast 404 through the core or with the Fast 404 module. The contrib module will give you more control and more functionalities.
Enable performance-enhancing modules
Entity cache can really speed up your application. Enable it and it will start caching all the entities2 (taxonomy, users, Entity Email) which are not cached by default. The biggest improvements will come on sites with large number of fields or references to other entities. Entity cache will even work better if you are using memache. Entity cache is now baked-in into Drupal 8. So there are really no reasons not to use it now.
- Views Litepager
- Elysia Cron
- File Cache
- Advanced CSS/JS Aggregation
- Panels Hash Cache
- Fast 404
- Authenticated User Page Caching (Authcache)
- Views cache bully
- Don’t use Drupal to compress pages as Apache will do a better job.