Lighthouse is an open source, automated tool for analyzing your site's performance. Lighthouse is built-in to the Google Chrome browser. When auditing a page, Lighthouse runs various tests against the page and then reports how well the page did across a broad spectrum of metrics. While Lighthouse doesn't improve the performance of a Drupal site itself, it helps to establish a performance profile and point towards areas that could be improved.

Lighthouse requires the use of Google Chrome. Other browsers include their own performance auditing tools. While the exact usage of each tool varies, the end result is the same: a report that can be interpreted to suggest where to focus your performance-tuning efforts.

In this tutorial, we'll:

• Learn how to run Lighthouse tests against a Drupal site
• Interpret the results of the report generated by Lighthouse
• Provide guidance on next steps to take to address the performance issues Lighthouse finds in our Drupal site

By the end of this tutorial you should be able to use Lighthouse to profile a Drupal site, interpret the results, and know where to start on making improvements.

Apache Bench (ab) is a tool that comes with the commonly used Apache HTTP server. It is designed to give you an impression of how your current Apache installation performs. It will work for any HTTP server, not just Apache. Apache Bench shows you how many requests per second your server can serve. This metric is in part a measure of how long it takes Drupal (PHP) to process the request and create a response. While there are other things that the HTTP server does too, executing PHP is by far the most expensive when serving Drupal pages.

Therefore, Apache Bench helps profile your PHP code for new features, patches after their application, and PHP libraries used on the site. You can quickly compare before and after metrics as an indicator of the scale of the impact a change has.

In this tutorial, we'll:

• Learn how to run the Apache Bench tool on our local environment
• Learn to interpret the result of the tests

By the end of this tutorial, you should know how to benchmark and profile your local Drupal installation using Apache Bench (ab).

Sites evolve over time. We're constantly adding and removing modules, modifying content, authoring custom plugins, and changing design elements. All of these changes impact our application's performance -- some more so than others. But if you're not measuring it, you can't know when your site inadvertently gets slower or by how much.

If you are responsible for a site's performance, it might be good to look into benchmarking it and establishing a performance budget early on, then monitor it on an ongoing basis. Many tools, paid and free, allow measuring key web performance indicators and backend code and server performance.

One-time measurements can be useful for immediate debugging, or when figuring out if that big new feature is going to have a negative impact on performance. But for long-term projects, it's helpful to have known baseline values and an established performance budget to see whether your performance improves or declines over time with every new feature.

Establishing the baseline (performance budget) and comparing future measurements is called site performance benchmarking.

In this tutorial, we'll:

• Learn the basics concepts of benchmarking
• Learn a benchmarking process and best practices
• List some commonly used tools for benchmarking Drupal

By the end of this tutorial, you should understand the concept of a performance budget, know when to benchmark your site, and list some tools available to help.

Pantheon uses its Object Cache and Global CDN services to help improve the performance of your Drupal sites. Using them requires a few steps to enable the services and configure your Drupal site to use them effectively.

Many performance optimizations are hosting-provider-specific. This tutorial covers some Pantheon-specific methods for increasing your Drupal site's performance. It's only relevant if your site is hosted on Pantheon. For other common providers, and generic performance tuning tips, refer to other tutorials in this course.

In this tutorial we'll:

• Learn how to configure and use Pantheon's Object Cache to speed up Drupal caching
• Learn about the use case for Pantheon's Advanced Page Cache module
• Install and configure the Advanced Page Cache module for better Drupal caching of sites hosted on Pantheon

By the end of this tutorial you should be able to explain when and why you would want to use Pantheon's Object Cache and Advanced Page Cache modules, and how they can help speed up Drupal sites hosted on Pantheon.

Over the history of the Internet, the single Page Speed metric evolved into various parameters that influence user experience. These metrics are commonly referred to as Core Web Vitals. Together, they paint a comprehensive picture of the performance of your site from an end user's perspective. These metrics are considered by Google and other search engines when assigning SEO scores.

Knowing what these metrics are, and what they are intended to measure, is an important part of creating a performance profile for your site. This knowledge can also help you find solutions for common performance issues.

In this tutorial, we'll:

• Define the metrics that make up the Core Web Vitals
• Point to additional resources where you can learn more about each metric

By the end of this tutorial, you should know which performance metrics are considered Core Web Vitals and what aspects of site performance they cover.

The performance optimization settings and modules provided by Drupal core are intended to work for the broadest possible set of use cases. From an administrator's perspective they provide minimal configuration options, and are designed to just work by being enabled. But behind that simplicity are some powerful features that will help speed up any Drupal-powered application.

