The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
Congratulations to all who helped make WordPress 6.5! Now that it has launched, I invite you to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases.
Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.
Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.
The form and comments will be open until April 26th, 2024. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.
Again, thank you for your contributions to 6.5 “Regina,” and for taking the time to help make future releases even better!
This post summarizes and highlights the impact that WordPress has had on Core Web Vitals (CWV) in the field in 2023, providing a metric-based retrospective at the end of the year.
TL;DR: The WordPress performance team and all WordPress contributors can be very proud of the accomplishments: The overall CWV passing rate across all WordPress sites has improved from 28.31% to 36.44% (+8.13%) on mobile devices and from 32.55% to 40.80% (+8.25%) on desktop devices. 🎉
These improvements led to a visible increase of CWV passing rates even for the entire web. The performance team is currently discussing additional findings to define the focus for 2024 and is looking for further proposals and contributors for next year.
Before looking at the 2023 metrics in more depth, a few things should be clarified.
The metrics shared in this post are exclusively field metrics. They are distinctively different from lab metrics, which are the metrics that have typically been shared in the WordPress release performance summary posts this year:
Lab metrics are benchmarks conducted on demand, typically as a synthetic A/B performance comparison. They provide an indication of whether/how a specific change is anticipated to impact performance. For example, for the lab metrics shared for the WordPress releases in the aforementioned posts, the load time performance of the respective new WordPress version was compared to that of the previous version, on the exact same setup, so that the only different variable is the WordPress version.
Field metrics on the other hand are analytics data collected from site usage and provide an indication of how performance is actually experienced by real users on real sites. For example, the Chrome User Experience Report (CrUX) provides a public dataset of performance field data from opted-in Chrome users, aggregated at the site level. The WordPress 6.3 field impact summary post shared metrics queried from that dataset, granularly broken down for just that release compared to the previous 6.2 release.
When reviewing field metrics, it is important to consider the following:
Field metrics are influenced by a myriad of factors, for example the active plugins and theme, the WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. version, the hosting stack, the browser(s) used by end users, their networknetwork(versus site, blog) connection, and more. So when comparing field data between two months, for example, it is impossible to limit the comparison to just one specific aspect of those.
Field metrics do not allow direct correlation between specific enhancements and their concrete metric impact. This is closely related to the previous point: Even if you compare the performance of a dataset of sites that enabled a specific feature before and after the change, for example, there may have been numerous other changes during that time that influence the data. Effectively, it is impossible to conduct clean A/B tests in the field.
Field metrics are more meaningful the larger the dataset is. Because of them being only indicators rather than “proof”, the larger the relevant dataset the more a specific metric observation from it can be trusted. It’s also worth considering that the web’s user base is incredibly diverse, so even the audience that a specific site has matters significantly for its field performance.
And yet, despite all these caveats, field metrics are the only way to validate how beneficial performance changes really are. If a performance “improvement” doesn’t impact real users, it effectively doesn’t matter even if it looked great in the lab.
CWV breakdown and assessment
For a brief recap on Core Web Vitals (CWV), they are a set of three specific metrics:
Each of these metrics has thresholds for whether a value is considered “good”, whether it “needs improvement” or whether it is “poor”.
This visualization shows the three CWV metrics and their thresholds.
These metrics can be captured for every single navigation / page load. A page load is then only considered to have “good” CWV if all three metrics show a “good” value. In other words, for a single navigation the CWV assessment is simply a binary metric of “good” or “not good”.
When looking at actual CWV datasets in the field, metrics are always aggregated, typically at the site / origin level. In other words, such an aggregation encompasses all navigations that happened on that site in a given time frame. In that dimension, the CWV assessment is considered “good” if 75% or more of the navigations have a “good” CWV assessment.
Last but not least, CWV can also be assessed at a larger scale, for example across all sites using a specific technology, like WordPress. In that scenario, CWV are typically measured through a “passing rate” which describes the percentage of sites that have a “good” CWV assessment. For example, if in a dataset of 1 million sites 200,000 of them have a “good” CWV assessment, the resulting passing rate is 20%.
Note that not only the overarching CWV passing rate can be measured, but also the passing rates for the individual metrics (LCP, FID, CLS and others). The CWV passing rate is however the most meaningful single metric as it is a summary of all of them.
But now let’s take a look at the data. Note: All metrics highlighted in this post are CrUX passing rates from the field, based on year-over-year comparisons between October 2023 and October 2022 (unless otherwise indicated).
WordPress CWV in 2023
As already mentioned in the “TL;DR” at the beginning of this post, CWV for WordPress have improved significantly this year:
Mobile CWV passing rate improved 8.13% (from 28.31% to 36.44%).
Desktop CWV passing rate improved 8.25% (from 32.55% to 40.80%).
While at first glance ~8% may not sound like much, it is a quite substantial boost to the passing rates, particularly when considering their base values. Relatively speaking, the new passing rate is ~29% higher than the old one on mobile and ~25% higher on desktop.
For reference: The previous year’s improvement for CWV passing rate was 6.99% on mobile and 6.25% for desktop. So while WordPress already did a great job in the previous year, this year even exceeded those accomplishments.
This chart shows WordPress’s mobile CWV passing rate throughout the year. Note that the decline between March and April is not a result of a WordPress-specific problem (or any performance issue at all), but rather due to a change in how the LCP metric is being calculated, which was rolled out in that month.
Let’s take a closer look at the individual metrics that make up CWV and how they changed this year. For simplicity, only the mobile numbers are shown below. They are slightly more important than desktop results since mobile traffic overall is higher than desktop traffic. More importantly, performance improvements carry more importance for mobile devices as they are typically less powerful and are subject to worse network conditions. It is also worth noting that the corresponding desktop numbers don’t show any notable differences in trend.
Mobile LCP passing rate improved 8.89% (from 34.48% to 43.37%).
Mobile CLS passing rate improved 4.22% (from 74.76% to 78.98%).
Mobile FID passing rate improved 0.87% (from 96.55% to 97.42%).
As you can see, LCP saw by far the largest boost. This is an excellent outcome, as improving LCP was the main focus for the WordPress performance team this year. The rationale behind this may also be obvious when looking at the base values: The LCP passing rate of WordPress sites is the lowest performing metric, so it deserves the most attention. On the flip side, even though FID only improved by less than 1%, that is perfectly fine given its passing rate is already so high.
Based on these metrics, it can furthermore be concluded that LCP was the primary driver behind the overall CWV passing rate improvements, which confirms the focus on this metric has made sense.
Last but not least, the Time to First Byte (TTFB) passing rate should be highlighted as well: While TTFB is not a Core Web Vitals metric, it is a direct part of LCP (specifically denoting its server-side load time performance portion), and it was another partial focus this year both because of its impact on LCP and because its passing rate is very low. Here is how it improved this year:
Mobile TTFB passing rate improved 3.10% (from 18.67% to 21.77%).
Desktop TTFB passing rate improved 3.53% (from 28.44% to 31.97%).
WordPress 2023 releases impact
This section focuses on the load time performance impact of the three new WordPress versions released this year, 6.2, 6.3, and 6.4. Since the focus for all of these releases was load time performance, it is sufficient to focus solely on LCP and TTFB.
While the overarching WordPress metrics from the previous section were based on a broad year-over-year comparison, the metrics to assess the release impact were queried with a more granular approach: For each WordPress version, a dataset was established between two months based on only the intersection of sites that were on the previous WordPress version in the first month and on the newer WordPress version in the second month. The months were then chosen in a way to maximize the size of the dataset (e.g. a WordPress version always sees the highest usage in the month before the subsequent version is released).
While that approach is still by no means an A/B comparison, it eliminates at least a good portion of noise e.g. from sites on other WordPress versions or sites that newly entered or dropped out of the dataset.
WordPress 6.2 LCP and TTFB
All metric comparisons are based on the intersection of WordPress 6.1 sites in March and WordPress 6.2 sites in July. See relevant WordPress 6.2 slide.
Mobile LCP passing rate improved 0.01% (from 34.98% to 34.99%).
Mobile TTFB passing rate improved 0.65% (from 18.47% to 19.12%).
Desktop LCP passing rate improved 2.13% (from 46.85% to 48.98%).
Desktop TTFB passing rate improved 3.89% (from 25.79% to 29.68%).
WordPress 6.3 LCP and TTFB
All metric comparisons are based on the intersection of WordPress 6.2 sites in July and WordPress 6.3 sites in October. See relevant WordPress 6.3 slide.
Mobile LCP passing rate improved 4.72% (from 34.46% to 39.18%).
Mobile TTFB passing rate improved 0.78% (from 18.78% to 19.56%).
Desktop LCP passing rate improved 1.96% (from 48.55% to 50.51%).
Desktop TTFB passing rate decreased 2.15% (from 29.28% to 27.13%).
WordPress 6.4 LCP and TTFB
All metric comparisons are based on the intersection of WordPress 6.3 sites in October and WordPress 6.4 sites in November (since newer data is not available yet). See relevant WordPress 6.4 slide.
Mobile LCP passing rate improved 0.30% (from 37.40% to 37.70%)
Mobile TTFB passing rate improved 0.11% (from 18.21% to 18.32%).
Desktop LCP passing rate improved 0.13% (from 49.46% to 49.59%).
Desktop TTFB passing rate decreased 0.31% (from 25.88% to 25.57%).
Remember that all of the above metrics are just indicators and an approximation of the field impact of those releases, influenced by several factors. It’s also great to keep in mind that the adoption of those versions will continue to grow. For example, as of November ~68% of all WordPress sites were using version 6.2 or newer based on the dataset. As the adoption increases further, the performance wins from those releases will continue to scale horizontally and benefit more sites.
WordPress 2023 impact on the web
WordPress, with its high usage, has a large footprint on the web, making a significant impact on the entire internet. When WordPress performance improves, the web’s performance improves. Therefore, last but not least, let’s look at the performance impact that WordPress has had on the web overall.
A good starting point for that is to compare the 2023 CWV passing rate improvement of all WordPress sites with that of all sites not using WordPress:
As mentioned before, WordPress’s mobile CWV passing rate improved 8.13%.
The non-WordPress mobile CWV passing rate improved by 3.68%.
The non-WordPress desktop CWV passing rate improved by 5.29%.
From those numbers alone, it is clear that WordPress has made notably more progress in performance than the rest of the web, which is an amazing achievement.
It is furthermore possible to draw some conclusions on how much WordPress’s impact on the overall web’s improvements are. For reference, the overall web’s CWV passing rate improved 5.35% on mobile and 6.26% on desktop. Based on that, a simple calculation can be used, subtracting the non-WordPress CWV passing rate improvement from that of the entire web. This leads to the following results:
1.67% of the overall web’s mobile CWV improvement of 5.35% comes directly from WordPress.
0.97% of the overall web’s desktop CWV improvement of 6.26% comes directly from WordPress.
While those numbers may seem small, this is literally WordPress’s impact on CWV for the entire web! It is an excellent reminder of how important WordPress’s role is for the web and how contributing to WordPress not only improves the WordPress ecosystem but also the entire web.
Considerations for 2024
With this recap of the 2023 CWV impact of WordPress, it is time to look ahead and plan for 2024. In particular there are two important considerations for the performance focus next year.
INP replaces FID as a Core Web Vitals metric
Earlier this year, a notable change to the CWV metrics was announced: The more recently introduced metric Interaction to Next Paint (INP) will replace First Input Delay (FID) in early 2024. Please refer to the linked articles for additional information on the metric and that change. The very short summary is that INP measures interactivity more accurately than FID, and due to its limitations FID ended up having very high passing rates throughout the web ecosystem – almost perfect as seen in the WordPress numbers before.
This visualization shows the new INP metric and its thresholds.
Since INP measures interactivity more comprehensively than FID, it implies that passing the INP assessment is more difficult than passing the FID assessment. In other words, the INP passing rate is expected to be lower than the FID passing rate. Once INP is taken into account for CWV instead of FID, this will therefore lead to a decline in the overall CWV passing rate as well. In reality, the difference is particularly relevant on mobile devices. Here is a comparison of the FID passing rate and INP passing rate of WordPress sites, based on October 2023:
Mobile FID passing rate is 97.42%, while mobile INP passing rate is 71.48%.
Desktop FID passing rate is 99.97%, while desktop INP passing rate is 98.47%.
While there is a small decline on desktop, it isn’t really worth focusing on as the value is still extremely good. But for mobile, the decline is significant. In other words, it will be important in 2024 to find ways in which WordPress can improve INP passing rates on mobile, in order to make up for the loss compared to FID.
Of course this is not only relevant for WordPress, but for the entire web. Here is how the mobile CWV passing rate would change if INP was already replacing FID today (data based on October 2023):
WordPress’s mobile CWV passing rate would be 3.64% lower (32.80% instead of 36.44%).
The non-WordPress mobile CWV passing rate would be 7.39% lower (40.58% instead of 48.02%).
Based on these numbers, it is at least a little comforting that WordPress will struggle with this change less than the rest of the web. Nevertheless, 3.64% CWV passing rate decline is a significant drop, so part of next year’s performance goals will be to make up for that loss, likely through a combination of INP focused improvements and a continuation of the LCP focused efforts.
TTFB focus was less impactful than (client-side) LCP focus
The second consideration for 2024 is not related to a metric change, but rather a potential takeaway from the 2023 metrics highlighted in this post: When looking at the WordPress release specific impact, it can be noted that the mobile LCP improvement was by far the highest in the 6.3 release (4.72%, compared to <1% for 6.2 and 6.4).
The WordPress 6.3 release included a number of client-side LCP enhancements, which likely led to a large chunk of those improvements, as more granularly indicated by the findings from the related field analysis from a few months ago. WordPress 6.4 and especially WordPress 6.2 were more focused on server-side LCP enhancements (i.e. TTFB enhancements), and based on the field results those releases did not lead to as large LCP wins. Even for TTFB, the picture isn’t entirely clear: As expected, WordPress 6.2 has a much better TTFB win than 6.3 on desktop, but on mobile devices the two releases show almost equal TTFB wins, with 6.3 even slightly higher.
While those numbers are by no means evidence, they raise the question whether the TTFB focus in WordPress core is the right way to move the needle for load time performance. Potentially the influence of other factors outside of WordPress core on TTFB, such as plugins, themes, hosting stack, or network connection, are just too large for the core-specific server-side improvements to make an impact in the field.
This does not imply the TTFB efforts should be dropped – but likely a shift is needed. Potentially, the TTFB issues need to be addressed through other means than directly enhancing the server response time of WordPress core itself. Further research should likely be conducted to get a better understanding of how much WordPress’s low TTFB passing rate stems from the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party ecosystem’s performance or other aspects not directly code-related such as hosting.
2024 planning is underway
The WordPress performance team is currently working on their roadmap for 2024. A GitHub issue for performance focused project proposals has been opened and awaiting input. You’re invited to contribute any WordPress performance related proposals or ideas you may have on that issue.
While the 2024 roadmap is currently being planned, let’s once again circle back to 2023: The amazing metrics shared here speak for themselves. Thank you to everyone who contributed to WordPress’s incredible performance impact in 2023!
This post summarizes the feedback received from the WordPress 6.4 retrospective. Thank you to those who contributed their feedback via the retrospective survey and comments on the post. For ease of reading, feedback has been synthesized. Full feedback is available for review in the anonymized form responses and comments to the original post.
Please remember that the following feedback are suggestions to bear in mind for future releases rather than action items for implementation.
What would you keep?
The Community needs/“wishlist.”
Blogblog(versus network, site) post per new feature or major change, e.g., performance improvements or the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Tag processor.
Release team formation and announcement during the previous release cycle for easy coordination.
Having a co-lead per release focus to allow for complimentary time-zone coverage.
Weekly health checks.
What would you add?
Additional minor releases between majors.
Iteration on Twenty Twenty-Four for Twenty Twenty-Five to reduce fragmentation.
Earlier merging of stable GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ features into WordPress trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..
Equal focus on old tickets and bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes with new features.
Feature the Pattern Directory in the BlockBlockBlock 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. Editor.
A dedicated session in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for testing the release.
A focus on cohort involvement for sustained contribution beyond a major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.’s development cycle.
More underrepresented release squads and opportunities for synchronous meetings in different time zones.
What would you remove?
Underrepresented release squads.
Minimum Core code contribution for Editor Tech role.
Increased documentation and training for new contributors to the release process.
Allow only “blessed tasks,” with enhancements/features that have received a first commit before BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 to continue to Beta 2 et al.
How did the collaboration feel?
This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.
Would you like to be part of future release squads?
16.7%: I haven’t been part of the squad but I would like to try in the future.
8.3%: I have been part of a release squad and I will gladly repeat.
41.5%: I have been part of a release squad before and will do so again, although maybe not next year.
8.3%: I am reluctant to participate again, but I would be open to it if responsibilities and processes were clearer.
8.3%: Maybe later, I’m not sufficiently experienced yet.
8.3%: I have been part of a release squad and would like to repeat, but unfortunately I don’t have the time for near/midterm future.
Takeaways and next steps
Respondents felt that following the development cycle as a new contributor was challenging.
Future WordPress Contributor Mentorship programs will mirror major releases so new contributors have mentored experience with ample documentation and support to find contribution onboarding opportunities.
The shorter development cycle, while previously requested, felt too short for ample feature development and testing.
6.4 was, for all intents and purposes, a success in bringing underrepresented gender voices, skill sets, and points of view into WordPress’s development cycle. 2024 will not include specific release squads to allow for more broad contributor involvement.
Maintenance will be one focus alongside new features for the WordPress 6.6 release in response to a call for more maintenance in major releases.
Congratulations to all who helped make WordPress 6.4 available! Now that it has been successfully released, I invite all who contributed to reflect and share our thoughts on the release process to learn, iterate, and improve for future releases.
Anyone is welcome to participate in this retrospective, so please take a few moments to complete the form or leave public feedback in the comments below. The survey is not anonymous, allowing for outreach should further clarification be needed; please note that your email address will not be shared or used for any other purpose.
The form and comments will be open until November 30th, 2023, with anonymized results available in a follow-up post in December 2023.
Again, thank you for your contributions to 6.4 “Shirley,” and for taking the time to help make future releases even better!
Based on lab benchmarks, WordPress 6.2 loads 14-18% faster overall for blockBlockBlock 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 2-5% faster overall for classic themes (measured via Largest Contentful Paint / LCP). Particularly server-side performance (measured via Time to First Byte / TTFB) is seeing a major boost of 17-23% for block themes and 3-5% for classic themes, which directly contributes to the overall load time.
This post provides more information and a retrospective on how those performance wins were achieved in the WordPress 6.2 release cycle.
Learning from previous WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. releases
During the betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). testing phase of WordPress 6.1 in November 2022, it became evident that a few notable performance regressions had made it into the release when compared to the performance of WordPress 6.0. While the single most impactful performance regressionregressionA software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. was addressed before the 6.1 stable release in one of its release candidates, overall performance still regressed slightly when using a block theme. Previous WordPress core releases, especially 6.0, saw more notable performance regressions. Despite other performance enhancements landing in those releases, the regressions effectively ended up canceling out the enhancements. In WordPress 6.2, this is significantly different, with all key metrics improving over the previous release, as highlighted in these performance benchmarks shared by @oandregal.
For WordPress 6.1, the regressions were discussed in a general assessment of WordPress 6.1 RC performance. Despite contributors from different core teams quickly prioritizing and investigating the issues, it was too late in the release cycle to address them all. This was a great learning experience: As much as we are working on performance enhancements, it is as important to continuously monitor performance of existing core features to avoid regressions. The more regressions there are, the less impactful any other performance enhancements are overall. While this seems logical and simple, it sometimes still takes an actual learning experience to get things right.
It is great to see that we have put these learnings into practice, and the performance wins in WordPress 6.2 demonstrate that. So what changed in the 6.2 release cycle?
Increased focus on performance measurement
When trying to summarize how performance work changed between the 6.1 and the 6.2 cycle in a single word, an increased focus on measurement proved to be the deciding factor. The following elaborates on the nuance of that simplified statement.
Identifying performance bottlenecks and opportunities for improvement
It was clearly visible that contributors were keen to rectify the 6.1 regressions and learn from that prior release. This already surfaced in the WordPress 6.1.1 follow up release which contained a few performance-related fixes: 12 of 30 tickets fixed in that release were focused on performance.
Numerous contributors from different core teams actively worked towards identifying and addressing performance bottlenecks, by both benchmarking and profiling WordPress core performance.
Profiling WordPress core has been tremendously helpful in identifying performance issues on the server-side, which has led to the notably improved TTFB performance we are seeing in WordPress 6.2. Common tools used for server-side profiling among contributors have been the open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. tools Xdebug and XHProf and the SaaS tool Blackfire. Contributors have been starting to define and document standardized ways for using these tools, which are intended to be published in the Make Performance Handbook soon.
For benchmarking WordPress core on the other hand, there was less clarity or known tools that could be used as is. While contributors initially came up with individual tooling of their choice to measure performance, the different benchmarking approaches had varying degrees of accuracy and ease of use, so it soon became clear that a more consistent approach would be needed. This was one of the key topics discussed in the first performance focused hallway hangout in January. From there, several contributors started more coordinated efforts for measuring performance, for both manual benchmarks locally and automated benchmarks via continuous integration.
The Performance Lead role
Another change that was made for the WordPress 6.2 cycle which has been supporting everything I have mentioned so far is the introduction of a new Performance Lead role as part of the release squad. This came as a result of the aforementioned performance focused hallway hangout, and I ended up stepping into this role for the 6.2 release. This enabled me to closely collaborate and support the other contributors and coordinate with them our performance measurement approaches. As mentioned before, I would like to emphasize that the performance wins in this release are a result of excellent work from several contributors on identifying performance weaknesses. The introduction of the Performance Lead role then merely brought a better representation of performance alongside the other members of the release squad.
I hope the role of the Performance Lead is here to stay, and I am excited to see additional contributors step into this role in the future.
Assessing performance on individual WordPress core patches / pull requests
As mentioned before, profiling is the recommended approach to identify performance bottlenecks in WordPress core. However, once a pull request with a potential fix is implemented, it is also crucial to measure the actual performance impact and through that validate whether the outcome is as expected. While profiling gives us an idea about the potential performance impact, it comes with caveats such as the overhead of the profiling tools running on the WordPress site, and also that it only captures a single request, which as mentioned above is subject to a good degree of variance when it comes to performance.
Various contributors in the WordPress 6.2 cycle benchmarked performance on individual pull requests, whether to prove a positive impact or performance or ensure that no regression is introduced. Different tools were used to assess the impact, often CLICLICommand Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. commands like “benchmark-server-timing” or “benchmark-web-vitals”. The “benchmark-server-timing” command has been most helpful for individual PRs with server-side performance impact, for example it was used in the #57502ticketticketCreated for both bug reports and feature development on the bug tracker. (see this comment), which is possibly the largest single performance enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. in the 6.2 release. The “benchmark-web-vitals” command however has still been useful for a few situations where performance decisions came down to exclusively client-side performance, for example in the #56990 ticket (see this comment), which explores the classic-themes.css performance impact.
Launching an automated performance testing workflow
In the WordPress 6.2 cycle, most of these benchmarks were conducted manually, which sometimes is a necessity due to the nature of the pull request, but other times is rather inefficient. Furthermore, it would not be feasible to benchmark performance manually for every WordPress core change – and that is precisely how a performance regression may be merged unnoticed. Several contributors have been collaborating on introducing an automated performance measuring CI workflow to WordPress core, and a first MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia was committed to WordPress core in [55459]. With this CI workflow, WordPress core performance metrics are now recorded for every single commit and are available in this dashboard. This allows us to easily spot a potential regression where previously it would have gone unnoticed. While at this point, there is still a sizable amount of variance in the data points and a limited number of metrics are available, the team will iterate in the coming weeks and months. This is only the starting point, and additional features like CWV support are already being planned. Needless to say, this is a major milestone and win for monitoring performance in WordPress core and will reduce some of the measuring workload already for the upcoming 6.3 cycle.
Assessing performance of WordPress core holistically
While assessing performance on every individual WordPress core change (pull request / commit) is very important to ensure continuous monitoring of performance and avoid regressions, it is also important to keep track of overall performance in WordPress core. This is particularly true during the Beta and RC stages of a release cycle.
At this point in particular, it is advisable to use the production ZIP version of WordPress core (e.g. a particular Beta or RC release) instead of measuring in the WordPress core development environment. The “benchmark-web-vitals” command mentioned in the previous section is perfect for this use-case, as it provides high-level performance metrics that capture both server-side and client-side performance. The resulting data can then be compared with the same metrics from e.g. the previous stable release, to get an idea how performance of WordPress core has changed (hopefully improved!) in the new release. This approach is what the numbers I shared in the beginning of this post are based on.
Performance benchmarks for WordPress 6.2
I would like to share a few more detailed numbers for the WordPress 6.2 performance improvements. Generally, I have been benchmarking two different scenarios, which showcase particularly the server-side performance enhancements (with #57502 contributing the most to them):
Home page using a block theme (Twenty Twenty-Three) with the default content (“Hello World!” post)
Home page using a classic theme (Twenty Twenty-One) with the default content (“Hello World!” post)
Since WordPress 6.2 included one notable client-side performance enhancement that affects only sites using images (see #56930), I included two more scenarios to assess that impact too:
Home page using a block theme (Twenty Twenty-Three) with the default content (“Hello World!” post) and a featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. on that post
Home page using a classic theme (Twenty Twenty-One) with the default content (“Hello World!” post) and a featured image on that post
For all of these scenarios, I then loaded the URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org 20 times using the “benchmark-web-vitals” command and recorded the metrics. The full metrics include more granular percentiles, but by far the most important ones are the medians (p50). Here is the data for the two scenarios with only the default “Hello world!” post (no featured image):
Scenario
Metric
WP 6.1.1 median
WP 6.2 median
Diff %
Block Theme: Twenty Twenty-Three
LCP
281.7ms
241.15ms
-14.39%
TTFB
176.75ms
137.8ms
-22.04%
Classic Theme: Twenty Twenty-One
LCP
209.65ms
203.65ms
-2.86%
TTFB
75.3ms
72.6ms
-3.59%
For comparison, here is the same data for the two alternative scenarios where the post has a featured image. Note how the LCP improvement for block themes is even more pronounced in this scenario:
To close this section, it should be noted that of course the 4 scenarios above are not representative of what most actual WordPress sites look like. Some other benchmarks were using the theme unit testunit testCode written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. data, and while that is more content, it is not necessarily more accurate either. There are inevitably limitations from lab analyses, and we will never be able to capture the “average” or “realistic” WordPress site synthetically. However, the Core Performance Team is exploring a few good baseline scenarios as part of enhancing the aforementioned automated core performance testing CI workflow, and it would be great if in the 6.3 cycle we could align the benchmarks to use similar scenarios rather than every contributor including myself having their own scenarios for benchmarking.
For some of the individual ticket highlights that contributed to the performance improvements in WordPress 6.2, please see the recent core editor improvements post.
Comparing performance between block themes and classic themes
You may have noticed in the data above that the classic theme is apparently loading faster than the block theme. Let me clarify that a bit since, while that is technically true based on my benchmarks, the data may be deceiving at first glance.
Let’s take another look at the data from the first table above: For the LCP metric, the classic theme already loads notably faster (203.65ms vs 241.15ms, based on the first two scenarios for WordPress 6.2), but for TTFB, it’s almost twice as fast (72.6ms vs 137.8ms). Server-side performance is better in classic themes mainly because block themes have to handle more data since much of what a classic theme’s code is responsible for is now handled through more dynamic features that furthermore rely on making additional database queries. However, it also needs to be acknowledged that block theme support in WordPress core is still relatively new (little more than 1 year old now), while the logic for classic themes has seen more than a decade of refinements. In other words, chances are there is still a lot of headroom for improving server-side performance of block themes, while for classic themes there is probably less of that. The performance improvements in WordPress 6.2 perfectly indicate that, noting that TTFB with a block theme has improved far more than TTFB with a classic theme.
Now here comes the most important part though: In client-side performance, block themes are much faster than classic themes. The way to spot that is by looking at the difference between the LCP metric and the TTFB metric, and here’s why: LCP can be considered representative of the overall load time, while TTFB is the server response time. So “LCP minus TTFB” is representative of the client-side load time. If you make this calculation for the above data points for WordPress 6.2, you can clearly see the benefits of the block theme when it comes to client-side performance (103.35ms vs 131.05ms). These benefits are evident due to the more dynamic logic that is applied in block themes to e.g. load scripts and stylesheets. Rather than the common pattern of enqueuing a big stylesheet and big script in the theme, block themes load assets more granularly and dynamically, only for what is actually needed on the current page.
You may argue that it doesn’t matter that client-side performance is ~30ms faster in a block theme if at the same time server-side performance is ~65ms slower. Yes, in this benchmark the classic theme is overall ~35ms faster than the block theme – however that is without any caching. It is a common best practice for WordPress sites to use a full page cache to avoid the need for all the WordPress server-side logic to run on every page load or, even better, to avoid the request to hit the WordPress site at all in favor of serving a cached response. While by far not all WordPress sites use a full page cache, many do. And in that case, the server-side performance becomes potentially less relevant. Keep in mind however that even then improving server-side performance is still important: As mentioned, many sites still do not use a full page cache, and even for those that do, certain dynamic content is almost impossible to reliably cache. However, if your WordPress site uses primarily static content and a full page cache, block themes are already faster than classic themes today – because they are faster client-side. You can “cache” away server-side performance problems, but you cannot do that on the client-side. In other words: Despite block themes being slower on the server-side, they provide a better foundation for building performant sites in the long run.
Appendix: Tools to measure and profile performance
To finish this post, here you find a list of links to some of the tools mentioned:
With WordPress 6.2 released and available to the world, it would be very helpful to this and future release squads if all those who contributed could take the time to reflect and share thoughts on the release process to learn, iterate, and make future releases smoother. ✨
Anyone is welcome to participate in this retro, so please take a few moments to complete the form or leave public feedback in the comments below. The survey is not anonymous, allowing for outreach should further clarification be needed; please note that your email address will not be shared or used for any other purpose.
The form and comments will be open until April 30th, 2023, with anonymized results available in a follow-up post in May 2023.
Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!
Props to @cbringmann, @chanthaboune for the peer review
This post summarizes the feedback received from the WordPress 6.1 retrospective. Due to an error in the form linked in the original retrospective post, the results of the retrospective are shared later than anticipated, and your patience is appreciated.
Thank you to the people who took the time to share their feedback and those who did so publicly on the post itself. To keep this post succinct, some feedback has been consolidated; you can check the anonymized form responses and the comments section in the retrospective announcement for the full feedback.
Please remember that these are just suggestions and things to consider for the future rather than items that will be implemented later.
Weeklies, bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, and editor PR triages.
Having several Editor-related leads.
Focusing on non-editor areas like performance, accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), and developer experience.
The release cycle length, as opposed to the original shorter one proposed.
The product walkthrough continues to be a valued addition.
The less “strict” process than previous releases allowed contributors to work on many things they wouldn’t have had the opportunity to work on otherwise.
Collaboration across different teams seemed to work well.
What would you add?
More transparency in coordination, governance, and decision-making in public spaces.
Improving and automating the backporting of editor features to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
An earlier cut-off for new Editor features and Enhancements to prevent last-minute fixes due to unstable code from GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.
Backporting from Gutenberg in smaller chunks to reduce the effort necessary to find the exact cause of bugs due to the large, multi-commit PRs.
Requiring any new Editor code to first go through a public release in the Gutenberg pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party before being considered for merging into Core.
Requiring the use of the new “private exports” code for any “experimental” or “unstable” Editor APIs that are consumed by Core.
Making all the data from this Retrospective public.
A more complete and timely roadmap.
Attention to other non-Gutenberg components, and polishing the Gutenberg APIAPIAn 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..
A more effective way of gathering feedback than the retrospective form allows.
There were 3 RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). rushed in the last week of release, and the final RC 6 was released a day before the actual release date. The final RC was reverting some changes: in these cases, an extended code freeze would allow sufficient time for the themes and plugins to get their code compatible with WordPress.
An even bigger focus in the performance area.
More people doing code reviews.
Earlier ticketticketCreated for both bug reports and feature development on the bug tracker. scrubbing in the release build cycle to avoid delaying the release parties.
More folks to oversee the Editor tasks/PRs; Gutenberg is too big for even a group of 5-6 folks to oversee and catch every issue completely.
Considering National holidays in Major countries. The auto-update broke some of the sites that used specific plugins during a major EU holiday.
What would you remove?
Work done in non-public channels to avoid making non-sponsored contributors feeling not really valued.
The manual backportbackportA port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. process from Gutenberg to Core.
The “Walkthrough”.This started as a “Go, No-go” but failed at its designed purpose to provide a line in the sand for feature inclusion based on a thorough, early review session. This was changed to “Walkthrough” to make it seem like it wasn’t an absolute statement on what will or will not be included in the final release. However, this “Walkthrough” only increases the pressure on contributors to essentially “follow the roadmap” of what is expected by leadership after the Walkthrough is made public. Removing it would let contributors offer an unpressured evaluation of new features before release to determine if they are actually ready for inclusion.
Weekly check-ins.`@`ing every single person on the squad is helpful; a more generic `@channel` call asking for anyone with flags to raise them would be better.
The shift from summarizing updates in meetings to relying on dozens of async updates.
How did the collaboration feel?
This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.
Some takeaways and next steps
There were various recurring topics that have experienced changes in the WordPress 6.2 release cycle. Please make sure to add your updated feedback to the 6.2 retrospective!
Most respondents felt the process was not transparent enough, with many decisions being made in private spaces.
The WordPress 6.2 release squad has made an effort to bring as many conversations as possible to the #6-2-release-leads Slack channel.
There are discrepancies around the usefulness of the walkthrough, especially its purpose.
Inefficient weekly check-ins with the release squad.
Based on this early feedback, the 6.2 release cycle saw a shift: release coordinators didn’t pingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” individual release leads, and limited to listing the release areas during check-ins.
A more effective way of gathering feedback than the retrospective form allows.
Although there is no indication of what a more effective way of gathering feedback would look like, the 6.2 retrospective includes more open-ended questions.
Requiring the use of the new “private exports” code for any “experimental” or “unstable”.
Thanks to Private and Plugin-only APIs, Experimental APIs in WordPress core have largely been tamed. A follow-up post on this topic will be published here in make/core next week. Stay tuned! EDIT April 17th: the post is live now.
Making all the data from this Retrospective public.
As commented at the intro of this post, here it is 🙂
With WordPress 6.1 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our thoughts on the release process to learn, iterate, and make future releases smoother. ✨
Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.
The form and comments will be open until December 15th, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog(versus network, site) in January 2023.
Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!
This post seeks to summarize the feedback received from the 6.0 retrospective, shared on May 27th. Thank you to the eight people who took the time to share their feedback and to those who also did so publicly on the post itself. To keep the post succinct, some non-actionable feedback has been consolidated.
Please keep in mind that these are just suggestions and things to consider for the future rather than items that will be implemented later.
What would you keep?
Outside of the following, there were repeat mentions of how collaborative, kind, and communicative the squad was as a whole in answering pings, making decisions, and supporting each other.
Early sharing of the feature highlight grid to influence About page, release video, etc.
Weekly check-ins.
Dedicated release channel for coordination.
Redundancy with co-leads in various roles to allow for more focus on details, higher capacity for work, etc.
Lack of heroic efforts and last-minute dashes
Collaborative decision making, e.g. with regard to the WebFonts APIAPIAn 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.
Structured release parties
What would you add?
More support for Docs & Training resources, matching devs that worked on issues with those writing docs/training.
Clearer documentation around resolving tricky issues during a release and when to bring leadership in.
Consider having apprenticeship roles for release squad roles to create a backup and for the continuity of the project.
A reimagined About page that designers can build directly using blocks.
Improved automations, specifically for the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Lead role.
Release squad should be picked as early in the release process as possible to allow time to prepare.
Consider adding documentation lead role for End User documentation
Improve process for identifying items that need dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., including labeling of PRs that need dev notes, considering multiple types of flags (DevNotedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. / MiscDevNote / Field guideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.), ensuring documentation is in place for what needs dev notes, and implementing automation to collect all items.
Checklist for each member of the squad at each release phase for improved coordination.
What would you remove?
Confusion/concerns around the Webfonts API situation.
Confusion around the initial betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 post and what role everyone played. This was very quickly resolved.
Backporting months worth of GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher changes before the release.
Lack of decisions and process around stabilizing and introducing experimental APIs, leading to a backlog.
Improving the process of introducing, stabilizing, and phasing.
Secrecy around jazzer leading to a lot of complexity around release time.
Too many places for tracking documentation updates from the docs team.
Complicated process for dev notes, including recommendations to stop using comments on the GitHubGitHubGitHub 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/ DevNote tracking issue for collecting all dev notes and change deadline to Beta 1 to give docs team more time.
Implementing a feature freeze in Gutenberg a week earlier to leave more room for integration with WordPress Core and reduce the length of beta releases.
Share more marcoms around the behind the scenes work with performance and accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) so the UIUIUser interface changes aren’t over indexed on messaging wise.
How did the collaboration feel?
This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.
Collaborating on this release was easy results
Collaborating on this release was enjoyable results
Collaborating on this release was efficient results
Collaborating on this release was well organized results
The release process was transparent and easy to follow
Would you like to be a part of future squads?
87.5% of people said “I have been part of the release squad and I will gladly repeat”. 12.5% of people said “I haven’t been part of the squad but I would like to try in the future”.
Next Steps
At a high level, a few discussions and follows up have already occurred that others can participate in:
A follow up post was done since the retrospective sharing improvements and automations for the Core Editor release role in light of the experience of those this release cycle.
An open discussion is underway around how best to backportbackportA port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. PHP changes.
Outside of the above, it’s clear that there are some process improvements particularly around documentation to consider including a role for End User documentation, changing the way documentation updates are tracked across multiple places, and the way in which dev notes are wrangled.
If you are interested in being a part of 6.1’s release squad and working to improve the experience, please share in the comments of the 6.1 planning post.
With WordPress 6.0 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our thoughts on the release process to learn, iterate, and make future releases smoother. ✨
Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.
To accommodate for WCEU2022 taking place next week, the form and comments will be open until June 19, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog(versus network, site) in late June 2022.
Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!
You must be logged in to post a comment.