WordPress 6.2 Performance improvements for all themes
With the latest WordPress release out in the world, this post seeks to recap the performance improvements available for all sites. According to this analysis done by @flixos90 that you’re encouraged to dig into, WordPress 6.2 loads 14-18% faster for block themes and 2-5% faster for classic themes. Server-side performance is seeing a major boost of 17-23% for block themes and 3-5% for classic themes. These changes demonstrate WordPress’s continued commitment to ensuring that websites built on the platform are optimized for performance.
This builds on efforts done in the past that you can read about in the following posts: Need for Page/Post Speed and Performance Matters.
Thank you to @oandregal and @flixos90 for collaborating on this post!
What’s changed
theme.json APIs
Leading up to WordPress 6.2, theme.json related code received more performance related attention partially thanks to an understanding that this newer configuration file has an important role to play in the future of themes. This work aimed to improve Time To First Byte (TTFB), a metric related to server-side performance. It focused on three aspects:
- Introducing new APIs: wp_theme_has_theme_json, get_classic_theme_supports_for_block_settings.
- Caching expensive API operations: wp_get_global_settings, wp_get_global_stylesheet, wp_get_global_styles_svg_filters
- Making API usage more efficient by only demanding the data it needs: do not compute supports for template and template parts.
According to this analysis, caching wp_get_global_settings
had the most impact in the release, improving classic themes by 9% and block themes by 24%. For context, while wp_get_global_settings
was introduced in WordPress 5.9, it’s usage expanded to cover many more use cases, including querying data for rendering front-end blocks. As a result, it benefitted immensely from caching the response.
Lazy-loading images for block themes
While Time To First Byte (TTFB) was a big focus of the 6.2 release, there was also a major change to Largest Contentful Paint, the main user-perceived performance metric: the first image or iframe of the post will no longer be lazy loaded for block themes.
As a reminder, lazy-loading images landed in WordPress 5.5. After an analysis reported that lazy loading images above the fold negatively impacted user-perceived performance, a fix landed in WordPress 5.9 with WordPress 6.2 following up to ensure block themes won’t lazy load the first image or iframe.
Front-end metrics
Outside of the work done to directly improve performance, there was also a focus on making front-end metrics readily available to all. The aim being to ensure developers have the necessary information to make new features performant and catch regressions earlier, all aiding in creating performant future major releases. All Pull Requests in the Gutenberg and wordpress-develop repositories now include front-end performance information. This information is also reported in the following places for a more comprehensive look:
- The Gutenberg dashboard now collects a number of front-end metrics:
- Largest Contentful Paint (LCP): tracks the overall user-perceived performance.
- Time To First Byte (TTFB): tracks server-side performance.
- LCP-TTFB: tracks client-side performance.
- There is a new WordPress core dashboard that reports the following server-side metrics:
- Total: tracks server-side performance. Equivalent to TTFB in the Gutenberg dashboard.
- Before template: tracks the time it takes to dispatch the
template_redirect
hook. - Template: the difference between total time and the time it took to dispatch the tempate_redirect hook.
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.
These “Core Editor Improvement…” posts (labeled with the #core-editor-improvement tag) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects.