Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- @flixos90: Formal team proposal
- Given our successes so far (5K+ plugin installs, lots of great feedback at WCEU, etc.) now is a good time to formally propose our initiative as a proper Performance Team
- This would get us our own site on make.wordpress.org and an entry on the top-level site
- Feel free to ask any questions or share your thoughts on this plan in the comments
- @spacedmonkey: Does that mean there will be “official” team members and leads?
- @flixos90: We’ll have to see; not sure if that’s a requirement for a formal team
- @tweetythierry: We currently have the GitHub members list, which we may use as a source of truth
- @shetheliving: Our next release, 1.2.0, is scheduled for next Monday 20 June, which is a US holiday, so we think it would be best to move to Tuesday 21 June and have the release party in the #performance channel on June 21, 2022 at 1pm EDT
- Asked for a thumbs up vote to approve this shift; received 8 thumbs ups so release will be moved
Focus group updates
Images
@adamsilverstein @mikeschroder
GitHub project
Feedback requested
Object Cache
@tillkruess @spacedmonkey
GitHub project
Feedback requested
Site Health
N/A
GitHub project
- We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
Feedback requested
Measurement
N/A
GitHub project
- We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
- @flixos90: Update on plugin checker proposal
- Most important decision to make soon is which approach to follow for this project
- Things to consider:
- Focusing on static analysis only is probably a no go, as so many aspects of performance can only be detected at runtime.
- Server-side analysis is a solid approach as it allows for runtime checks, and we could still easily include static analysis as part of that approach.
- Client-side analysis certainly gives the most flexibility to also include e.g. browser optimization related checks, but it also requires either a public site to be spun up or a headless browser setup, which can be tricky to have on certain environments.
- See this as building with two potential use cases in mind:
- For plugin developers to integrate with their own development workflows, e.g. in a GitHub action
- For the wordpress.org plugin repository to run it on plugin submission (potentially in some reduced capacity, i.e. only a subset of all checks that they consider most valuable)
- @spacedmonkey: Wonder if we can use my ideas from a plugin like Query Monitor, like detecting duplicate queries, slowing running queries, or query counting. For example, WooCommerce adds over 100 queries to page load.
- @flixos90: Discovering things like that would definitely be helpful and Query Monitor is a useful tool that we reuse parts from
- @mitogh: Do we have an idea of which metrics would be considered baseline to “pass”?
- @flixos90: Would be less of a general “pass” vs. “fail,” but more a ton of individual checks that can pass, create an error, or create a warning, like PHPCodeSniffer
- @flixos90: One project that we should probably research more is the latest automated theme testing tool mentioned here. Current take is that we should primarily focus on a server-side approach that’s built with client-side extensibility in mind.
- @johnbillion: I’ve considered splitting some parts of Query Monitor into Composer packages but don’t have capacity right now, happy to assist though where necessary
- @flixos90: One more step that @mikeschroder pointed out is that we should share this proposal with a wider audience, including the plugin review team; will share shortly and also plan to publish a post on Make
Feedback requested
JavaScript
@aristath @sergiomdgomes
GitHub project
Feedback requested
Infrastructure
@flixos90
GitHub project
Feedback requested
Open floor
Help wanted
#core-js, #core-media, #performance, #performance-chat, #summary
#hosting-community, #tide