Performance Chat Summary: 28 March 2023

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


  • None today

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

  • @olliejones Work continues on SQLite, next is to load woocommerce and beat on it.
    • Future project: identify as many places in core where the SQL is non-portable MySQL specific stuff and work on making it standard. Should that be a TRAC ticket?
    • @joemcgill I definitely think that having trac tickets that describe any improvements you’d like to see made would be useful.

JavaScript & CSS

Link to roadmap projects

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @10upsimon We are addressing the issue(s) around script concatenation, work is in progress and in the final stages of review, with minor iterations ongoing. Unit tests are being implemented to validate the approach and should be ready for final review today or tomorrow.
    • We are entering into a more holistic/overall code review of work done to date, essentially a code review of all work done thus far as part of the epic. Minor iteration is anticipated as part of this review process and will be executed as required.
    • Work can be seen here
    • Various tests/testing scenarios will be undertaken prior to submitting a final pull request against.


Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @flixos90 I have been continuing on the lazy-loading exploration and am getting close to opening Trac tickets for the individual pieces of work
    • To clarify, this is about avoiding to lazy-load LCP images, or rather in-viewport images in general
  • @flixos90 I have also been thinking a bit about the fetchpriority="high" feature for which we already have a module. One thing that we may need to iterate on there is that it just adds the attribute to whichever first image doesn’t have loading="lazy". This is not terrible, but it’s also probably not the best way to go about it, since the two attributes should not simply be mutually exclusive. The guidance is rather:
    • fetchpriority="high" should be only on the LCP image.
    • loading="lazy" should be omitted on images above the fold (i.e. potentially more images than just the LCP image).
  • @joemcgill I am in the very early stages of looking into ways we can improve the way WordPress calculates the sizes attribute.


Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • No updates

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger We have 2 tasks remaining for the Plugin Checker infrastructure with plans to complete this week. Once done, we will start performing initial testing and review  the infrastructure holistically before working on the additional checks. Progress can be seen on the GitHub repo here. As always, feel free to take a look and leave any thoughts/ideas you may have in the repo. Thanks!

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

New Projects / Proposals

  • @spacedmonkey Just flagging, I want to get the core unit tests running against redis. In my research, more hosts are using redis then memcache, so we could test against this and change our thinking of object caching in WP space from memcache to redis
    • @olliejones fwiw the SQlite Object Cache plugin has extensive perf. instrumentation built in.

Open Floor

  • @rmccue Re SQLite, I’m moderately concerned about the potential performance impact that introducing another layer of abstraction may introduce there. A traditional reason that WP hasn’t been DB-independent is because of (theoretical) performance gains by tightly coupling the two and taking advantage of that. (Which are assumptions I think do need to be tested.) I realise I’m coming in late to this, but I guess I’m just not seeing how the SQLite work ties into performance specifically. (I see a clear case for the non-performance benefits.)
    • @aristath Well, I admit that the tie between SQLite and performance is a bit weird… but the way I see it, it comes down to this: on a small, lower-end server, the server’s resources are shared between a php server, apache, and a MySQL server. By using SQLite, the server can allocate its limited resources to php and therefore achieve better performance.
      It’s better for sustainability mostly, and for performance on smaller sites (that usually are hosted on cheap servers) the performance gains will be there
    • @rmccue I can see how eliminating the latency and translation between two separate servers for PHP and MySQL could help performance, not sure of the overhead if it’s on the same server; that said, it feels like the primary goals of the project are not performance related
    • @olliejones It might ??? be a good idea sometime to spin off a team to do dbms-independence work, the target of which would be support for SQL Server, postgreSQL, SQLite, and, gag, Oracle. Having those would help scale up WordPress sites. postgreSQL especially because it can do wildcard searches with indexes. But that imaginary project’s connection to this team is a bit tenuous, as you mention.
    • Discussions here continued beyond the end of the meeting

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

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

Leave a Reply

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