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.
Hallway Hangout: Performance Improvements for WordPress 6.2
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.
