Core Performance Team Roadmap Published

Over the past few weeks, the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team has been working on a roadmap for 2023, gathering different priorities of the different contributors and bringing them together in a cohesive roadmap. The team is excited to share this roadmap, which is now available on the Make Performance site.

The roadmap summarizes the team’s big picture focus areas and more specific efforts planned for the year. This is intended to be a living document that may see updates from time to time. It is difficult to plan and scope work for an entire year, so certain priorities may shift or new ones may be raised. Even so, this roadmap is meant to communicate the current intentions for what is on the near horizon for the Core Performance Team.

While most priorities on the roadmap are focused on direct WordPress core enhancements and performance support of the key GutenbergGutenberg The 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/ phases 2 and 3, other priorities are focused on external tooling, such as to measure performance reliably, or to provide assistance to pluginPlugin A 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 or theme developers.

Please refer to the 2023 roadmap page for a comprehensive overview. It contains the full list of priorities for the year, and furthermore provides additional context for the big picture focus areas.

#core-performance, #performance, #roadmap, #roadmaps

Performance Chat Summary: 21 February 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023
  • Next steps on sharing the public roadmap for 2023 now the GitHub issue has been closed
  • Next steps on creating standalone plugins [summarized in this GitHub issue]
    • The performance team received feedback from Matt and Josepha regarding the 3 approaches in this comment
    • @flixos90 As such, we should move forward with option 2. While that’s not the same option we initially voted for, I think that’s still a great option, and it’s great that we now have a clear path forward
      • As mentioned before, Option 2 is technically a bit more work than Option 1, but it effectively includes the work we would need to do for Option 1 as well. So I think it makes sense to do this work in two stages
      • @flixos90 has opened a couple of follow up issues as well as this overview issue to keep track of all the work: https://github.com/WordPress/performance/issues/656
      • Call to please review and share any ideas or feedback you have on GitHubGitHub GitHub 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/ (either in the overview issue if it’s high level feedback, or on the specific issues if it’s a more concrete feedback regarding one of the tasks)
      • The idea is that for milestone 1, which is already fairly well defined, to get it across the finish line by end of March
      • So at that point we would have the standalone plugins available already, which is a big step regarding the overall effort

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger we are working towards completing the infrastructure for the PluginPlugin A 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 Checker over the coming weeks. Once done we will reach a major milestone where we’ll have a working plugin running with some initial checks. You can see progress on the GitHub repo here. Feel free to leave any thoughts/ideas you may have in that repo too.
  • @joemcgill sharing on behalf of @mukesh27 who is out for WC Asia
    • he is very close to having the automated performance measurements workflow implementation for WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ready to share. There is one new requirement that needs to be addressed, which we discovered when coordinating with @youknowriad about logging data with the dashboard he’s set up at https://www.codevitals.run/project/2. Hoping to have that wrapped up later this week.
  • @joemcgill Also, I opened an initial draft PR for adding XHProf support directly in the wp-env package. I’m planning on making updates to that approach this week that would simplify setting up XHGui for analyzing profiling data, but am already able to use this setup to do profiling of WP, which has been useful in testing for possible regressions in 6.2.

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones work proceeds on the SQLite integration
  • @clarkeemily spotted a few new issues added recently re. SQLite integration which I added to the [Focus] Database label [see here]
  • @joemcgill There were also a few issues that came up during the Performance Lab release party yesterday, that I wanted to make sure we get added

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90 No updates from my end, other than the news I already shared about creating standalone plugins and unbundling the Performance Lab plugin, and that version 2.0.0 was released yesterday

Feedback requested

Open Floor

  • @olliejones The drop-in method of loading run-early code is reaching the limit of its flexibility. And the workarounds are, imho, too brittle to release broadly; they’ll drive site owners ’round the bend.
  • A lot of this performance work will depend on run-early code. Can we imagine a more extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. way of handling it that will work better when, say, 50% of all sites use SQLite, and they all use other drop-in activated features?
  • It will likely take some sort of core change to improve this corner of WordPress. What’s the process for working out all that stuff?
  • It might be as simple as modifying the mu-plugin load order so some of them load early.
    • @joemcgill I think it’s a great question, and one that we could begin thinking about by focusing on examples of where the current functionality of WP is limiting our ability to deliver the kind of user-facing improvements we’re trying to make. If solving an underlying architectural issue unblocks a whole lot of other improvements, then I think it’s worth prioritizing, but hard to say without concrete examples.
    • @olliejones the following come to mind:
      • Collisions between the performanceServer timing part of PL and various persistent object caches.
      • Collision between Query Monitor and the SQLite integration
      • And, conceptually it should be possible to run both Query Monitor and SQLite integration, and activate/deactivate them in whatever order the site owner wants. (except obvs deactivating SQLite on a install that uses it would break it.). The same logic applies to object caching.
    • @olliejones to create an issue to capture next steps here
  • @joemcgill flagged a critical issue to address this week https://core.trac.wordpress.org/ticket/57150 

