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

Announcements

• Welcome to our new members of #core-performance
• Call for 2024 roadmap priorities https://github.com/WordPress/performance/issues/903 – the issue will remain open for project priorities until January 5, 2024

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

• @mukesh27 plan to review Jonny’s Lazy load varients PR
• @joemcgill Just getting back into things after the long holiday break. Left a review on @spacedmonkey PR on #59969, which @thekt12 has also been working on. I think we’re close to having something there, just need to align on some details of the approach, I think
  • @spacedmonkey I think we need to consider b/c I think adding a new parameter of variations callback is the only way forward. We need to think about how we are going to implement this in 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/ as well. We have to support 2 versions back of WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The 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. PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher code is in Gutenberg.
  • @joemcgill agreed. If you can outline those concerns in the PR or ticketticket Created for both bug reports and feature development on the bug tracker., that would be helpful. I left you some feedback just about 30 min ago there
• @pereirinha I plan to circle back this week to #59595

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

• No updates this week

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. & CSSCSS Cascading Style Sheets.

Link to roadmap project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

• @flixos90 I’ve been going back and forth on a few ideas regarding JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. modules in the tracking issue
• @luisherranz Regarding JS modules, I’ve opened a PR in WordPress and I’d love to get some feedback there as well https://github.com/WordPress/wordpress-develop/pull/5818

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

• @joemcgill I think the Performance Lab module proposal for lazy sizes is about ready. @flixos90 do you have any timing considerations before that is merged? https://github.com/WordPress/performance/pull/904
  • @flixos90 I’m not sure we should merge it right now given we’re in the last bits of unbundling 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, and it would introduce a new module that ideally should be a standalone plugin. Potentially we could still merge it, but IMO the more pressing point would be to submit it to the .org directory. So that it can go to the review chain. Since it’s a community feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., potentially we could request to expedite
  • @joemcgill Makes sense. I do think we’ll end up wanting it to be in the PL plugin while we await the review, though, so we can get some early testing and feedback on the approach prior to potentially getting this into core during this cycle
  • @flixos90 I think my proposal at the end of https://github.com/WordPress/performance/issues/911#issuecomment-1866602771 would allow for that. Curious what y’all think about this. It would allow us long-term to start anything as a module, then make it a plugin once it’s approved in the directory
  • @joemcgill I like the idea. I would prefer we work towards a clean code separation between modules and plugins, so it’s obvious which are which.
  • @flixos90 There would still be a transition involved though. For instance, if we merge this now, it would go into the modules folder, as only those are actually included and loaded in PL.
    Once it would be approved on .org, we could then move the code to the plugins folder, with (probably) the only code change being the module headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. turning into the plugin header

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

• No updates this week

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo for Plugin Checker

Contributors: @mukesh27 @swissspidy

• @mukesh27 For the Plugin Check, I’ve been providing support by conducting code reviews for open PRs. Additionally, I’ve raised an issue regarding PHPUnit displaying a warning message: “The configuration file did not pass validation!”
• @joemcgill One of the big milestones to finish now that we’re into the new year is getting version 1.0.0 published to the .org repo. Right before the end of the year @bordoni who has helpfully taken up this transition from the Plugin Review team, published maintenance release v0.2.2 of the legacy version. Coordinating with them on when to fully switch over is top of mind for me. Here’s the related issue.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

• @mukesh27 We are on the verge of completing the Milestone 2a issues along with their corresponding follow-up PRs for the Creating Standalone Plugins.
  • The following final PR is ready for review Revise migration pointer un-dismissal to work for all admins

Open Floor

• Discuss #60120 
  • @spacedmonkey I don’t think this ticket should be blocked by other ticket. That ticket might take a long time to resolve. This issue can’t be resolved by the next release. The only thing to decide is if we make the cache group global.
  • @joemcgill I would hope to have an approach for #59719 (the blocking ticket) resolved very shortly and I agree that #60120 should be resolved in this release cycle.
  • @spacedmonkey With theme data, most of it should be global caches in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site context
  • @flixos90 I completely agree that this should receive a cache group. I’m curious though why that is urgent. What are the actual problems of having this in the global cache group?
  • @spacedmonkey The default cache group isn’t a global cache group. Not being in a cache group, means that the cache group can not be cleared.
  • @joemcgill By “default cache group” I assume you are talking about the “themes” cache group. That group is also not persistent without a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., so one of the questions is whether we need to introduce a new cache group, or revisit the way theme data is cached.
  • @spacedmonkey The default cache group is that, a group called default which is where is stored if no group is defined, as current.
  • @pbearne I would be happy to make the changes as needed
  • @joemcgill Thanks for clarifying what you meant by default. What do you mean by “global”
    • @flixos90 Global groups apply to an entire multisite
  • @flixos90 Makes sense that it’s probably not optimal to use a non-global cache group. But we shouldn’t just use themes, that’s the tricky part. Surely we could just make up a new group name for a new global group and fix this issue, but I think then it could be that group name would need to be changed based on the decision from #59719
  • @spacedmonkey Cache groups can be local to a site like posts or global in multisite like networknetwork (versus site, blog) or user
  • @flixos90 To be fair, even the themes group is only global if it’s set to persistently cache. Since we probably want the data here to be persistently cached, it would make sense to make that group (whatever it would be called) global
  • The rest of this discussion continues in Slack from here https://wordpress.slack.com/archives/C02KGN5K076/p1704215017254669

Our next chat will be held on Tuesday, January 9, 2024 at 16:00 UTC in the #core-performance channel in Slack.

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