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 our bug tracker.
Following up on the prior hallway hangout on Performance Considerations for Block Themes, @flixos90 and I are running an additional one on performance improvements in WordPress 6.2. @flixos90 is the performance lead for the WordPress 6.2 release (a new role!) and this is a chance to get a more behind the scenes look at what’s to come.
At a high level, we’ll go through quick intros (what each person does/focuses on) and what performance work has been done with WordPress 6.2, with a likely specific focus on enhancements to theme.json. Ultimately, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to discuss.
6.2 improves performance, in particular 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.
Block themes are still slower with server response time than Classic themes due to higher configurability. Based on how block themes work they allow us to do more for client side performance than Classic themes.
Testing environments can be quite different, making it hard to replicate at times and important for folks to run across different environments before coming together to cross compare.
Performance regressions seem to be caused by a build up of PRs causing minor changes rather than a few PRs. On the flip side, object cache improvements are responsible for most of the improvements though.
Some regressions are quite minor, a few ms, and it’s important to contextualize percentage changes with that in mind.
There’s a sense that there’s an opportunity with newer mechanisms, like theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., to bring bigger improvements in performance.
Education for developers is needed from a few angles: documentation, learn WP content, developer tools, automated testing.
We need to differentiate between consistency and variance coverage when it comes to performance testing. Start small and expand.
Consistency is critical to have when doing these tests. No matter how good this work gets, there will always be some variance in performance results and an inability to cover all of the real world cases.
Overview of performance lead role
Came about as part of the last hallway hangout and is a new role for the 6.2 cycle, requiring some level of creating a new path.
@flixos90 has taken on this role and shared about his experience thus far.
Responsibilities include: Prioritize performance enhancements, catch performance regressions and collaborate with relevant teams on fixing them, keep track of overall load time performance of WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for the release.
More specifically, this work includes periodically reviewing tickets with performance focus keyword, assessing performance of different PRs, and conduct overall performance analysis of 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. / 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). to identify notable wins and regressions. This latter task can hopefully become a lot simpler in the future, by relying on the automated core testing environment.
In the future, this role could expand for 6.3 to include general profiling to proactively identify bottlenecks to focus on.
6.2 Improvements
There’s been amazing work done to improve performance with block themes in particular for 6.2
@spacedmonkey brought up though that the numbers for block themes still aren’t comparable to classic themes. Block themes are 2-3x slower.
It’s going to be difficult to keep the same level of performance with a classic theme because a block theme does more stuff to generate that page.
While the block themes have a slower server response time, it’s in part due to configurability which is higher.
Based on how block themes work they allow us to do more for client side performance than classic themes. Haven’t measured how much that offsets negative server side impact.
Cause of regressions
Lots of little things causing regressions rather than one main PR, making it hard to address at times. On the flip side, the object cache work is responsible for most of the improvements though for 6.2.
Should we prioritize small fixes too rather than really big? We could prioritize smaller items and do lightning rounds of PRs. Little tweaks do add up but we also do not want to get in the way of development.
In systems that are newer, like theme.json, @oandregal believes that there’s more space to improve things. For example, with theme.json caching the settings was obvious in retrospect. However, you don’t always anticipate how the call you write will be used. It’s likely that the newer systems will have bigger spaces for improving and other ones will be more like little tweaks.
More developer education
@spacedmonkey spoke about how he wants to see more developer education done.
Helping folks write performant code or learn to use query monitor could help the entire ecosystem improve.
There’s an opportunity to bake this into Learn WP work too cc @psykro for consideration (gave you a shout out in the call).
It’s critical to not just ship these improvements but to publicize them and get the word out.
If we start to notice consistent code patterns where people are repeatedly using certain functions in certain ways that could be optimized, we could work with other Make Teams to help reinforce best practices.
@tweetythierry brought up if there was more that could be done on the developer tools level, especially for core developers.
Automated testing, testing environments, and variance vs consistency
Don’t want an automated suite to dampen running our own tests and tweaking things.
Even small changes, like using a localeLocaleA locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. or loading 30 posts rather than 10, can make a big difference.
It’s important to think about which environments we want to run tests in. A few sample environments – a little content, a lot of content, one without any language pack, one with a different locale, etc.
We can start small and expand as we will never be able to cover the real world. It’ll always be limited. Most important thing is that we test across consistent environments. No matter how good we make this, there will always be some variance in performance results.
@tweetythierry brought up the need to differentiate between consistency and variance coverage. With automated testing, important to have consistency in setup but we shouldn’t just rely on one set of configuration forever. Should do it manually to increase variance coverage. It’s super important to have consistency though at the end of the day.
@spacedmonkey brought up wanting to profile in different languages since 58% of sites aren’t running in English. There’s a solid chance that there’s low hanging fruit on translated strings that could really add up for majority of sites.
Profilers and tooling
Discussed Blackfire accounts for core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. as there’s been conversations with them in the past. It’s not 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. though and couldn’t be used broadly for 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 and theme authors for example.
@spacedmonkey said to 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.” him if folks would like an account for testing and exploration.
This is another area that needs clear documentation on how to setup and what to use.
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/ measuring more frontend metrics
Currently, there aren’t many numbers yet for LCP since it just landed a few days ago.
Time to first byte doesn’t have much variance when comparing against something like typing that has a lot more variance.
With frontend measurements having less variance, it should be easier to find regressions since they are more stable than the others.
Thus far, not a ton of data but need to be mindful of the data because of the current setup. For example, we need the template we are using to use big images to spot other kinds of regressions.
@oandregal shared that there are some things this library does that the tests he implemented don’t do. Especially as we grow and add more metrics, it would help to go with a library.
As more is being done to work on performance as it relates to 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, a hallway hangout has been planned to bring together folks from various backgrounds to see what else can be worked on, unblocked, and better understood. This is meant to be both a knowledge sharing and alignment creating session between folks from various areas including but not limited to @flixos90@adamsilverstein@spacedmonkey@youknowriad@desrosj@tweetythierry@oandregal@aristath.
At a high level, we’ll go through general intros (what each person does/focuses on), current work underway to address performance, what work is being done specifically for block themes, and general open Q&A. Hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to demo/discuss.
There’s difficulty in this work partially due to how backports happen 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/ to CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. both for finding and fixing regressions.
There’s still a big need to have solid measurements and track them in some level of granularity for both Core and Gutenberg.
There’s great potential in Block theme performance because of how they are built to improve performance.
Some level of changes in performance is okay but we need to avoid major regressions and not let perfect get in the way of good enough.
A Performance role for the upcoming 6.2 release squad should be considered to improve coordination between various teams and focuses.
Theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. performance & avoiding major performance regressions with merging Gutenberg into Core
We kicked the call off discussing issues in 6.1 around caching data in theme.json, which led to a broader discussion around merging Gutenberg into Core in a way that avoids regressions.
Andre shared how performance is measured in Gutenberg (typing, time it takes to load a big post, etc) for each release. You can see the results of each test in the various release posts under “Performance Benchmark”.
Some performance concerns for 6.1 happened only via manual testing. How can we automatically find this rather than needing to manually manage much of this work?
Testing needs to happen both in Gutenberg and with Core.
It’s not always easy to spot performance concerns 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 for a variety of reasons:
How code is ported from Gutenberg to Core making it hard to track problems down with this example shared of the kind of large backports that happen.
Iteration happens much faster on the Gutenberg side than Core.
Inconsistencies in results depending on the tool used.
A question was raised around whether there is load time performance tracking on the front end for Gutenberg. This currently doesn’t exist but it was agreed that it should be explored.
Tonya shared how iteration happens much faster on the GB side with Core happening less frequently so when we think about performance, we want to think about strategies for how we can do it on a faster basis. Let’s not wait until we get into Core and let’s retest when it gets added to Core.
Tonya’s team is working on improving the backporting process with sooner and smaller backports to Core to get them in throughout the development cycle. If it’s ready, 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. it rather than waiting.
Part of this work is making sure Gutenberg back end code is Core ready (runs against same thing so when backports are ready to go, it’s Core ready).
Tonya is going to do a Make post to cover what her team is working on.
Jonny brought up confusion around where to make changes when performance concerns are found. This is a larger conversation and it was agreed to bring that discussion into a different space to preserve the conversation around performance.
Avoiding regressions in Classic themes & how performance is measured
Jonny is doing very manual testing to try to catch things as much as possible. Having automated tests would be huge along with being able to generate a spreadsheet comparing RCs, commits, etc.
Database queries are usually a sign that something is loading that shouldn’t be loaded. It’s not always obvious but it can act as an early warning sign that something isn’t working.
Joseph previously volunteered for the measurement side but got pulled into other things. It sounds like this is still a significant need to figure out, do measurements, and track them in some level of granularity (per day, per commit, per release) for both Core and the Gutenberg plugin.
Sergio shared more around the WordPress.comWordPress.comAn online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ side of things with lots of tooling being run tools for WordPress.com servers which wouldn’t apply well to this situation since they are not particularly suitable to ongoing development.
Felix discussed measuring server side performance by using server timing metrics to see how many ms certain processes take. In theory, you could have something that could receive server timing metrics.
The performance dashboard for Gutenberg was discussed as a spot to make more robust and port in more tracking: https://codehealth.vercel.app/
The general topic of how to measure PRs to reflect real improvements in production came up with Andre sharing how depending on the tool used there are wildly different responses in performance impact.
Jonny brought up how complex this can get when you add in object caching, PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions, etc. Any performance metrics would need to have a matrix of configurations to cover cases.
In general, need to also look at regressions individually because they might be different to a different degree depending on environment.
Adam ended this section of the conversation with a great reminder that some level of small changes in performance in normal but we need to avoid major regressions. Let’s not let perfect get in the way of good enough.
Core web vitals and block themes. What parts of Core can be improved out of the box? What are we doing specifically around block themes?
Jonny shared that because of theme.json, Block themes are slower than Classic themes with work underway for them to be on par with Classic themes. There’s an amazing opportunity to do performance work with Block themes because everything is a block. You could prefetch image assets, ensure images above the fold are loaded, etc once you know entire markup of page before headers are sent.
Discussed various ways enhancements could happen with script and resource loading (CSSCSSCascading Style Sheets. file loading, font loading, etc) as well as lazy loading things as well beyond just images (what about CSS?). For example, if a block is in the footer of the page, could load later on.
Thoughts around better ways teams can work together around improving block themes.
In particular, this refers to the Core Editor, Core, and the Performance teams since we’re all ultimately a part of broader WordPress efforts and we can use our unique expertise to be better together.
Discussed having another hallway hangout specific for WordPress 6.2 items to have more practical, hands on things to go through.
Anne threw out the idea of having a Performance related role for release squad and will follow up to more formerly propose.
Jonny brought up ensuring folks are giving the time to respond during releases and to 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.” early. At the same time, Tonya reminded us to avoid having bottlenecks and to practice reviewing something after it’s merged to still fix what’s found.
Next steps:
@hellofromtonya will share a Make post about the work her team is doing at Automattic around more continually backporting items from Gutenberg into Core.
@annezazu will suggest a performance role on release squad (with +1 from Tonya, Jonny, and Thierry).
@annezazu will follow up with a 6.2 related performance hallway hangout once 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 is released.
@adamsilverstein will share a Make post on an automated testing environment and possible steps there.
Serving as Editor Tech Co-leads for WordPress 6.0, @zieladam and @gziolo not only shipped our most polished version of 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 so far, but they also walked the extra mile to automate a lot of the legwork involved in the process 🎉
For WordPress 6.1, @czapla and @bernhard-reiter will be the Editor Tech Co-leads. Since it is a first for both of them, their predecessors have graciously agreed to walk them through the process.
As this knowledge might be valuable to others – especially future generations of Editor Tech Leads – @annezazu suggested turning this into a public Hallway Hangout that will be recorded and shared. Yours truly, serving as Co-release Coordinator in both 6.0 and 6.1, will join this merry band to facilitate.
In a nutshell, we will be covering the following topics from an Editor Tech Lead perspective:
Major versions vs. Minor versions
Minor version release process
Major version release process
If you’re interested in joining, the Hallway Hangout will happen on 2022-08-11 12:00; a Zoom link will be shared in the #core-editorSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel before starting. We’d be especially interested to hear from previous Editor Tech Leads about their experience and advice! However, everybody is welcome to join to get a glimpse of the ins and outs of the Editor Tech Lead role and, who knows, maybe volunteer in a future release squad !💥
The recorded session will be added to this post once it’s ready.
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.-based Navigation editor screen has been behind an “experimental” feature flag within the 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/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 for some time. The purpose of the call was to outline the work required in order to remove the “experimental” status from the screen in order that the editor is active by default in the Gutenberg plugin.
The team working on the feature feel this is valuable in order to increase the visibility of the feature and therefore improve the quantity of feedback we receive.
Meeting Recording
If you’d like to watch the full recording of the session you can do so below:
Key points agreed
It was agreed that the prerequisite for removing “experimental” was: UIUIUser interface/UXUXUser experience feature parity with the existing Navigation screen (nav-menus.php) in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
We also acknowledged that:
We wouldn’t commit to feature parity of developer focused APIs at this stage.
Removing “experimental” in the Gutenberg plugin, would not automatically make the feature ready for merging into Core (that won’t happen until WordPress 5.9 at the earliest).
What was discussed?
The format of the hangout was an open discussion comparing and contrasting the classic menu screen with the experimental block-based navigation screen.
To this end attendees were asked to test drive both screens and note down their findings prior to the call.
The meeting facilitators also prepared a list of items as discussion points which were worked through during the call.
Each item was demonstrated, discussed and then assigned a loose priority of High/Medium/Low based on how critical the group felt the issue was to achieving feature parity.
Outcomes
The key outcomes of the call were:
A clearer understanding of the current project roadmap and the next steps required.
Contributors working on the Nav Editor will now look to reorganise and reprioritse the tracking issue around the problems identified during the call.
All items will be added to the tracking issue (with the possible exception of bugs).
The High priority section of the tracking issue will be reformed and refocused around the goal of “removing the experimental status from the Navigation Editor”. Only tasks directly related to this goal will be considered for inclusion in the “High” priority section.
Tasks identified during the call that were marked as Medium or High till be added to the aforementioned High priority section of the tracking issue.
Contributors will focus on tackling High priority tasks in order to realise the goal of removing the “experimental” status.
All contributors are encouraged to become involved in prioritisation. Everyone is welcome and we’d very much value your feedback. If you feel a priority is wrong or missing then please let your fellow contributors know.
Thanks to everyone who attended the hangout and we look forward to moving the Navigation Editor forward together.
On Thursday, I hosted a little walkthrough on how to write a simple end-to-end test to make sure a specific piece of editor functionality that had broken in the past wouldn’t break again.
As 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/ grows, the project sometimes experiences regressions: Features that used to work suddenly don’t anymore. In order to prevent these regressions from happening, contributors can write end-to-end (e2e) tests that cover a given piece of functionality and alert us when that functionality is broken. Combined with a Continuous Integration system such as 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/ Actions, this is a very powerful tool, since it can notify a PR author that their PR might break something before they even merge that PR.
I’ve recently tried to keep more track of such regressions, and have started filing issues requesting e2e tests to cover them. In the hangout, I’ve picked one of these issues and demonstrated how to write an e2e test for it.
