Call for 2023 roadmap priorities

[felixarntz]

With the WordPress Performance Team being official and having a dedicated Make Performance site, we should have a team roadmap for what we want to primarily focus on this year. This issue is an open call to share your personal or collective priorities for the year, so that we can aggregate them in an eventual public roadmap to share with the wider WordPress community.

The roadmap should eventually be published as a top-level menu page on https://make.wordpress.org/performance/, and we plan to publish a brief post to inform about it on the Make Core site.

The roadmap should encompass any efforts associated with the WordPress Performance Team, regardless on how those efforts are being implemented - whether it is a pull request to core, a feature project in the Performance Lab plugin, a separate project, etc.

If you're actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue!

For every priority that you would like to focus on this year, preferably include the following:

• A brief project name / title for the effort
• A brief description that summarizes the "What" of the project (e.g. what is being done in this project?)
• A brief description that summarizes the "Why" of the project (e.g. how does this benefit performance in WordPress?)

A good rule of thumb for the descriptions is 2-3 sentences. Don't be too brief, but no need for a PRD-style essay either :)

Last but not least, note that this roadmap is of course not set in stone. Priorities can shift over the year, and the roadmap should remain a living document over time that we keep updating as needed. So this initial set of priorities for 2023 acts as a solid starting point.

This issue will remain open for project priorities until February 15, 2023. Afterwards, the public roadmap will be drafted based on the priorities shared here. The roadmap draft will be shared for review in a future #core-performance chat, to allow for feedback and iterations before it is published.

[felixarntz]

In this comment I'm sharing two priorities that have already been proposed in Make blog posts:

• Creating a plugin checker tool (see proposal post)
  • What: WordPress has had a theme checker tool for many years, to help theme developers test a theme for whether it follows various best practices, including security, accessibility, and performance. Having a similar tool for plugin developers can help them to spot problems in their code in an automated way.
  • Why: It is no secret that plugins play a major role in WordPress performance. No matter how fast the core or the theme is, a single plugin can introduce a major performance leak. With the WordPress plugin checker, plugin developers will have a tool at their fingertips to continuously monitor that they are following best practices.
• Enhancing the Scripts API with a loading strategy (see proposal post)
  • What: The Script API will be enhanced to allow developers to provide a "loading strategy" for their scripts. While today scripts can only be loaded in a render-blocking fashion, this API will allow WordPress to load scripts deferred or asynchronous. It will be implemented in a way that takes script dependencies into account and applies a strategy only if it can be applied without breaking the dependency loading cycle.
  • Why: Render-blocking scripts have a major performance impact on load time performance, and thus the "Largest Contentful Paint" metric (LCP), since they delay the main content of the page. Almost 50% of WordPress sites load too many render-blocking scripts. This enhancement in WordPress core will allow plugin and theme developers to mark their scripts as deferred or asynchronous without a risk of breakage.

[adamsilverstein]

