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

Announcements

• Welcome to our new members of #core-performance
• Plan to launch Performance Lab plugin version 3.0.0 on Mon April 15

Priority Items

Structure:

• WordPress performance Trac tickets
  • Current release (WP 6.6)
• Performance Lab plugin (and other performance plugins)
  • Open discussion regarding streamlining PL plugin and other standalone plugins #1061
• Active priority projects
  • INP research opportunities
  • Improve template loading

WordPress Performance Trac Tickets

• For WordPress 6.6:
  • @adamsilverstein volunteered to be the performance release lead for 6.6

Performance Lab Plugin (and other Performance Plugins)

• Open discussion regarding streamlining PL plugin and other standalone plugins #1061
  • @flixos90 at a high level I like what @swissspidy proposed in https://github.com/WordPress/performance/issues/1061#issuecomment-2044774194
    • It would be great if we could have distinct releases per plugin, and automate it completely. Even before we had standalone plugins, the Performance Lab release process involves quite a bit of manual work, like bumping versions and adding changelog in PRs. It takes just a very short time, so not a big overhead, but still prone to human error
  • @joemcgill I definitely like the idea of making the release on GH the result of a release rather than the cause of a release. Seems like we need to better define all of the requirements that an updated process should meet prior to diving into implementation. Is there someone consolidating those requirements?
    • @thelovekesh has volunteered to pick this up, aiming for next Monday to collect everyone’s feedback and to generate a proposed approach
• @mukesh27 has been working on below some follow-up PRs.
  • PRs that have been merged:
    • PR #1116 – Delete option when uninstalling the Modern Image Formats plugin
    • PR #1117 – Update GitHub actions dependency
• @flixos90 opened https://github.com/WordPress/performance/issues/1118 which is about enhancing the npm run since script to support standalone plugins. This unlocks a simple yet valuable improvement to our current publishing workflow for standalone plugins. That said, this is separate from the main discussion we should have here as it doesn’t holistically change anything. I just wanted to mention it for reference

Active Priority Projects

Improve template loading

• @thekt12 asked @joemcgill to check performance for https://github.com/WordPress/wordpress-develop/pull/6369/files at your end, I don’t see much difference.
  • @joemcgill Sure. I can look at that. I also think we need to decide how to resolve @peterwilsoncc feedback on https://github.com/WordPress/wordpress-develop/pull/6137

INP research opportunities

• @adamsilverstein still working through the results, some discussion has continued in comments on the doc. I also saw @swissspidy opened this ticket which is related to one of the findings #60962 (thanks!)
  • One other small update, part of the INP doc suggests a move towards Interactivity API adoption could be helpful, in that regard I have added custom metrics to httparchive so we can track API adoption: https://github.com/HTTPArchive/custom-metrics/pull/113
• @westonruter For sites still using MediaElement.js, I’ve identified some code that appears to be needlessly spending ~50 ms (when profiling at 6x CPU slowdown on my machine) to check if the pointer-events style is supported. Since this is now supported by >98% of browsers, I think this entire block of logic should be replaced with just a simple export const SUPPORT_POINTER_EVENTS = true given this.
  • Granted, this would be more of a LCP fix than an INP fix since it happens early when the page is loading.

Open Floor

• @thelovekesh This PR is waiting for review – https://github.com/WordPress/performance/pull/981. Can someone please take a look. Thanks.
• @spacedmonkey I am going to look into adding new functions for loading multiple network option at once. These plan to mirror the new options for site options. Everyone happy to add this to performance focus?
  • I also want to look into a ticket I created regarding changing how query caches are invalidated
  • At the moment, we use last change as a salt for cache keys. This results in validation but it also means for high traffic sites that generate lots of content, lots of keys being generated. So much so that people are turning the query caches off.
  • I want to find a way to reuse the same query cache keys even after invalidation. Instead of make a new cache and hoping a the existing one falls out of cache, reuse the same key and sort the last modified time as part of the object.

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

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