The core Dynamic Page Cache and Internal Page Cache modules are designed to provide a base cache setup for any site. These modules are responsible for the static page cache, dynamic page cache, and lazy loading optimizations.

For developers, Drupal provides a complete and well-designed Cache API. You can, and should, integrate it into your custom code. This integration includes defining the cacheability of any content your module outputs so that Drupal can be smart about how that affects how and when a page that incorporates the output can be cached -- as well as storing and retrieving the results of complex or long-running operations. The API also helps with setting appropriate HTTP headers for the responses Drupal generates for each request so that the user's browser and other layers in the stack can appropriately cache the output.

The entire system is flexible, and there are many contributed modules that can aid in making the default caching system even faster for specific use cases.

In this tutorial, we'll:

• Learn about the caching-related modules in Drupal core
• Review the Drupal core performance settings and recommended values

By the end of this tutorial you should be familiar with the Drupal core modules responsible for caching, their settings, and recommended values.

There's no magical set of right tools to use to monitor a Drupal site's performance and health. While thinking about performance monitoring, you need to optimize your approach depending on the number of applications you manage, their complexity, business needs, and the skill-set of your team. Based on these factors, you may choose to use one of the core or contributed modules, go with third-party solutions and services, or some combination of both.

Drupal core comes with a couple of modules that allow you to monitor the health and performance of the site including Syslog, Database Logging, and the status reports provided by the System module. There are also numerous community-contributed modules, a sampling of which we'll cover here.

In this tutorial, we'll:

• List some contributed modules that are commonly used for monitoring a Drupal site
• Provide an overview of what each module does

By the end of this tutorial you should be able to list a few contributed modules that might be useful for monitoring your Drupal application and define what each one does.

New Relic is a monitoring service that provides insights into your application stack from front-end performance to the server and infrastructure metrics. New Relic uses a combination of aggregating server logs, and pre-built (or custom) monitors to track the metrics that are most important to your application. The collected data can be organized into custom dashboards, and alerts can be set up and issued per customizable conditions.

In this tutorial, we'll:

• Learn about different New Relic modules and their purpose
• Review some default dashboard components and reports
• Discuss how to use the information in New Relic to understand the health of your Drupal application

By the end of this tutorial, you should understand the basics of using New Relic and the insights it offers to monitor and improve the performance of your Drupal site.

Performance profiling allows you to see an overview of how your Drupal application stacks up against your users' needs and business requirements. A good profile will help you understand where the performance bottlenecks are and where you should focus your efforts in order to achieve the best results when optimizing your application.

There are many profiling tools available to help you analyze your Drupal site's performance. Some are free -- like the browser’s built-in development tools, the Lighthouse Chrome extension, and XHProf. Some are paid -- like New Relic, Blackfire, and other profiling SaaS solutions.

In this tutorial we'll:

• Outline the general concepts and goals of performance profiling
• List some available profiling tools and their features

By the end of this tutorial you should be able to describe what performance profiling is, and list the tools commonly used to establish a performance profile for a Drupal site.

When your site is experiencing performance issues, one way to pinpoint the cause is to use profiling tools. Before you can fix the issue you have to be able to identify what's causing it. All profiling tools do roughly the same thing: they tell you what code is called during the request and how much time is spent executing it. This helps to identify the slowest code and dig deeper into the cause. Once the cause is determined you can start figuring out how to optimize the code.

For this tutorial, we’ll use New Relic as a profiling tool, but you can apply a similar methodology using the profiling tool of your choice.

In this tutorial, we'll:

• Learn how to identify and analyze slow transactions
• Look at common things to check for while profiling
• Cover some questions you should ask when looking at profiling data to help track down the slow code

By the end of this tutorial, you should know how to profile a Drupal site (specifically with New Relic) to find performance bottlenecks.

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.

If you want to define a new URL that a user can navigate to, and custom PHP code that will generate the content of the page, you need a route and a controller. Most of the time you'll want to do something more complex than hard code the content of the page. This will require using services in your controller. This can be accomplished in different ways.

In this tutorial we'll:

• Provide the definition for a new route which maps a path to the callback method of a controller class.
• Create a controller that returns a hard coded string.
• Look at examples of using both ControllerBase and dependency injection to access services from a controller, and discuss the benefits of both approaches.

By the end of this tutorial, you should be able to define a new route that maps to a controller and displays content on the page as a result of your custom logic.