• Adding Automated Performance Testing to core workflows Note: see blog post
  • What: Additional workflow that runs performance benchmarks after each commit, similar to the other automated tests we already run like PHPUnit and E2E tests. The results would be aggregated and made available on a dashboard (similar to Gutenberg's).
  • Why: Automated testing is a critical tool to catch performance regressions early and prevent them from making it into releases. Tracking performance over time will also give us a way to gauge overall progress of the performance initiative.

[aristath]

• SQLite database integration
  • What: Continue improving the SQLite database integration. The module was published, however there are a lot of things to improve.
  • Why: The current implementation is basically a fork of a fork of a 10-year-old plugin. It works, but there are many implementation details that we should change (for example it relies too much on regular expressions to transform the queries). Refactoring the implementation will strengthen security and improve compatibility. The goal is to end up with an implementation that is as good as the current MySQL database implementation included in Core, so we can then propose merging it and making WP officially support SQLite.
• PHP Classes Autoloader
  • What: An autoloader for PHP Classes in WordPress Core.
  • Why: WordPress currently loads everything, on every request. Introducing a basic PHP autoloader would allow WP to only load the files it needs for each request, improving performance.

[kt-12]

Adding fetchpriority="high" to the LCP image in WordPress core

• What: fetchpriority is a new HTML attribute that tells the browser about the priority that a certain resource should be loaded with. By adding the attribute to the LCP image / hero image on each page, we can ensure it is prioritized which will enhance WordPress's load time performance.
• Why: Only ~35% of WordPress sites on mobile perform well in the "Largest Contentful Paint" metric (LCP) which measures load time performance. On pages with images, ensuring that the LCP image loads as soon as possible (by adding fetchpriority="high" to it) can improve LCP performance by more than 10%, which is a significant impact for this relatively straightforward change.

[joemcgill]

Identifying and addressing the largest server response time bottlenecks in WordPress core

• What: Creating and conducting a process by which PHP performance profiling of WordPress core can be analyzed. This will help us identify which parts of the WordPress page lifecycle attribute the most to its overall response time. We can then prioritize enhancements to WordPress Core that improve the performance of those specific subsystems—surfacing concrete functions or APIs that can then be explored for making improvements, either through individual Trac tickets or larger feature projects. Additionally, the tooling and process for this analysis should be documented and shared as a resource for the community to use for future analysis.
• Why: A slow server response time, or "Time to First Byte" (TTFB), is a common problem for WordPress sites that directly affects Core Web Vitals via the LCP metric. Only ~20% of WordPress sites on mobile have a good server response time according to the CWV Technology Report, making it the performance metric with the biggest room for improvement in WordPress.

[rjasdf]

Better SQL indexes on tables

• What: Many tables, especially the "meta" tables are inefficiently accessed. The fixes ("CREATE INDEX") have been put into a plugin, but they should be rolled into the base product. This is a known bottleneck in the WP core.
• Why: Sure, we could depend on the Plugin forever. But with a plethora of plugins, users don't necessarily know the benefit they will get from them. So they hesitate to go through the effort to install them. Or they wait until they have so much data that they worry about the downtime that they may incur for the installation. Improving the indexes will speed up most of the SQL queries.

[mukeshpanchal27]

Eliminating jQuery usage from the frontend in WordPress default themes

• What: Almost all older WordPress default themes up until Twenty Seventeen load jQuery in their frontend for logic that could easily be achieved by vanilla JavaScript. In this effort the affected themes should be modified to eliminate that dependency.
• Why: jQuery is a relatively heavy JavaScript library, particularly when considering that much of its use-case is now obsolete with what is available in more modern vanilla JavaScript, even in now outdated browsers. Replacing jQuery with vanilla JavaScript in such instances can lead to LCP improvements of up to 30%.

[OllieJones]

Build large reference instances for load- and regression- testing large-site performance.

• What: Cloneable sites with tens of thousands of posts / pages / users / categories / tags. Specifically

  • A large blog instance, with 100K users, 100k posts, 1000 pages, 5000 categories, 5000 tags.
  • A large WooCommerce site, number of products and variations tbd.
  • A multisite instance with 5 subsites, and similar numbers of objects to the large blog instance.

  It's necessary to build cloneable sites, then work out how to incorporate them into test workflow.

• Why: Load testing (aka stress testing) is a good way of detecting bottlenecks and concurrency issues in large systems.

  Famously, it's hard to optimize things you can't measure.

  Finally, repeatable testing can help catch performance regressions.

Notice that these reference sites may help @adamsilverstein's goal of automated performance testing.

[OllieJones]

Optimize the taxonomy subsystem.

What: Find and fix inefficiences in the taxonomy subsystem.

Why: Field data on MariaDB / MySQL performance shows large-site problems (some stunningly slow queries) in taxonomy handling. There's probably some low-hanging performance fruit to harvest.

[felixarntz]

Avoiding to lazy-load LCP / hero images in WordPress core

• What: While WordPress core already has logic to determine what is likely the LCP image on a page in order to not lazy-load it (as introduced in WordPress 5.9), there is still a high occurrence of WordPress sites that lazy-load their LCP images as of today (see this Web Performance Calendar post). This effort is about identifying those use-cases and implementing solutions in WordPress core to ensure they are also covered.
• Why: While lazy-loading images in general is a great practice to reduce bandwidth and contention between images on a page, lazy-loading the LCP image is a bad pattern as it increases the time the page takes to load. Avoiding to lazy-load the LCP image has in the past led to LCP improvements of up to 33%, so bringing this improvement to more sites is vital for a larger horizontal impact.

[joemcgill]

Improving the calculation of image sizes attributes

• What: When we introduced responsive images to WordPress in version 4.4, WordPress had almost no way of knowing what the intended layout of an image should be when calculating the sizes attribute. Therefore, we shipped a reasonable default value and encouraged theme authors to filter that default for more accurate sizes attributes. With block themes, we now have more layout information available and may be able to improve the default sizes calculation for images.
• Why: While it's already possible for theme authors to filter the sizes attribute of images, calculating these accurately is fairly complex, and many WordPress sites are either not filtering this attribute or are doing so inaccurately. According to this Web Almanac analysis there is a significant opportunity to improve performance of image loading by improving the accuracy of the sizes attribute WordPress produces.

[felixarntz]

Optimizing the autoloaded options database query in WordPress core (see module proposal)

• What: An algorithm should be implemented that tracks the options which are actually used on a page, so that the list of options to autoload is dynamically managed by WordPress core themselves. Plugin developers will still be able to influence whether a specific option should be autoloaded or not, but they will no longer be fully responsible for it.
• Why: The autoloaded options database query in WordPress is a costly part of every WordPress page load, and it can lead to errors even with persistent object caches if the list of options gets too large. This is a common occurrence for sites that have existed for a long time and used a variety of plugins throughout their existence. The underlying problem is that WordPress relies solely on plugin developers to define whether an option should be autoloaded or not, however the parameter to control this configuration setting is not necessary to provide and defaults to autoload every option, which leads to the aforementioned excessive amount of autoloaded options.

[felixarntz]

Posting here some notes from @spacedmonkey that he shared with me via DM (he didn't post himself because of limited availability this month):

• Lazy loading meta data.
• Improve performance of translations.
• Autoloaded options.
• PHP versions, upping min version and removing backwards compablitiy for php 5.2/4 that is still in core.
• Block theme performance

I already proposed an item for optimizing the autoloaded options query in https://github.com/WordPress/performance/issues/631#issuecomment-1430191057, but the other 4 points weren't explicitly mentioned before on this issue. 👍

[felixarntz]

Thank you everyone who posted a comment on this issue! 🙌

As mentioned in the issue description, at this point the preparation phase of collecting priorities in this issue is closed.

Based on all the feedback above, I will draft a roadmap for the performance team that shall eventually be published on the Make Performance site. Once there is a draft, I will share it in the #core-performance Slack channel for review and feedback prior to publishing.

[alexdhika]

integrated with openswoole and roadrunner