Our next chat will be held on Tuesday, February 28, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-media, #core-performance, #performance, #performance-chat, #summary

Performance Chat Agenda: 21 February 2023

Here is the agenda for this week’s performance team meeting scheduled for February 21, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 14 February 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Performance team roadmap for 2023 reminder, if you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue before end of day Wednesday February 15, 2023
  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @flixos90: we got the lazy-loading fix for blockBlock Block 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 committed to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. yesterday: https://core.trac.wordpress.org/changeset/55318 – just in time for the WP 6.2 BetaBeta A 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. 2

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @spacedmonkey: Would like to get feedback on #57701 and GutenbergGutenberg The 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/ PRs 48003, 48001, 48000, 47999, 47997

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger: Progress on the PluginPlugin A 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 Checker infrastructure is moving along nicely. We’re aiming to have a working plugin running with some initial checks by end of the month. You can track progress on the GitHub repo and feel free to leave any thoughts/ideas you may have (the repo will be moved to the WordPress organisation when ready).
  • @joemcgill: I’ve got a working implementation of a profiler setup, using XHProf in a wp-env environment that I plan on cleaning up and submitting as a PR to the @wordpress/env package this week and will write up detailed instructions for how others can use these tools to profile WordPress locally.
  • @joemcgill: I’ve also been supporting @mukesh27 (who is also traveling today) on an initial implementation of adding automated server timing measurements to the wordpress-develop repo so we could begin measuring the performance impact of specific commits to core. Looking to try and open a PR later this week.
  • @flixos90: I quickly hackedhacked the WP core dev environment yesterday using @joemcgill‘s XHProf approach above to get it running there too: https://github.com/felixarntz/wordpress-develop/commit/ed096270d817eb9850ea54e4a30662cf2d9492d8
    This is by no means a clean implementation, but something to potentially explore later; would be nice to get this optionally baked into the core dev environment as well so we can easily do profiling as we develop
  • @joemcgill: One thing to note there is that there is an observability cost to profiling, so it’s not meant to be a way of measuring performance from a user’s point of view, but instead to inspect the performance attributes of specific subsystems within a WordPress request lifecycle

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones: SQLite integration: Lots of testing coming in.  Ari Stathopoulos and Adam Zielinski have been hammering away on the SQL dialect translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. issues. This PR will be an ongoing job.
  • @olliejones: It would be nice to integrate some database query stuff into the Server-Timing APIAPI An 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. — that reports to the browser. I’ll do a module proposal.

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • Approach for publishing modules as standalone plugins
    • @joemcgill: That seems like a conversation about “which” modules should be published outside the Performance lab plugin, which is the same as this issue, correct?
    • @flixos90: Yes 640 is related, but this is about our policy. Basically, if we decide every module is a standalone plugin, there will never need to be any discussions on which modules to publish and which not to
    • @joemcgill: I think the only thing that is unclear is whether we’re going to intentionally not publish certain types of modules (e.g., site health checks) as separate individual plugins. I’m still of the opinion that those types of features, which don’t modify the user experience of WordPress, but are instead meant to help measure and/or provide performance feedback should remain part of the Performance Lab plugin itself, rather than being shipped separately.
    • @flixos90: So I guess we have to decide between 3 alternatives
    • @joemcgill: I think that’s a good initial set of options. As a thought experiment, we should apply these options to the current list of modules
    • @flixos90: I took your request to heart and posted a list of modules here

Our next chat will be held on Tuesday, February 21, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-media, #core-performance, #performance, #performance-chat, #summary

Performance Chat Agenda: 14 February 2023

