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!
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:
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:
template_redirect hook.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.
WordCamp Asia 2026 brought the global WordPress community to Mumbai, India, from April 9–11, gathering…
WordCamp Asia 2026 will be available to watch live across three days of streaming, making…
April 9-11, 2026 | Jio World Convention Centre, Mumbai, India WordCamp Asia 2026 brings the…
The second Release Candidate (“RC2”) for WordPress 7.0 is ready for download and testing! This…
When WP Engine acquired WPackagist on March 12, the WordPress developer community faced a familiar…
The first Release Candidate (“RC1”) for WordPress 7.0 is ready for download and testing! This…