2 Focus group updates
- @clarkeemily: Team Rep nominations reminder
Focus group updates
- @adamsilverstein: In the last week the image team finished addressing the WebP feedback and switching back to the original single mime output approach. We also started work on controlling output per size and adding support to
- @adamsilverstein: Yesterday during contributor day at WCUS, Matt posted on (not shipping) WebP in 6.1 which was a surprise to the team. We are currently working with the release leads to better understand his concerns and develop a path forward. I want to acknowledge this is a blow for everyone who worked on the feature (myself included) and at the same time I’d like to encourage us to focus on how we can move forward given the current position. Are there concerns we can address? Does a canonical plugin make sense?
- @spacedmonkey: I think it makes sense to move the webp functionality found in the performance plugin to it’s own plugin. That way it will be easier to get users to test it and get feedback on just this functionality.
- @flixos90: I think if it remains a “feature project”, it makes sense to remain in the Performance Lab plugin – we don’t know if moving it out of it would get us more testers (especially since the Performance Lab plugin has 10k+ installs which is a lot for a feature plugin). If the path of a “canonical plugin” should be pursued, then of course we would need to take it out, but then the nature of the project would also change.
- @kadamwhite: Speaking from REST experience, the times we flirted with making add-on plugins to test specific routes, they never got the traction the main plugin did.
- @adamsilverstein: My main concern about a feature like WebP being in a canonical plugin is how users would know they should enable it.
- @eatingrules: FWIW, millions of users are finding and installing image optimization plugins in the repo. Smush has over 1 million installs. EWWW Image Optimizer has 1+ million. Imagify has 600k. Shortpixel, 300k. WebP Express, 200k. Robin image optimizer, 100k.
- @kadamwhite: Something I remember coming up when we initially introduced responsive images was server / cdn costs, because certain configuration could cause higher-res versions to be downloaded. Does WebP’s size benefit translate to any hosting benefit?, in terms of money?
- @adamsilverstein: with the current implementation yes! lower storage requirements since WebPs are smaller, and lower bandwidth requirements as well, though slightly more processor effort to generate
- @flixos90: I think this discussion is very valuable, however we won’t be able to make any decision here today since we’re still waiting for more information. Hopefully we’ll know more by next week. We definitely need to continue this discussion once we do.
- @pbearne worked on https://github.com/WordPress/performance/pull/528 to add a
fetchprioritymodule to the Performance Lab plugin; will be a co-owner of the module
- @wpgurudev has been working through the feedback and comments on background job class for image regeneration: https://github.com/WordPress/performance/pull/507, this is again up for review; next PR for review will be background process runner https://github.com/WordPress/performance/pull/512, this makes use of job instance, so will be reviewed and merged post the above PR merge
- @spacedmonkey got 3 commits into core (, , ) and worked on PR #3178
- @kadamwhite: We’ve been doing some work on sites with very high comment volume around understanding the comment caching in core, because we began to actually see bottlenecks in cache performance with churn from comment cache eviction. Is anybody in this group specifically knowledgable about how WP handles comment caching?
- @spacedmonkey worked on this in the past
- @spacedmonkey: @furi3r has updated draft for new cache Site Health checks dev note, ready for another review
- @flixos90 will have another look
- Needs Discussion (8 issues)
- We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
- @mehulkaklotar is working on proposal for Plugin Check plugin. Right now, we would include minimal checks in the plugin that is included in the wporg-code-analysis and check the error log for any warnings, notices when plugin activated. I would love to hear suggestions about Github action that we will provide as an action that developers can use into their plugin repo.
- @spacedmonkey: Next steps for Dominant color feature (continued from last week)
- @pbearne: Are we all happy to merge the theme flag version?
- @flixos90: I think there were still some open questions and research to do on the perceived performance improvement
- @spacedmonkey: What are those questions? It comes down to the fact, we can’t move the performance benefit when it comes to metrics. But the benefit is more about what the users sees. That benefit is not an easy one to prove with numbers. It is more like a feeling of speed.
- @flixos90: Agreed, it’s certainly more challenging to prove anything regarding perceived performance. I don’t know but there is research on how “good” the LQIP perceived performance benefit is – so at least in theory there is something to unpack there for the dominant color perceived performance benefit as well. Maybe it’s a bit of a stretch to have us to UX research around that, which may be the only thing we could do in terms of research. At this point, I’m not opposed to it landing in core, but I’m also not sold on it.
- @spacedmonkey: I consider dominant color like other meta data we generate, so why not this? It could be helpful for theme developers.