No one likes to wait for a slow site to load. Not me, not you, and definitely not search engines. And the effect of site load times on things like SEO, user bounce rates, purchase intent, and overall satisfaction are only going to become more pronounced over time.
Drupal is a modern web framework that is capable of serving millions of users. But every site is unique, and while Drupal tries hard to be fast out of the box, you'll need to develop a performance profile, caching strategy, and scaling plan that are specific to your use case in order to be truly blazing fast.
Drupal site performance depends on multiple components, from hardware setup and caching system configuration to contributed modules, front-end page weight, and CDNs. Experienced Drupal developers looking to optimize their applications know where to start looking for potential savings. They can manipulate settings and combinations of these components to achieve the desired results. Our goal with this set of tutorials is to help explain the process and provide you with the insight that comes with experience.
In this tutorial we'll:
- Introduce high-level performance concepts for Drupal that we'll then cover in more detail elsewhere
- Provide an overview of the main Drupal performance components.
By the end of this tutorial, you should understand what components around your Drupal application are responsible for site performance.
Goal
Introduce performance concepts and components to developers.
Prerequisites
- None
High-level overview of Drupal's cache system
Drupal has a robust Cache API and various caching layers to support application load and to boost performance. In order for caching to be effective you need to define what can be cached, how long it can be cached, and under what conditions it can be cached.
Some of these caches are internal to Drupal and some are built-in to the stack of applications required to serve and view a web page. All of them are controlled by Drupal's code.
The goal of caching is to not waste time re-creating something that hasn't changed since the last time it was created. This reduces the time it takes to serve it. And, it frees up compute power to handle other non-cached responses.
The layers of the caching system are as follows:
- Browser cache:: Caching provided by the browser. All modern browsers are set up to store copies of static assets such as CSS, scripts, and images if the server gives them permission to do so. This minimizes the network traffic and optimizes the page load time by allowing things to be downloaded once and then re-used. Both the browser cache and reverse proxy cache (see below) rely on Drupal to provide HTTP cache control headers to know what can be cached, and for how long.
- Varnish, CDN (reverse proxy cache): A reverse proxy cache service such as Varnish or one provided by a CDN (Content Delivery Network, such as Cloudflare or Fastly) sits between Drupal and the browser. It can cache and reuse content generated by Drupal that doesn't change from one request to the next. For example, if the content of your homepage is the same for every visitor after Drupal generates the HTML, a reverse proxy keeps a snapshot that it can use to respond to subsequent requests without requiring Drupal to build the page again. This also works for CSS, images, and other static assets. CDNs have the benefit of storing copies of the snapshot physically (geographically) closer to the end user and further reducing latency. Unlike the browser cache, in general, this layer will also provide a mechanism for purging data from the cache. So Drupal can be a little more aggressive about what is stored in this cache.
- Opcode cache: A backend cache that keeps a copy of the compiled PHP script in memory, this can improve your Drupal application's performance.
- Application cache: The Drupal application cache layer. This consists of two major components: cache backends (DB, Memcache, Redis) and the render cache.
Optimizing the application cache layer is vital to ensuring excellent performance of a Drupal site. Fortunately, as Drupal developers, this is the layer over which we have the most control.
If you want to learn about the Drupal caching system in-depth, read the Overview: Drupal's Caching System tutorial.
Page weight and performance budgets
A performance budget is a benchmark or a limit that can be set for a specific performance metric of the site, for example:
- time to interactive
- overall page load time
- first contentful paint
- max time per database query
- max HTTP POST request size
A performance budget can include these as well as other metrics, and sets thresholds for each metric, measured over time.
When working on development of your Drupal site, you'll refer to your performance budget to ensure that new code and features are not degrading the performance of your application. The axiom goes, "If you don't measure it, you don't actually know if it's fast or not."
Learn more about performance budgets and benchmarking in the Overview: Benchmarking and Performance Budgets tutorial.
Performance budgeting goes hand-in-hand with the concept of page weight. Page weight or page size refers to the overall size in bytes of the assets that make up a web page. It consists of all files that compose the web page: HTML markup, images, and other media, CSS files, and JavaScript. The smaller the page weight, the better the performance of your site. Refer to the Overview: Drupal's Cache Modules and Performance Settings tutorial for recommended settings to optimize caching and asset weight.
Content Delivery Networks (CDNs)
A content delivery network (CDN) is a distributed network of servers that work together to provide fast web content delivery. The distributed nature of the CDN allows serving web assets via a server located in close geographical proximity to a users' location.
CDNs not only provide performance optimizations but often act as firewalls, able to enhance the security of the site (alleviating the impact of a DDoS attack, for example).
CDNs are often provided by Drupal web operations platforms and are part of most hosting solutions. They also can be configured separately through third-party CDN services such as Fastly or CloudFlare.
Refer to the tutorial, Overview: Content Delivery Networks (CDNs) and Drupal, to learn about CDNs and their benefits.
Contributed modules that improve performance
The Drupal community has developed and contributed a number of modules that help boost the performance of your application in order to address specific use cases. These modules can be divided into the following categories:
- Debugging modules: Help debug cache headers, tags, and contexts and make it easier for developers to discover where the performance bottlenecks are occurring in their applications.
- Utility modules: Allow for the optimization of some performance settings and enhance the core functionality. For example, automatically optimizing all images.
- Monitoring modules: Allow for monitoring a site's performance and core web vitals.
To learn about some popular modules for Drupal performance optimization, refer to Boost Drupal Performance with Contributed Modules and Extend Drupal Site Monitoring with Contributed Modules tutorials.
Server scaling
As the traffic to your site increases, the resources required to serve that traffic increase as well. Knowing how and when to increase the resources available to Drupal is an important part of any performance strategy.
Server scaling means adding CPU, memory, and storage resources to the server to help it sustain the load. One of the most critical metrics for a server is scalability. Scalability refers to the server’s ability to adjust its settings and configuration to accommodate increased load. Scalability can be vertical or horizontal. You can use both options on their own or in combination.
- Vertical scalability: Refers to adding more resources to a single server and increasing its parameters, such as CPU, memory, or storage.
- Horizontal scalability: Refers to increasing the number of servers that support the Drupal application and spreading the load across them.
Refer to the tutorial, What Is Server Scaling?, to learn more about server scaling for Drupal applications.
Recap
The performance of a Drupal site consists of multiple components such as:
- caching
- server scaling and hardware optimization
- performance budgets
- front-end performance
- CDNs
A well-tuned Drupal site utilizes most of these components to allow for scalability and a good user experience. As developers, we need to understand what the various layers of the performance stack are, and how the code we write and the configuration we set in Drupal can impact these components. And remember, if you're not measuring it you don't know if it's fast.
Further your understanding
- Check the home page of your site. What is its page weight? How could you decrease it?
- Can you list the layers in your applications performance stack? Be specific.
Additional resources
- Why Is Page Weight Important for Web Performance? (dotcom-tools.com)
- Drupal server scaling documentation (Drupal.org)
- Drupal server requirements (Drupal.org)