Update (Aug 8, 2023): Benchmarks in this post were updated with results for the 6.3 stable release.
With WordPress 6.3 now available, this post summarizes the performance improvements that are part of this release. While WordPress 6.2 set the bar high with its notable boost to load time performance of Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., WordPress 6.3 has been able to exceed these results: Based on the performance benchmarks conducted, WordPress 6.3 loads 27% faster for 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. themes and 18% faster for classic themes, compared to WordPress 6.2, based on the Largest Contentful Paint (LCP) metric. For WordPress 6.2, those improvements amounted to 18% and 5% respectively, so it is fair to summarize that WordPress 6.3 is a major achievement in terms of performance.
Thank you to @clarkeemily for collaborating on this post!
What makes 6.3 so much faster?
To break down the performance improvements in 6.3, it is crucial to understand the different load time performance metrics and how they relate. The most holistic metric is Largest Contentful Paint (LCP) because it captures overall load time performance. As such, the percentages mentioned in the introduction of this post were specifically the LCP improvements measured.
An important part of LCP is the Time to First Byte (TTFB) metric, which captures server-side load time performance and thus directly affects LCP: Effectively, TTFB is the server-side part that contributes to the LCP result. For client-side load time performance, there is no dedicated standalone metric. However, since client-side performance is effectively everything else, it can be concluded that client-side load time performance can be expressed by the difference between LCP and TTFB, i.e. “LCP-TTFB”.
Client-side performance
In WordPress 6.2, the majority of the performance boost came from improvements to server-side performance (TTFB), as highlighted in the aforementioned 6.2 performance improvements post. In WordPress 6.3, that is different: Most of the performance boost stems from client-side performance improvements (LCP-TTFB). In fact, client-side performance in WordPress 6.3 is 40% faster for block themes and 31% faster for classic themes, compared to WordPress 6.2. For reference, in the comparison of WordPress 6.2 with 6.1 LCP-TTFB amounted to only a 1.5% and 2.5% improvement respectively.
The vast majority of the client-side performance improvement comes from optimizing the emoji-loader.js script, by leveraging modern 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/. APIs such as Web Workers, OffscreenCanvas, and sessionStorage. Unless your WordPress site has disabled the related emoji functionality, you should notice a performance improvement due to this enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. See #58472 and [56074] for additional context on this change.
The other notable portion of the client-side performance improvements stem from adding support for the fetchpriority="high" attribute on images. As such, this improvement is only relevant on content with images above the fold, but given that images are by far the most common media used on web pages, it is very likely that you will notice a performance improvement from this enhancement as well. For a comprehensive overview of how to leverage and modify the new functionality as a developer, please refer to the 6.3 dev note on image performance improvements. For additional context on the change, see #58235 and [56037].
The following list highlights a few additional tickets that can improve client-side performance in certain scenarios, several of them enhancing the heuristics for whether to add the loading="lazy" attribute to images:
Last but not least: A notable developer feature that should be highlighted here is the introduction of script loading strategies, which adds support for loading scripts with defer or async. This is a major milestone for performance in general, however so far only the 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. itself has been introduced, which means there is no actual performance impact from it yet, which is why the change was not mentioned earlier in the post. As WordPress core and the ecosystem starts adopting the API (e.g. defer for block view scripts and async for comment-reply), it is anticipated that in the future we will see notable performance improvements from it as well. Please read the 6.3 dev note on registering scripts with async and defer to learn more on how you can leverage the API as a developer and the advantages over approaches that directly manipulate the script tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). See #12009 and [56033] for additional context on this change.
Server-side performance
While server-side performance improvements in 6.3 overall did not account for as much of the performance boost, the release still includes several notable enhancements, particularly for block themes, where server response time is 19% faster. Many of the server-side performance enhancements are the result of optimizing low-level logic in WordPress core internals. While this makes the improvements difficult to describe in isolation, it means that they don’t require any adoption or modifications in the WordPress ecosystem in order to become effective.
One of the most notable performance enhancements for block themes was a low-level change which optimizes how WordPress core block styles are registered. This is relevant since core block styles are handled slightly differently from those of custom blocks. Prior to 6.3 however, all blocks were using the same general logic which included quite a bit of flexibility, and thus also a performance cost, which was unnecessary for the core blocks. The change introduced a dedicated function to register core block styles in a more efficient way. See #58528 and [56044] for more context on this change.
Another major win for block theme performance was an improvement to the get_block_templates() function. The logic in that function was optimized to no longer process all block templates but only those that match the current query. See #57756 and [55687] for more context on this change.
The wp_common_block_scripts_and_styles() function is another optimized function that is certainly worth highlighting. This enhancement is only relevant to hybrid themes, specifically classic themes that call add_theme_support( 'wp-block-styles' ), but for those themes it results in a major server-side performance boost. See #58560 and [56064] for more context on this change.
The biggest change that has a notable performance impact for both block themes and classic themes is a performance optimization in the wp_maybe_inline_styles() function which avoids unnecessary calls to relatively costly functions to get the size and contents of stylesheet files. See #58394 and [55888] for more context on this change.
The following list highlights a few additional tickets that can improve server-side performance in certain scenarios:
Database performance
Several enhancements were made in WordPress 6.3 to lazy-load metadata, which can avoid database queries in certain situations. These changes are outlined in the 6.3 dev note post on metadata API improvements. See the individual tickets #57227, #57645, #57901, and #58185 for more context.
Additionally, the get_pages() function now uses WP_Query internally, which not only means elimination of duplicate code, but more importantly it leads to a performance improvement in the function as it now benefits from the same solid caching behavior, something that was missing in the previous custom implementation of the function. For more context, please see the 6.3 dev note on the get_pages() function and the ticket Created for both bug reports and feature development on the bug tracker. #12821.
Last but not least, the WP_User_Query class now supports caching query results, becoming the last of the WordPress core query classes to support it. This can avoid database queries when querying user information. For more context, please see the 6.3 dev note on WP_User_Query caching and the ticket #40613.
A note on the benchmarks used
While the metrics shared in this post are based on benchmarks that were conducted with the same methodology used for WordPress 6.2, any benchmarks need to be interpreted with nuance: Other than how the WordPress site used for benchmarking is configured, benchmarks are heavily dependent on the environment that they are run in. To have additional reference points, a few different contributors conducted and shared their benchmarks as well, based on a slightly earlier version of the release, 6.3 RC1. All of the benchmark results are summarized in this spreadsheet.
It can be noted there that some of the other benchmarks did not see improvements as high as noticed in the benchmarks highlighted (which, for context, were run on the author’s machine), but the main takeaway is that there is a notable performance boost overall. For now it made sense to focus on the performance benchmark with the numbers highlighted in this post in order to be consistent with the numbers from the aforementioned 6.2 performance improvements post, since that was using the same environment for the performance benchmarks as well. For any of the other contributors’ benchmarks where the relative improvements were not as high, it can be assumed that the 6.2 performance benchmarks on their environments would have shown an equivalently lower performance boost as well.
While this means we cannot get a definite answer to how much faster WordPress 6.3 is, it is safe to say that it is a lot faster than 6.2, and relatively speaking the performance improvement is even higher than it was between 6.2 and 6.1.
Automated benchmarking workflow
Some of the benchmarks referenced were conducted using a new reusable automated benchmarking workflow that @swissspidy recently implemented, using the same approach as the manual benchmarks, but using GitHub 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/ Actions. Those results show that using this workflow leads to more consistent results overall due to using the same environment, and it furthermore reduces the effort needed to conduct performance benchmarks. In the future it may be a good idea to rely on the numbers from that workflow rather than those from an arbitrary environment of a specific contributor. For reference, the automated workflow numbers roughly indicate the following performance improvements in WordPress 6.3 compared to 6.2:
- LCP is 10.6% faster for block themes and 8.8% faster for classic themes.
- TTFB is 4.7% faster for block themes and 5.6% faster for classic themes.
- LCP-TTFB is 13.4% faster for block themes and 9.3% faster for classic themes.
Get involved
If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both.
Props to @adamsilverstein, @annezazu, @joemcgill, @oandregal, @spacedmonkey, @westonruter for review and proofreading.
#6-3, #block-themes, #core-editor-improvement, #core-performance, #performance
