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
    • @flixos90 That would be a great item to add
• 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

• @adamsilverstein no major updates this week

Feedback requested

• See above
• Needs Discussion (10 issues)
• Needs Dev (1 issue)

Object Cache

@tillkruess @spacedmonkey

GitHub project

• @spacedmonkey working on https://core.trac.wordpress.org/ticket/57568. I think it’s ready for commit
• Added unit tests and ready for review – https://github.com/WordPress/wordpress-develop/pull/3629
• Ready for review – https://github.com/WordPress/wordpress-develop/pull/3928
• Ready for review – https://github.com/WordPress/wordpress-develop/pull/3544
• Ready for review – https://github.com/WordPress/wordpress-develop/pull/3178
• Going to commit after this call – https://github.com/WordPress/wordpress-develop/pull/3365

Feedback requested

• See above
• Needs Discussion (4 issues)
• Needs Review (1 issue)

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

• Needs Discussion (5 issues)
• Needs Review (1 issue)
• Needs Testing (0 issues)

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

• Needs Discussion (4 issues)
• Needs Review (2 issues)

Database

@olliejones

GitHub project

• @olliejones Nothing big. SQLite Object Cache making progress thanks to @spacedmonkey for feedback. That’s it.
  • @spacedmonkey performed some testing and reported some issues https://github.com/OllieJones/sqlite-object-cache/issues

Feedback requested

• Needs Discussion (3 issues)
• Needs Review (2 issues)

Infrastructure

@flixos90

GitHub project

• @flixos90 nothing to update for Infrastructure

Feedback requested

• Needs Discussion (8 issues)
• Needs Review (2 issues)

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: @flixos90 I think 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