About the Team

The WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team was established in 2021 and is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem.

The Core Performance Team builds and manages the Performance Lab plugin, a collection of performance-related “feature projects” for WordPress core.

Team Reps

Our first and current team reps are Felix Arntz (@flixos90) elected in September 2022, and Emily Clarke (@clarkeemily), elected in February 2023.

Learn more about Team Reps here.

Top ↑

Project organization

The Performance Team was initially proposed and spearheaded by a partnership of several organizations in the WordPress space, including Google, 10up, XWP, and Yoast. Each organization has committed personnel and contribution hours for the Performance Team. In addition, many community members also participate in discussion and contribute code to both TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. and the Performance Lab pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-partyA full list of contributors to the Performance Lab plugin is available here.

Top ↑

Focus areas

While the Performance Team works on any and all issues related to WordPress performance, much of our work is directed toward the following focus areas, which were voted upon by the Team:

  • Images – Serving images in good quality but as small as possible
  • JS & CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. – Optimizing JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and CSS orchestration
  • Database – Optimizing database performance
  • Measurement – Compiling data and analysis and reporting on performance
  • Object Cache – Improving object caching, e.g. Redis, Memcache, etc.

Each focus area has one or more designated points of contact (POCs). For an up-to-date list of current POCs, please see the Performance Lab CODEOWNERS file. POCs and members from each focus area provide an update on their work during our weekly chats.

All Performance Lab issues are labeled with an appropriate focus area using a [Focus] label and are added to the appropriate focus area’s GitHub Project. For more information about managing GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Performance Lab issues, see the Performance Lab section of this Handbook.

Top ↑

Mission and philosophies

The Performance Team’s work is always mindful of the broader WordPress core philosophies. In addition, we have our own defined mission and philosophies.

Top ↑

Mission

The WordPress Core Performance Team is a dedicated working group to tackle monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem.

Top ↑

Philosophies

Top ↑

Automated fixes as the end goal

We aim to explore ways for WordPress core to solve performance problems on its own without burdening third-party developers or end users. We should approach every performance issue that we tackle with that end goal in mind and never settle for “just” introducing an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..

Top ↑

Consuming our own APIs

Introducing an API on its own is historically problematic in WordPress core. We should only merge an API into WordPress core if we can demonstrate that it is beneficial with real usage. We should consume our own APIs in WordPress core right away, facilitating an automated fix to the related performance problem and proving their effectiveness. 

Top ↑

Metrics over subjective assertions

We should avoid theories, hypotheses, and sentiment and instead rely on defined metrics, research, and data (preferably real user metrics as opposed to “lab data”) to inform and back up our decisions.

Top ↑

Enhancement for most, regression for none

We should always be aware of and understand edge cases and be mindful that a performance enhancement for the majority should not cause breakage or other adverse effects for the minority. Backwards compatibility is critical.

Top ↑

Decisions, not options

“Decisions, not options” has long been a major tenet of the WordPress core project, and it is especially relevant for performance. Web performance is an inherently technical topic and we must make the right performance decisions for end users and not burden them by asking them to make technical performance decisions. Relatedly, we should only launch a feature in core if it can be enabled by default because it has been thoroughly tested and we are confident that it can successfully be utilized on every site. However, fine-tuning performance behavior should still be possible for developers, even if a feature is enabled by default.

Top ↑

Standards and wide support

We can only implement web technologies in WordPress core that are already standardized and widely supported. If a specific technology is already standardized, but still not supported across all servers or browsers that WordPress core officially supports, we should ensure that implementation can be made as a progressive enhancement that does not bring any adverse effects in unsupported environments.

Top ↑

Easy-to-understand performance guidance and actionable recommendations

We acknowledge that a large number of WordPress sites are maintained by users that do not know how to code. Any performance-related guidance that we provide should be easy to understand, only include minimal technical information, and provide end users with a clear way that they can do something about it. 

Last updated: