Performance Chat Summary: 2 May 2023

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

Announcements

  • Proposal for using fetchpriority to enhance LCP image performance published

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

  • @spacedmonkey: Committed [55701] and [55702]
  • @spacedmonkey has been working on #58196
    • Could have the possibility to have 6-10% of server time for block themes
    • @flixos90: There are some conflicting metrics on that last one. We have to figure out why your metrics show such good values while mine don’t show any notable change. I tested with 6.2 (not trunk)
      and didn’t see any performance impact
    • @spacedmonkey: I think it related to changes in trunk
    • @johnbillion: The ticket is now about adding caching (see new comment and new PR)
    • @spacedmonkey and @flixos90 to follow up with additional benchmarks to determine why the benchmark results differ so much

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

  • @spacedmonkey plans to commit lazy loading of comment meta everywhere, today or tomorrow
    • All other types, like user and post meta are so heavily used ( user meta == capabilities and post meta, post thumbnails ), that it not really worth lazy loading it
  • @xavivars had a couple of comments regarding the SQLite integration
    • @xavivars: I know it has been discussed previously that this may not be a “performance” project, but only something related to the work here, so not sure if this is the relevant forum for that, or there’s a better place for it
    • @flixos90: Yes, just to recap the above conversation from last week: The SQLite plugin / PL module will going forward no longer be directly associated with the performance team. We’ll still be supporting the project, but it will be decoupled from the WordPress/performance repository and the Performance Lab plugin
    • @flixos90: Probably best to raise in the plugin’s GitHub repository
    • @xavivars: It may be worth to remove it from https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization (or make that decision explicit in the roadmap)
    • @flixos90: Good point. Let’s raise that again next week when more people are around to discuss. Maybe we could change it to support the project rather than driving it, or something like that.

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @flixos90 would like to share that there is now a pull request for the new script loading strategy https://github.com/WordPress/wordpress-develop/pull/4391
    • @westonruter: In that pull request for Script Loading Strategies, identified what may be missing support for async scripts having dependencies. I put together an Async Library Script Loading Demo that demonstrates how async scripts could indeed have dependencies. So I’d like it if anyone could affirm my findings for the need for async scripts to be able to have dependencies/dependents. Feel free to just comment on the PR. Since 10up is not here, it doesn’t make much sense to chat about it right now.
    • @flixos90: I’ll have to take a closer look. Let’s continue discussing, but I’d like to note that this could also happen in a separate follow up enhancement. It depends a bit on how complex it is and how much it increases the scope of the current effort I’d say. We can always iterate, and not supporting async with dependencies could only be the first iteration
    • @westonruter: From what I can see, it’s more about just copying the same logic in place for defer. Currently there’s a check that just bails async entirely if there are deps
    • @flixos90: When the current implementation was originally defined, it was noted that by default async scripts don’t execute necessarily in the same order their tags are printed on the page.
    • @westonruter: When async scripts have dependencies, the order is explicitly not significant. It’s up to the library to ensure that the logic is executed in the right order. You can see in my demo when you get a chance. So it’s less about the execution order as much as being able to automatically get a bundle of scripts printed
    • @flixos90: Yeah, but I feel that is what complicates things. We would have to assume the script that uses async does the right thing, whereas so far with how the strategies are handled, WordPress will ensure it loads things in the right order
    • @westonruter: Since it is opt-in by developers, I don’t see it being an issue.
    • @flixos90: I agree that this is something worth supporting in WordPress, but supporting it has different implications for developers than what is supported by the current PR. So I would see that as a separate enhancement as it requires its own level of discussions. On a technical level we could easily support it it seems, but the implications are different
    • To be discussed further
    • @westonruter: Another point I wanted to raise: for that same pull request, I also proposed the elimination of manual script tag construction in WP_Scripts to improve readability, increase robustness, and facilitate CSP in scripts printed by WordPress core. Any concerns about using those script tag construction helpers in WP_Scripts? It’s not clear why they weren’t utilized when they were introduced.
    • @johnbillion: +1 to that, those functions haven’t gotten much use since they were introduced
    • @flixos90: Yeah I agree we should definitely use them
    • @flixos90: It would be great to get additional code review feedback this week, just please be conscious that Simon who has been leading the work on the PR is out this week, so it may only be next week that he’ll get back to it

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @flixos90: Last week I opened and milestoned several Trac tickets to enhance core’s lazy-loading logic:
    • #58211
    • #58212
    • #58089
    • #56588
    • #58213
    • These enhancements will benefit an eventual fetchpriority implementation as well. The idea is that the latter should therefore only happen after those enhancements have landed.

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • No updates

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

  • @flixos90: We’re still awaiting approval for the Fetchpriority standalone plugin repository, as the plugin review team is currently seeing notable delays. Fingers crossed we get an approval soon
  • @flixos90: Other than that, we’ve started thinking about what the implementation for a Milestone 2 (actually removing the modules from PL) could look like, see the overview issue description for sub-issues

Open Floor

  • @westonruter: On the topic of CSS, there’s Felix’s Gutenberg issue to load less CSS for core blocks by only printing the CSS for the blocks used on the page, here specifically for classic themes. I identified some challenges with inlining CSS with rendered blocks. I suggested a (probably controversial) alternative using output buffering. Here’s a proof of concept plugin. Maybe page output buffering now would be less controversial since it’s essentially how block themes are working?
    • @spacedmonkey: I am not a fan of output style tags inline. I feel like that would have side effects we could do know about. ATM, we have a head and footer styles / scripts. I was wonder if we could add a enqueue after every set of blocks, so widget blocks, post content and block theme. If it was an opt-in feature and all core blocks opt-in, that could go a long way.
    • @westonruter: Inlining I think is a no-go, for the reasons I identified
    • @spacedmonkey: Could we inline that at the start / end of post content?
    • @westonruter: That would probably resolve the issue with inlining breaking CSS selectors. But not all. For example, if you have div.entry-content > p:first-child, inlining would break this (edited). And if the CSS were at the end of the post content, then this would be the same problem as we have right now with the styles being printed in the footer: the potential for flash-of-unstyled-content
    • @spacedmonkey: So we need some other hook to output the scripts / styles in. Outside of the context of the content. In block themes we could add that but if might an opt-in for classic themes.
    • @westonruter: IMO, an opt-in for classic themes would take a long time to get adoption, and it doesn’t seem quite right if the future focus is on block themes. I’m not sure how the hook would work in practice either. Block themes are able to solve this problem by “output buffering” the content (not using ob, but rather just storing the content in memory for do_blocks). If output buffering could be used in classic themes, then we’d be able to hoist footer styles to the head in the same way, easily.

Our next chat will be held on Tuesday, May 9, 2023 at 15:00 UTC in the #core-performance channel in Slack.

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

Leave a Reply

Your email address will not be published. Required fields are marked *