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 project, a collection of performance-related “feature projects” for WordPress core.
Team Reps
Our current team reps are Aditya Dhade (@b1ink0) and Shyamsundar Gadde (@shyamgadde), elected in March 2025.
Previous team reps were:
- Felix Arntz (@flixos90), September 2022 to February 2025
- Emily Clarke (@clarkeemily), February 2023 to February 2025
- Bethany Chobanian Lang (@mxbclang), September 2022 to February 2023
Learn more about Team Reps here.
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, other companies and individual 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-party.
See the dedicated Contributors page for a list of current and previous contributing companies and individuals.
Focus areas
Features are broken down into distinct plugins. Each plugin 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 regularly provide an update on their work during our office hours.
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.
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.
Philosophies
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..
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.
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.
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.
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.
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.
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.
