The WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem. We build and manage the Performance Lab plugin, a collection of performance-related “feature projects” for WordPress core.
The WordPress CoreCoreCore 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.
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 TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. and the Performance Lab pluginPluginA 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. A full list of contributors to the Performance Lab plugin is available here.
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 & CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site.– Optimizing JavaScriptJavaScriptJavaScript 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 GitHubGitHubGitHub 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.
The Performance Team’s work is always mindful of the broader WordPress core philosophies. In addition, we have our own defined mission and philosophies.
The WordPress Core Performance Team is a dedicated working group to tackle monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem.
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 APIAPIAn 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..
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.
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.
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” 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.
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.
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.