Drupal Performance: No Kidding No Coding

Drupal is a content management system (CMS) designed for low coding creation of a full-featured website. This CMS features an advantageous mix of configuration options and framework flexibility. Therefore, as a very progressive framework, Drupal strikes a good balance between flexibility and performance quality. In addition, setting a correct configuration can make Drupal performing unbelievably fast.

Caching for Speed

To put it simple, the cache saves some particular elements of your webpage in their rendered form, which allows your browser to avoid launching all scripts and styles again and again, thereby increasing the webpage loading speed.

There are three types of cache in Drupal:

  • Application-level Caching A type of cache which cannot be turned on or off, or optimized. When you are suggested to “clear the cache” to see any changes on your website, there is application-level caching at work behind the scenes;
  • Page-level Caching This caching type is one of the most effective, because when the page is cached, there is no need in Drupal bootstrapping anymore. Though, this caching type works only for anonymous users and its utility depends on your site traffic;
  • Component-level Caching A type of cache, that affects visual elements of websites, including navigation bars, headers, main content areas, and other elements, including views, panels, and blocks. Caching components can really improve your website performance, for example, if you have the same block displayed on several pages.

Performance Considerations

From the previous paragraph we have learnt that a good website is a high performance website with low latency. But how to determine whether the website performance is high or not and the current speed level is good enough for end-users?

To answer these questions, first of all, you should clearly understand the goal of the website that you create. For example, if your website is customer focused then every millisecond matters, whereas, intranet website performance does not weigh as much. The second step is to measure what parts of the website require speedup and implement proper solutions depending on your conclusions.

The good practice leading to the best results is to document the project, record changes, and analyze results. It will help you to see the dynamics of your website performance change. For example, you can easily identify the moment when things got worse or better and might happened before that moment to cause such change. Before adding the first module to your website, record your site baseline performance. Then, do the same after you install another one. Repeat this simple action for any new implementation to the website.

As you see, two general rules should be remembered at all times: before implementing a module to your website it is better to test it out, and the more modules you add to your site, the more performance demand you create.

Here are some of the most common sources of performance problems:

  • Page building modules, such as Views and Panels;
  • Any external or third-party service;
  • Overall complexity;
  • Misconfigured components.

Troubleshooting Considerations

If the problem exists, the first thing you should do is to collect evidence, analyze, and discover the cause. The recommendations in the previous section can help to determine the problem cause and find an appropriate solution.

Here are some examples of troubleshooting prompts based on 5W2H method (What, Who, When, Where, Why, How, How Many):

  • What has happened? (Describe the problem);
  • Who is affected? Describe who from participated parties, whether people or applications / modules / services, were affected by the problem;
  • When did the problem occur? Determine the time of the incident and frequency. Were there any events that might correspond to the moment of problem occurrence or right before that moment?
  • Where did the problem occur? Determine where the problem occurred in the workflow and the piece of application / service. The more granular view is available the more chance is to determine the problem cause;
  • Why does it work this way? Describe why the workflow / procedure / algorithm was designed the way it works now;
  • How the workflow / procedure / algorithm works and what was the mode / situation when the problem occurred?
  • How many users / pages / services / apps were affected? Describe the magnitude of effect.

Finding answers to the above prompts will lead to discovery of potential causes and development of corrective actions.

Vital Performance Tools

There are some helpful tools for those who know something about coding and development. They can help to troubleshoot by showing you the number of queries run on a page, the execution time, how much memory was used, and other useful metrics. Even if you don’t understand some of metrics, you can still use them for comparative analysis.

Here are some of vital modules that can aid in performance improvement:

  • Boost – provides caching of static pages for anonymous users;
  • Entity Cache – caches entity objects and is especially useful for websites with large amounts of content;
  • Block Cache Alter – you can use this module to determine cache settings for each block individually. It can be very useful if you want to cache some particular blocks of your website;
  • Views Litepager – this tool is for large websites with certain database configurations and speeds up creation of pagers for Views, though its functionality is limited as the performance tradeoff;
  • Views Content Cache and Cache Actions – the advantage of these modules is clearing the cache only when the content changes, but they require the Rules module to be installed.

Image optimization for your website can be performed by using SpriteMe tool that uses so called “sprites” – images aggregated into one file and used in several places. This approach reduces the number of server requests.

There are some webpage testing tools as well, such as: Webpagetest.org, Google PageSpeed, Firebug, Web Inspector and others. All of them can analyze requests and provide information such as the number of requests coming back etc. They use header information to determine whether the page is cached and measure, for instance, how long each item takes to return.

Points to Remember

To achieve high performance of your web site we suggest remembering the following points:

  • there are three types of caches in Drupal: application-level cache, page-level cache and component-level cache, each of them having their own features;
  • cleaning the cache is a very important thing and there is a lot of modules that help in cleaning caches;
  • before starting to implement any modules and features it is better to try them out on a test site;
  • document and monitor all the changes you implement on your website and do some analysis.

As you see now improving the performance of a Drupal site doesn’t require knowledge of inner workings of servers or applications, specific software coding, or the command line use, though the knowledge of all these things can be very beneficial if you decide to understand hidden performance levers and operate your web site efficiently.

Now you can use our tips to build successfully your perfectly running website!