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

Announcements

• Welcome to our new members of #core-performance

Priority Items

• WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
  • Current release (6.7)
  • Future releases
• 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 (and other performance plugins)
  • Enhanced Responsive Images
  • Embed Optimizer
  • Image Prioritizer
  • Image Placeholders
  • Modern Image Formats
  • Optimization Detective
  • Performant Translations
  • Speculative Loading
• Active priority projects

WordPress Performance Trac Tickets

• There are currently 16 performance issues in 6.7
• @pbearne I need input on this ticketticket Created for both bug reports and feature development on the bug tracker. as I made opinionated changes as to which option should not be autoloaded #61103
  • @joemcgill I plan on digging into that PR to give you feedback, but am going to be out on holiday for a bit. If anyone else has time to look at this in the mean time, please do so.
  • @mukesh27 I will take a look this week
  • @joemcgill One thing that will be good to understand, is that if we aren’t autoloading options that are only needed in the adminadmin (and super admin), how do we make sure the editor experience isn’t negatively affected. I think you’re already planning on priming all of those options in the admin, but would be good to get some performance measurements of the before/after of both the front end and admin.
  • @pbearne I have a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. to load the admin options in back on wp_int

Performance Lab Plugin (and other Performance Plugins)

• Performance Lab plugin and the following performance plugins:
  • Enhanced Responsive Images
  • Embed Optimizer
  • Image Prioritizer
  • Image Placeholders
  • Modern Image Formats
  • Optimization Detective (Developer Preview)
  • Performant Translations
  • Speculative Loading

• @mukesh27 I have been working on PRs that ready for review:
  • Performance Lab plugin:
    • PR #1374 – Autoloaded Options Health Check: Disabled options reappear in Site Health after external update
  • Modern Image Formats plugin:
    • PR #1354 – Picture element: The accurate sizes improvement for images not working
• @westonruter It seems like we’re getting increasing reports of issues with image generation in Modern Image Formats
  • In GitHub and support forums
  • @westonruter Might be related to the issue of AVIF generation taking a very long time sometimes?
  • @joemcgill Ah, I do remember cases a long time ago where image generation could take longer than the max PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher timeout on some hosts and result in the attachment data being created in the DB while the actual image generation failed. I wonder if something like that is happening?
  • @westonruter That’s being discussed here: https://github.com/WordPress/performance/issues/371
  • @adamsilverstein this could also be a support detection issue, (where format support for AVIF gives a false negative or positive), interesting they say it falls back to WebP
  • @westonruter I wonder if the AVIF generation should be moved a background process? Use the JPEG immediately upon upload and then use the AVIF once it is available
  • @adamsilverstein we already have a way of generating images in multiple passes, but it needs to be able to process one image completely before the timeout
  • @joemcgill That’s a good idea. There is prior art for generating missing intermediate sizes that could be referenced.
  • @pbearne Idea: we need a long process control for wp-admin that can be used for any task that takes a long time (images gen, post delete, etc.)
  • @adamsilverstein https://github.com/WordPress/performance/issues/490 was part of that previous effort, there is also a trac ticket
  • @westonruter I thought that was primarily for regenerating the entire media library
  • @adamsilverstein yes, but part of that was the ability to regenerate images in i the background #6814 16 year old ticket
  • @joemcgill It’s not totally accurate anymore, after #40439
  • @adamsilverstein true, we partially solved the issue with that, as long as the user agent remains present to trigger the retries
  • @joemcgill I’ve played with using WP_Cron for this a looooooong time ago, but that can cause failures to affect end-user front-end requests, which we’d want to avoid

Active Priority Projects

Improving the calculation of image size attributes

• @mukesh27 For Improving the calculation of image size attributes i have been working on:
  • PR #1382 – Update wp_calculate_image_sizes to Reflect Changes in sizes attribute
  • Issue #1389 – Accurate sizes improvement didn’t account for the disable 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. for sizes
  • @joemcgill I’m reviewing those this morning

Plugin Check

• @swissspidy there is 1 new performance-related check being worked on that’s ready for code review: https://github.com/WordPress/plugin-check/pull/519. There are more PRs some other contributors are working on, but nothing performance-specific.

Open Floor