Here is the agenda for this week’s performance team meeting scheduled for February 14, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 7 February 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Reminder: Performance team roadmap for 2023 https://github.com/WordPress/performance/issues/631 If you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue before end of day Wednesday February 15, 2023
  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger making good progress on the PluginPlugin A 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 Checker. We’re starting to finalise the infrastructure and should have a working plugin running some initial checks by end of the month. You can track progress on the GitHub repo and leave any thoughts/ideas you may have. The repo will be moved to the WordPress organisation when ready
  • @mukesh27 I would like to share an update for Automated Performance Testing that @adamsilverstein already share blog post on WordPress core.
    • Issues that completed and merged in feature/automated-performance-testing-mvp branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..
    • AC ready for review.
    • We will open a PR against the WordPress trunktrunk A 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. once the initial version is complete. Feel free to take a look at the issues and leave any thoughts or ideas you may have.
  • @joemcgill Additionally, I’ve been starting to work on an experimental implementation of XHProf with wp-env to help make it easier for folks to do general performance profiling tasks. See: https://github.com/joemcgill/gutenberg/pull/1 as a starting point.
  • @10upsimon updates on Enhancing the Scripts APIAPI An 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. with a loading strategy
    • Documentation approved, although there was a comment added post approval that I have addressed. It does not change the work, but it does result in the need to confirm that the blocking strategy is not to be confused with the blocking  script attribute itself.
    • GitHub issues have been finalized and broken down into 4x milestones in a separate sheet, estimates are present for all issues in the sheet, although not all issues are in GH yet.
    • GH Issues and AC’s have been added to the project board for Milestones 1, 2 and 3 and have been assigned to @joemcgill for review. It looks like all except for one have been approved (at the time of writing) as they’ve been moved to the backlog
    • I’m in the process of breaking down issues for Milestone 4
    • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. to be posted by Friday, I see no risks thereto.
    • Engineering will commence next week on Milestones 1, 2 and 3

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones I’ve been hammering on the low end persistent object cache, looks good.
  • @aristath These past couple of weeks I continued working on the SQLite database implementation. There’s a lot of work to do, but things are looking good. Started collaborating with @zieladam as well in an effort to improve some things and make the implementation more stable.

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • @flixos90 Just sharing here that I discovered (probably?) a major performance regressionregression A 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. in 6.2 for classic themes: https://core.trac.wordpress.org/ticket/57648
    • I’m going to follow up on that ticket shortly to collaborate with @oandregal as he is seeing slightly different results. Of course there is a chance that something specifically in my analysis went wrong, but we will have to validate that data

Our next chat will be held on Tuesday, February 14, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#core-performance, #meta

Performance Chat Agenda: 7 February 2023

