Over the past two years, I’ve had the opportunity to work as part of the WordPress Performance Team, which has the ambitious goal of making the user experience of the whole internet better by improving the performance of WordPress, which powers over 40% of sites on the web. As the year comes to a close, I wanted to share some things that I’ve learned in the process.

Good ideas are not enough

The WordPress Performance Team began in late 2021 with many ideas about the types of projects that they could work on. New initiatives often start with an abundance of ideas and yet struggle to make progress on those ideas due to all sorts of challenges, like a mismatch between the team’s ambitions and the resources available, a lack of clear objectives, or an inability to commit to and execute a coherent strategy.

To the credit of the folks who started the WP Performance Team, they set the team up for success by incorporating several key factors into the team’s founding, which we’ve been able to sustain and expanded on over the past several years:

1. A clear objective
2. A way to measure success
3. A set of projects aligned with the objective
4. The ability to successfully complete those projects
5. A continual process of learning and improvement

1. A clear objective

The WordPress Performance Team site opens by stating, “The WordPress Core Performance Team is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem.”

The mission and philosophies of the team provide more details about the team, but to simplify, the team exists to make websites built with WordPress faster for the people who visit them. While certainly ambitious, this is a very clear objective that helps to guide all of the activities of the team.

2. A way to measure success

Even with a clearly stated objective, a lofty goal like “we want to make WordPress faster” isn’t all that meaningful unless you can be specific about how you are measuring “fast”. Otherwise, it’s too easy to cherry-pick examples that support the value of your work. Thankfully, Google has established Core Web Vitals (CWV) as a set of industry standard metrics that can be used to identify opportunities to improve the software and a means to measure the impact of specific enhancements.

Even though the metrics are clear, the ways of measuring those metrics can be complex and nuanced. To help clarify and standardize the approaches we use, we’ve documented tools and process for how we measure performance in our Team Handbook and use these tools to continually monitor and improve our practice. More on this later.

3. A set of projects aligned with the objective

Each year, the Performance Team publishes a public roadmap of projects that the team intends to work on. These projects include experimental ideas and research projects where the impact is yet to be determined, opportunities where clear performance improvements have been identified, and some internal projects intended to bolster the team’s ability to execute and measure performance.

For most of the projects that the team works on, some initial discovery has been done to determine if the potential impact of the work is worth the investment of time that would need to be made to complete the project. To illustrate why this is important, I could hypothetically have a big impact by personally implementing performance best practices on each website individually, but the time needed to do so makes this clearly an absurd idea to propose. Therefore, we have to evaluate the impact of our work against the effort required to complete it.

We evaluate the priority of each project or feature based on how large the performance improvement is likely to be, how broadly that improvement will be adopted across all sites, and how much effort (both in terms of engineering and community engagement) will be required to ship and promote the work. With this in mind, the projects with the greatest chance of success are ones that are easier to execute, are not likely to face a lot of community push-back, can be adopted by default on most websites, and are expected to have a big impact out of the box. Conversely, opt-in improvements—or ones likely to face a lot of pushback—are less likely to be prioritized as high.

4. The ability to successfully complete those projects

Related closely to the last point, having a clear set of projects to work on are only useful if you have the ability to implement them. This means having more than just the right engineering skills, but also requires that you have the ability to plan and execute the engineering effort needed to complete the project. This includes supporting the time needed to stay focused on the effort and the ability to ship and promote the work once it has been completed.

Without the right expertise on the team, it will take a lot longer to learn iteratively to produce a working solution. Without a clear plan to break down the project into smaller goals you can easily get stuck in an overwhelming set of problems that inhibit progress or waste time. Without the ability to stay focused on the project—due to factors like changing team goals, interruptions from other priorities, team members changing roles and needing to step away from the project, etc.—progress can be slow. Without the ability to ship and promote the feature you can see a lot of time and effort wasted by hitting a last minute roadblock from important stakeholders, lack of adoption of the feature, etc.

In a wide-ranging open source project like WordPress, all of these have to be kept in mind, but for me I think being able to limit interruptions is the most challenging as there are always new and interesting problems that can catch my attention or colleagues working on other priorities whom I would like to support.

5. A continual process of learning and improvement

Working on performance is very satisfying for me, because I can make observations about the current performance of the application, plan and implement an improvement, and then measure the impact of that change. However, implementing a process for continual observation and learning is takes a lot of effort. To streamline this work, we’ve implemented several processes that support continual learning and improvement.

First, to allow for experimentation and observation, the Performance Team maintains the Performance Lab program as part of the WordPress organization. This project, which started as a single feature plugin, but has expanded into a mono-repo for a set of feature plugins, allows the team to ship and test experimental features before they are proposed for WordPress Core.

Many of the tools and processes we use for measuring performance in our day-to-day work have been incorporated into an automated performance workflow, which runs on each PR to WordPress to measure the performance impact of the change before it is committed, to record the impact of each change after it is committed, and send the results of those measurements to a custom dashboard that tracks performance over time. Also, during each release cycle, a Performance Lead reports benchmarks comparing the current in development release with the previous major release starting at the first beta in order to help discover and fix any regressions that may have occurred during that cycle before the release is shipped. Here’s an example of the performance benchmarks for 6.7.

In addition to those tools, we make use of field data collected by the Chrome User Experience Report (CrUX) to track the real world change of WordPress performance metrics over time for each release. Felix Arntz recently shared an overview of 2024 CWV impact data in a recent hallway hangout.

Sustaining momentum is hard

In the earliest phase of the Performance Team, there were many opportunities to make sizable performance impacts by finding and fixing large performance problems like improving the way images are loaded and improving WordPress’ translation system or implementing web platform features like registering scripts with async and defer attributes or auto-sizes for lazy-loaded images.

However, as the team has had success and the initial set of big-impact opportunities have been addressed, the team risks facing diminishing returns on investment as the current work-streams require equal or greater effort for lesser potential impact. At the same time, the project continues to evolve it’s feature set in exciting ways, but the additional functionality can sometimes come with a performance cost to end users. In addition, folks who have been involved in the project will naturally have changing priorities over time, requiring new contributors with fresh ideas to pick up the work and push it forward.

Given the continued scale of WordPress market share, I am confident that there are numerous opportunities for the WordPress project to make major contributions that progress good user experiences on the web and look forward to being a part of those efforts. If you’re interested in how you can participate or support the work of the WordPress Performance team, please get in touch!