At Focalworks I have been working on Drupal since 2011. We have created websites, portals, web applications and even developed an Intranet using Drupal. There is no doubt that when you are dealing with a lot of content and need to do rapid development, Drupal has all the right tools (or we can say modules) to help you out. But, one aspect that sometimes can become a huge concern is the infrastructure on which you are running your Drupal instance. In this blog, I am going to talk about some very important tweaks that will help you get the best performance out of a Drupal website.
Drupal is a great CMS for rapid website development. The theming layer is just a perfect separation of concerns where front-end developers can work on a standalone HTML markup. Write the HTML markup, CSS, and JS based on the design requirement. Then just stitch that markup as a theme inside a module and get the necessary data from the database.
Recently, we have been fascinated by Drupal’s paragraph module and have started with that workflow also. However, that’s something that I have presented in a separate blog since how to properly use paragraphs and follow the BEM format is a topic in itself. If you want to learn more about this, you can refer to this link and read about the module and its concept.
Here, we will be talking about Drupal-based sites that we have built and what we do to get the best performance out of Drupal 8.
Our experience with Drupal dates back to 2009 – the days of Drupal 6. And we shifted to Drupal 7 in 2011 when it was released to take advantage of the improvements it offered over Drupal 6.
However, one thing that we felt was a concern was performance. Yes, with Drupal 7 you need to be extra careful about the performance, especially when your site is being accessed by authenticated users more than anonymous users. In some of the portals/intranet kind of applications that we built, we faced quite a few challenges related to performance on Drupal 7. Just stating that Drupal 7 is a performance hog doesn’t really solve any problem. We need to understand why it is slow so that we can find ways to improve performance. One of the best things about Drupal is its architecture to extend or modify the core functionalities without the need to modify any of its core files. The CMS code is huge and when building a site, there are times when we would like to modify how certain things work out of the box. This is where hooks, theme registries and module discovery features come into the picture. However, these do take a toll on the overall performance.
Also, Drupal being a very generic CMS, has an architecture that is very easy to extend. However, the robust nature of the CMS comes at the cost of a lot of performance. For example, if we go a little more technical into this topic; every content in Drupal is a node that is of some content type like Blog, Gallery, Product, etc. and we can add unlimited fields to a content type which allows us to add that information inside our content. But as we create more and more fields in the CMS, we are actually increasing the number of tables. There are tables for the field information, the version information and even some metadata regarding the field to render.
Now, when Drupal is building a node, it will query a lot of tables. This is where things can go wrong if performance is not given priority. Drupal solves this problem with its Cache API which has tremendous improvement from Drupal 7 to Drupal 8. It provides a way to cache blocks and pages by default along with the minification and aggregation of JS and CSS files. But, many of these are only useful when your users are anonymous. When your site has logged-in users, a lot of caching will not work, say, for example, page cache, because maybe, somewhere on the page, you are showing the current logged-in user’s username.
This is why we have taken the help of some caching software or utilities that ensure that Drupal is able to get more data from high-speed cache stores. Redis, for example, is a great choice. We not only use this for Drupal-based sites but also for other applications built with Laravel and other PHP frameworks. With Drupal’s Redis cache module, we can install Redis, configure the module, make some changes to the setting file so that Drupal knows how to connect to the Redis server and we are done. Drupal will automatically cache a lot of most frequent queries result in the cache. And with that, Drupal will get that information from RAM instead of hitting the database.
One great module which we have seen can do wonder is the Dynamic page cache module. The traditional page cache module is used to cache the rendered HTML which works very well for anonymous users. However, the Dynamic page cache module using the Drupal cache context is able to understand the user’s context and cache responses for individual users. This article on Drupal 8 Dynamic Page Cache by Wim Leers is also a great resource in understanding the individual kind of cache and how it can have a huge impact on the performance which Wim Leers shows using the Apache benchmark tool.
Another great option is Varnish, which can boost your site’s performance by a huge multiplier. For anonymous users, you can practically serve your entire site through Varnish and never even hit the database. So, your site is served from a server’s RAM memory. But, Varnish is also used a lot for logged in users as well. Drupal’s cache api heavily utilises block-level cache for individual users, blocks and also handles dynamic page cache. Having said that, I would like to mention that setting up Varnish and getting the page cache to purge properly will require a lot of reading and tweaking the Varnish configuration files also known as vcl files.
These are some of the tweaks that we do in Drupal configuration using services like Varnish and Redis in almost every site that we build, as performance is always a great concern for every site. And there are few more things as well that we want to explore to take the performance to the next level by using features like Big Pipe, caching responses for authenticated users in a CDN, etc. Big Pipe, in particular, has great potential because in public-facing websites, the time it takes to render the first element is a big factor and Big Pipe can increase that speed tremendously. We look forward to sharing our experience with you once we are able to figure that out on hit production with a site.