Here is the agenda for this week’s performance team meeting scheduled for February 7, 2023 at 16:00 UTC.

  • Announcements
    • Reminder: Performance team roadmap for 2023 https://github.com/WordPress/performance/issues/631 If you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue before end of day Wednesday February 15, 2023
    • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023
  • Focus area updates
  • Infrastructure
  • Open floor

    This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

    #agenda, #meeting, #performance, #performance-chat

    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.

    If you’re interested in joining, the Hallway Hangout will happen on 2023-02-13 16:00. a Zoom link will be shared in the #core-performance SlackSlack Slack 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.

    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.

    Noting this specifically for folks who have expressed interest previously or who are involved directly in this work, despite some of you going to WC Asia! cc @hellofromtonya @aristath @oandregal @tweetythierry @desrosj @youknowriad @spacedmonkey @adamsilverstein

    Recording

    Attendees: @flixos90 @spacedmonkey @tweetythierry @oandregal  @annezazu @mukesh27 @joemcgill @johnbillion

    Notes

    Overall themes to the conversation:

    • 6.2 improves performance, in particular for blockBlock Block 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.jsonJSON JSON, 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 coreCore Core 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 trunktrunk A 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. / BetaBeta A 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 candidate One 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 localeLocale A 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 Contributors Core 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 Source Open 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 pluginPlugin A 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 pingPing The 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.

    GutenbergGutenberg The 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

    • @flixos90 asked @oandregal about the work being done in Gutenberg to add more frontend rendering 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.
    • @flixos90 shared the web vitals GitHub repo that is supposed to be very close to how core web vitals are measured.
    • @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.

    Links Shared

    #hallwayhangout, #performance

    Automated performance monitoring in WordPress core

    Gathering performance metrics automatically is a way to track performance over time and ensure that WordPress continues to improve.  Automated performance tooling will also help the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team identify issues and resolve them with less effort.

    Why add automated performance testing?

    Adding automated performance testing will help us monitor performance changes in WordPress core continuously. It gives us a track record to capture how core performance is being enhanced over time, and it allows us to catch regressions early and accurately identify underlying causes. Similar to our unit testunit test Code 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. suite, automated performance testing would help protect core from introducing large performance regressions by catching problems immediately and tracking performance over time. Automating testing also means saving contributor effort by replacing a time consuming manual process.

    The core performance team is focused on improving core performance. Examples of this work include introducing changes that reduce the number of database queries or improve caching. Each new performance team feature must show measurable gains, and each new WordPress release is performance tested by the team. In the 6.1 release cycle, this led to the discovery of some significant performance regressions, e.g. in this Gutenberg issue or this Trac ticket. Automated testing would catch this type of regressionregression A 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. as soon as it was introduced, making it much easier to resolve.

    It is worth noting that GutenbergGutenberg The 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/ has already done extensive work on performance, tracking metrics with each commit and publicizing details with each release.  

    What automated performance testing would do in core

    Similar to Gutenberg, WordPress core would gather a set of automated performance metrics along with the existing test runs (e.g. unit tests, coding standards) we already have for each new commit. These metrics can be used to identify the exact point a performance regression is introduced into core. At milestones like a major releasemajor release A 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., the metrics can be compared against the previous release to gauge progress.

    Goals for the initial version

    The scope of the  initial version of automated performance testing is intentionally kept limited so we can deliver more quickly, then we can iterate. 

    The initial version will include the following features:

    • For each core commit a GitHubGitHub GitHub 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/ action will run a set of automated performance tests, collecting key data points about how WordPress is performing (such as total load time and total query time) on blockBlock Block 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. and classic themes. 
    • The system will collect server timing metrics using the standard WordPress environment and current recommended version of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher.  

    Future Enhancements

    Several areas of work are considered out of scope for the initial implementation, primarily to keep the focus limited for the initial release — not because they aren’t good ideas! Once we build a solid foundation for tests and are confident in the metrics we are collecting, we can consider additional improvements.

    • Collecting additional metrics: initially we will focus on key server timing metrics
    • Collecting metrics for other contexts: initial metrics will only measure the home page of the latest core block and classic themes with their default demo content.
    • SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. or ticketticket Created for both bug reports and feature development on the bug tracker. reporting: initial work will focus only on collecting and recording metrics at each commit. 

    FAQ

    Will the data be stable enough to be useful?

    Performance results can vary in a CI environment, making regressions harder to detect. To mitigate this, the system will run several iterations and use the median value.

    What metrics will be collected exactly?

    Initially we will only collect a few key metrics to keep the dashboard simple, focused on the total load time. Once we have established the new tool, we can consider including additional metrics, or adding hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. to make the test runs extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software..

    What about testing older PHP versions?

    To reduce the time/cost associated with running these tests, they will be limited to the current recommended version of PHP. Unlike unit tests, performance tests are unlikely to produce significantly different deltas for different PHP versions: regressions are likely to be across PHP versions.

    Why not test wp-adminadmin (and super admin) or more routes?

    In order to keep the time and cost of running these tests low, and the dashboard simplified, initial testing is intentionally being kept somewhat minimal. In the future it would be good to consider adding other common routes such as the wp-admin dashboard and single post page.


    Thanks to @tweetythierry @flixos90 @joemcgill @mukesh27 for reviewing this post and to @youknowriad for the inspiration (and foundation) of the Gutenberg performance metrics.

    #core-performance, #performance, #testing

    Performance Chat Summary: 31 January 2023

    Meeting agenda here and the full chat log is available beginning here on Slack.

    Announcements

    • Performance team roadmap for 2023 https://github.com/WordPress/performance/issues/631 If you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue!
      • @flixos90 Anyone that is more or less regularly contributing to the team is asked to think about and share their priorities for this year, if possible
      • @spacedmonkey There is also SQLite database and object cache that are in play
        • @flixos90 I think SQLite is clearly a focus. What is on the issue right now is not at all a complete roadmap. The idea is that anyone can post comments with what they would like to prioritize
      • @olliejones It’s my impression that almost nothing, except @flixos90 contributions, are on the priority list yet. So, it’s up to the rest of us.
        • @flixos90 Exactly, I just posted 2 things that we already have proposal posts for, as a starting point. So yes, it’s explicitly a call for anyone involved in the team to contribute to this roadmap
      • @spacedmonkey One thing I have not discussed publicly, but want to look into lazy loading meta data in core. We have a problem that more and more WP_Queries are being run per page and lots of post meta is being loaded when not needed https://core.trac.wordpress.org/ticket/57496
    • The GutenbergGutenberg The 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/ team recently added TTFB measurement to their repo, which is being collected in the code health dashboard here: https://codehealth.vercel.app/project/1. It’s making visible the performance regressionregression A 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. in blockBlock Block 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. theme rendering when compared with classic themes for a simple “hello world” page. As a team, we would like to make sure we’re properly prioritizing the tickets we have for 6.2 that would positively impact this metric—particularly anything that we need to land before the betaBeta A 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 milestone next week.
      • @joemcgill I think much of the work for 6.2 that was focused on improving server response times for block themes has already been merged, but I’m mindful of the beta milestone coming next week and want to help prioritize helping land anything that I can that is still in the air.
        • @spacedmonkey me and @flixos90 have worked a lot on block theme performance. Any questions on what I am working on, please feel free to pingPing The 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.” me
        • @joemcgill Main thing is whether there are any enhancements that still need to land that you’re waiting on review for?
      • @clarkeemily we also have the Bug Scrub tomorrow at 16:00 UTC time where we can talk through other 6.2 performance items
      • @mukesh27 Is anyone on the Gutenberg team checking those regressions, or do we have to?
        • @joemcgill Good question. I think they are, but there’s no reason we shouldn’t take a look every so often. Really, it would be nice to do something similar for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
        • @mukesh27 Are those changes incorporated into the core of WordPress?
        • @johnbillion I’d love to do something similar for core, the main problem is how to avoid variance so the reporting over time is accurate
        • @flixos90 We have talked about it before in that recent hallway hangout earlier in January. In fact @adamsilversteinis working on a Make post that should go out this week
        • @spacedmonkey I would also have some way of query count per page load.
        • @joemcgill I think long term variance is a concern, but maybe not a blockerblocker A bug which is so severe that it blocks a release. as long as the short term trends are instructive/useful.
    • Plan to have quick-fire focus area updates (15m) so we can focus the remainder of todays chat on Next steps for Unbundling the Performance Lab PluginPlugin A 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 (proposal)

    Focus area updates

    Images

    @adamsilverstein @mikeschroder

    GitHub project

    Feedback requested

    Object Cache

    @tillkruess @spacedmonkey

    GitHub project

    Feedback requested

    Measurement

    N/A

    GitHub project

    • @joegrainger Still making good progress on the Plugin Checker, starting to approach the remaining issues on the infrastructure so will soon be in a position to run some of the initial checks and do some testing. Feel free to track progress on the GitHub repo and leave any thoughts/ideas on issues. The repo will be eventually moved to the WordPress organisation when ready.

    Feedback requested

    JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

    @aristath @sergiomdgomes

    GitHub project

    • No updates

    Feedback requested

    Database

    @olliejones

    GitHub project

    Feedback requested

    Infrastructure

    @flixos90

    GitHub project

    • @flixos90 nothing to update for Infrastructure

    Feedback requested

    Open Floor

    • Unbundling Performance Lab plugin
    • TL:DR; the team are in agreement to proceed with working towards splitting out standalone plugins and keeping the Performance Lab plugin as it is for now
    • Detailed conversation below:
      • @flixos90 We are still waiting to get feedback from Matt on the 3 alternative options that we have outlined and discussed earlier in January. However, I think it would be unwise to just wait and do nothing until we hear back, for which we don’t have a timeline. Therefore my proposal is to work towards simply splitting out standalone plugins and keeping the Performance Lab plugin as is for now
      • A bit more context on the reasoning behind that proposal: The “for now” here is important, as that would likely be a temporary solution. Doing so is effectively our option 1 that we voted for in https://github.com/WordPress/performance/issues/618#issuecomment-1377598692, but the main reason I’m proposing to already work towards it here is that that option is the least disruptive and the least effort, and even if we eventually go with option 2 or 3, we would need to implement the same changes as part of that
      • It is also the most natural transition, for example @aristath‘s SQLite standalone plugin has already been broken out as a standalone plugin
      • The idea is that with the above we would work in the right direction no matter what the eventual final outcome should be. And in any case we would not be wasting time doing work that would potentially not be needed
      • @joemcgill So, if I’m understanding properly, you’re proposing that the performance lab plugin would still include the modules that have been split out. Correct?
      • @flixos90 Yes, it is effectively like option 1 in https://github.com/WordPress/performance/issues/618#issuecomment-1377598692
      • @joemcgill What other plugins need to be split out that aren’t already?
      • @flixos90 I think that we need to discuss. But first I wanted to get feedback on the general idea I shared above. Is that a reasonable next step, as a temporary measure to work in the right direction?
      • @johnbillion Does that duplicate any work or is there a handy build/deployment step for publishing the separate plugins?
      • @flixos90 We would have a build step that simply replaces module headers with plugin headers and deploys those as individual plugins. All modules already work standalone, so there’s no extra work involved in that regard. The main work would be to implement the build and deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. step.
      • @joemcgill At least the SQLite integration plugin is already moved to a separate repo, so it’s a bit clunky to have some of these modules in a mono-repo and some not. It would be nice to align on a development approach.
      • @flixos90 Absolutely; if we go with this approach, we would likely move the SQLite repo back into the PL repo (just for development, the plugin repos on .org would of course remain separate)
      • @johnbillion +1 on a monorepo otherwise we introduce more metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. problems maintaining separate repos
    • No other thoughts on the above from todays meeting, @flixos90 based on the feedback above I think it’s reasonable to proceed with this option for now, to work in the right direction. What we should discuss then though is our approach on how to break out modules as standalone plugins (which we already started talking about a few weeks back)
      • @joemcgill My initial question is whether all modules should be standalone plugins, or if some of them are better suited to stay as part of central infrastructure or smaller experiments as “core modules” of the performance plugin?
      • @flixos90 Exactly, I would outline these alternative ways to go about it:
        • Every module becomes a plugin?
        • Some modules are grouped together into “focus” plugins?
        • Only some modules get broken out as a plugin?
      • @olliejones Specifically, does it make sense to have a standalone “Enhanced Site Health” plugin containing the various site health modules?
        • @flixos90 Potentially. Though my personal take is that we should avoid grouping modules as then we are still going the slippery slope of not having individual plugins for individual features. FWIW, we used to have plugins like https://github.com/audrasjb/site-health-audit-enqueued-assets, and I think that’s the most appropriate approach, even if those plugins are extremely niche
      • @joemcgill Personally, I would keep things like audits, health checks, and small feature experiments like fetchpriority in the main plugin, and break out larger feature plugins.
        • @flixos90 If we do this, we won’t fully address the request of having individual plugins for individual features. What if someone just wants to test fetchpriority? Yes, it’s much simpler than e.g. WebP, but I’m not sure that justifies going a different route for the two
        • @joemcgill That may have been a bad example, and also the part that I’m least confident about, but seems it would be nice for us to have a place to experiment with smaller changes that we are thinking of proposing as enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. in core and not have to spin each one out to a separate plugin until/unless it matures to the point where it’s warranted.
        • @flixos90 Ah okay, that idea sounds interesting. Certain things could start out as a module in the PL plugin and only become plugins as they mature?
      • @olliejones So, PL contains stuff that’s bound to be included in core, AND stuff that’s bound for standalone plugins? Is that right? Or is the criterion for putting a module into PL still that it is bound for core?
        • @joemcgill Right, or if they’re a large enough feature that it makes sense being its own thing. I would say the SQLite persistent cache fits that qualification for me
        • @flixos90 All of that would be things to be included in core. Whether it’s a module in the PL plugin or a standalone plugin is just different ways to “test-drive”. So if we did that, we would still have a mapping that a module can be mapped directly to a standalone plugin, but we would decide for each module whether/when to do that on a case by case basis?
        • @olliejones Is that too limiting? Is Matt thinking along the lines of Drupal’s Core Modules? Is that the direction his “canonical plugins” want to go? Should this team stay away from doing stuff UNLESS it’s bound for core? That’s what I mean. There’s plenty of perf work that only applies to some installs, not all.  Like the persistent object caches. Maybe like webp.
          • @flixos90 we can totally work on things that are not for core; for example the plugin checker project we’re working on. It’s just that the scope of the Performance Lab plugin has been for features targeted for WordPress core. Of course it can always happen that a feature is never deemed eligible or ready. But features in the PL plugin should have the intent to land in core eventually
        • Conclusions: @flixos90think we are converging on the approach of “decide on a case by case basis for each module whether/when it becomes a standalone plugin”, but it’s been only a short conversation with few voices heard, so maybe we can defer a hard decision until next week; I’ll summarize in https://github.com/WordPress/performance/issues/618 and we can keep discussing there
        • @olliejones add to roadmap https://github.com/WordPress/performance/issues/631 for future discussion

    Our next chat will be held on Tuesday, February 7, 2023 at 16:00 UTC in the #core-performance channel in Slack.

    #core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

    #core-performance, #meta