• WordPress 6.6 performance analysis
  • @adamsilverstein Yes… I have been working on a post for 6.6 performance changes and will share a draft here for feedback soon!
  • one challenge has been identifying the source of the slight regressions we see in 6.6 (the numbers haven’t changed much since I shared results here for an 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). a few weeks ago)
  • part of the challenges is tracking changes that originate in 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/ project and are then merged over to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. our automated tests haven’t highlighted issues, nor are the Gutenberg performance tests
  • some ideas: it might be because the regressions are very small and spread out over a number of commits, or it might be related to the difference in how we are doing automated tests. in case, it points to an area we can improve
  • @joemcgill Agreed. There are a number of improvements that we could make to our CI infrastructure in both the GB repo and in Core that would help. We’ve already got https://github.com/WordPress/performance/issues/1380 as a place to discuss a set of improvements we want to focus on next. I’d love to see more discussion there so we can define and prioritize some next steps.
  • One of the questions that I still have is whether the benchmarks that we have been taking at the end of each release are providing us with useful info, or if they are obscuring what is really happening in the field.  @adamsilverstein I’m curious if we could get some HTTPArchive data after 6.6 has been out a while to see if our lab benchmarks relate to real user data or not.
  • @adamsilverstein that is a good point, I’m happy to work on that. we should have enough data in a few months.
  • some performance improvements we are adding will really only become apparent in the field data, and our automated testing can’t really measure those

Our next chat will be held on Tuesday, July 30, 2024 at 15:00 UTC in the #core-performance channel in Slack.

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

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

Announcements

• Welcome to our new members of #core-performance
• The next Performance Lab release will take place on Mon Jul 15, see https://github.com/WordPress/performance/milestones
• WordPress 6.6 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). 3 happening today, ahead of the main release scheduled for Tue Jul 16

Priority Items

• WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
  • Current release (WP 6.6)
  • Future release
• 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 (and other performance plugins)
  • Auto-Sizes for Lazy-Loaded Images
  • Embed Optimizer
  • Image Prioritizer
  • Image Placeholders
  • Modern Image Formats
  • Optimization Detective
  • Performant Translations
  • Speculative Loading
• Active priority projects

WordPress Performance Trac Tickets

• @pbearne the https://github.com/WordPress/wordpress-develop/pull/6994 first draft done, needs a looking at
• @joemcgill We already have a good number of performance focus tickets on the 6.7 milestone—most of which are roll-overs from 6.6. I know that I need to review and clean up the ones that I’m responsible for, but I would encourage us all to do so.

Performance Lab Plugin (and other Performance Plugins)

• Performance Lab plugin and the following performance plugins:
  • Auto-sizes for Lazy-loaded Images
  • Embed Optimizer
  • Image Prioritizer
  • Image Placeholders
  • Modern Image Formats
  • Optimization Detective (Developer Preview)
  • Performant Translations
  • Speculative Loading

• @westonruter For Embed Optimizer, this PR will be ready for review this morning. I just need to add the description to detail the changes: https://github.com/WordPress/performance/pull/1302
  • This includes fundamental enhancements to Optimization Detective to make it much more powerful to be able to make optimizations to a document (e.g. what Embed Optimizer requires)
• @westonruter I think the plugin with the most need is Modern Image Formats as there are a couple bugs needing to be fixed: https://github.com/WordPress/performance/milestone/59
  • @westonruter just merged one of the fixes
  • @adamsilverstein @mukesh27 and @joemcgill are reviewing
• @mukesh27 the updated sizes feature from auto-sizes is ready for this release, some final PRs ready for review:
  • PR #1335 – Plugin rename
  • PR #1329 – Merge feature 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". to 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.
• @joemcgill there’s also a proposed name change for the Auto-Sizes plugin

Active Priority Projects

Improving the calculation of image size attributes

• Discussed above

Improved template loading

• @joemcgill The template loading work is mainly wrapped up in 6.6. There are a few minor follow-up issues that I think we’ll continue to track but I’ll work on summarizing next steps and closing up those GH issues.
  • The two things that are on my mind in the short term are:
    • Supporting the Plugin Check project as the Plugin Review team are working to get it integrated into their systems.
    • Improving our performance metrics for both CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GB.

Plugin Check

• @joemcgill For Plugin Check, I’d like to get more eyes on this conversation., which may end up being a requirement for them to do the integration

Open Floor

• @mukesh27 Do we have any open issue for Improving our performance metrics for both Core and GB 
• @joemcgill raised that @swissspidy mentioned one last week that included both misc improvements and shared performance tooling and asked about whether we should separate these issues https://github.com/WordPress/performance/issues/1093
  • I do think it would serve us well to put some focus on this early in the 6.7 cycle so we can more easily pinpoint which commits have server timing performance implications. That’s been a big challenge the past 2 releases. (In the GB repo specifically)
• @pbearne I am thinking of suggesting that WP has an infrastructure release where we update/re-organize the PHPUnit tests etc. as without core committers actively making the changes it will never get done. The performance testing could be part of this
  • @joemcgill I would suggest proposing the infrastructure changes you have in mind and whether those become a release focus or not, could be secondary.

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

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