A website can be further accelerated by using a content delivery network (CDN). In this case, a third-party provider is used to deliver resources and provides specialized servers for this purpose. If a CDN is used, the latency time for accessing resources is reduced: an independent network of caching servers distributed over geographically sensible locations ensures that content only has to cover the shortest possible routes for delivery. This reduces the energy consumption of the network infrastructure and speeds up the delivery of resources. Drupal offers connections to various CDNs through the use of modules, which can be used for resources within your Drupal installation.

Aggregate and minimize JS and CSS

Bandwidth can be saved by delivering minified JavaScript and CSS. Drupal is modular, which means that every single module delivers CSS and JS. This leads to the fact that often several dozen files must be transferred to be able to display a website. Drupal offers a useful optimization by aggregating CSS and JS files. Because instead of many small files, only one large one needs to be delivered, which can massively reduce the number of requests to the server.

Reduction of the productive system

Drupal 8 has the ability to use different configurations for different environments of a website. For example, a staging or test environment may have a different underlying configuration than the production environment. The configuration contains virtually all the mutable data necessary for Drupal to function.

We can increase Drupal’s performance (albeit only a little in newer versions) by disabling modules in the production system that don’t serve any purpose there anyway. For example, Drupal provides a powerful tool through Views to configure dynamic lists of content and display them in the form of pages or content blocks in the website. Additionally, there is the ViewsUI module, the user interface for views. This can be used to create views, which is handy in the development process. However, the module is not necessary for displaying a view. On professional sites with connected deployment processes it has no use anyway, because changes are only made in local development environments. So you can deactivate certain modules in the production environment, which are not needed there. Because the mere fact that a module is activated worsens the performance of the page. For each individual module, however, it should be clearly weighed up whether it is actually useless in the productive system.

Optimized source code

In all our own developments, we should make sure that we optimize our code. For many developers this may sound banal, but it is no less important! If we optimize our source code and, for example, save unnecessary function calls and store intermediate results instead of performing calculations over and over again, we save valuable computing time during calculations and operations. The resulting energy savings for a heavily used website or web service quickly add up to an impressive amount.

Want an example? Here’s one of my favorite beginner mistakes from the Drupal world: