WordPress 6.4 is the third major release of the year that delivers a better user experience to site visitors by improving performance of the core software. This version improves server response time by ~4% over version 6.3.2. This, combined with additional frontend optimizations, leads to improvements to Largest Contentful Paint (LCP)—an important Core Web Vital. For example, Twenty Twenty-One (a classic theme) shows an improvement of ~4% for LCP and Twenty Twenty-Three (a block theme) shows a ~9% LCP improvement when run on WordPress 6.4 compared with 6.3.2 based on benchmarks conducted by the WordPress Performance team.
This release caps off an ambitious year of work for the Performance Team, with major improvements made in each release. You can read more about those improvements in the performance improvement summary posts for version 6.2 and version 6.3. While version 6.2 focused on server side improvements, and 6.3 focused more on client side improvements, this release was focused on continuing server side improvements while further optimizing and extending the improvements that were made earlier in the year. Meanwhile, the team continued iterating on the tools and methodologies used to measure and report on performance.
An overview of the performance enhancements in this release is included in the WordPress 6.4 Field Guide and you can read details about the following highlights in their individual dev-note posts:
Server side improvements
Client side improvements
Previous performance benchmarks reported for each release were taken by @flixos90 (the performance release lead) on his own computer, using a standardized set of best practices and tools. This release we have attempted to automate the process in order to establish a reproducible methodology that can be used by any contributor using a standard set of tools.
The process for this release uses the compare-wp-performance GitHub action, originally developed by @swissspidy, which sets up two standard test sites using wp-env inside of a GitHub worker, takes a set of metrics based on 100 requests, and reports them in the action summary (example). To account for variance between each run, this is done 5 times and the median values are used for reporting purposes.
Since the testing environment has an important impact on performance benchmarks, we wanted to revisit the previous versions from this year and apply the same methodology for comparison. Each of the following metrics show the percentage the metric either improved (negative numbers) or got worse (positive numbers) between versions.
Twenty Twenty-One
Twenty Twenty-Three
Twenty Twenty-One
Twenty Twenty-Three
Twenty Twenty-One
Twenty Twenty-Three
Detailed data can be found in this spreadsheet, with links to the individual GitHub workflows.
While the methodology used for this release is an improvement over the previous process, there is much room for improvement, including finding ways to stabilize the metrics collected during benchmarks for releases and during development, improving the test content and use cases we test for these benchmarks, testing different configurations and environment characteristics (e.g., PHP versions, persistent object cache, etc.).
Props to @joemcgill for taking the time to write this extensive and detailed post, and @flixos90 for review.
WordCamp Europe, the biggest WordPress conference in Europe, spent the first week of June in…
tl;dr: Temporary 24-hour cooldown period for plugin/theme releases before auto-updates. AI can give defenders an…
The full chat log is available beginning here on Slack. WordPress Performance Trac tickets @b1ink0…
WordPress at 23 is simultaneously both the strongest and most precarious it’s ever been. Last…
June 4-6, 2026 | ICE Kraków Congress Centre, Kraków, Poland WordCamp Europe 2026 will bring…
Every WordPress release celebrates an artist who has made an indelible mark on the world…