Performance Chat Summary: 28 March 2023
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- None today
Priority Projects
Server Response Time
Contributors: @joemcgill @spacedmonkey @aristath
- @spacedmonkey worked on several tickets:
- For review:
- Ready to commit:
- New tickets:
- My two focuses, get lazy loading meta across the line for term meta (working on comment meta) and implementing wp_cache_get_multiple in more places in core
- @aristath work continues in the SQLite project – as well as the php autoloader for wp-core
- @joemcgill I’m just wrapping up an initial round of profiling observations, and plan to have something written up to share soon. Some highlights are that there are lots of places where we could try to reduce the use of file system reads associated with block registration and template rendering that we wanna look into. There is also a potential opportunity for some improvements to the way translations are being handled and classic seems that we also want to review.
- @spacedmonkey already has some fixes in the works for some issues we discovered while comparing notes. I continue to be somewhat hampered by only being able to use one arm, but I’m working through it.
- @rmccue As an aside, I noticed that the method of merging translation files in memory is probably suboptimal and we might be able to avoid that. (I’ve been reimplementing pomo in native code, and noticed it there)
Database Optimization
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
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.
Images
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 haveloading="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
sizesattribute.
Measurement
Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27
- No updates
Ecosystem Tools
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
Contributors: @flixos90 @mukesh27 @10upsimon
- @mukesh27 We’ve almost finished engineering for Milestone 1 tasks and all PRs in final review. If anyone has some capacity please review
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 https://core.trac.wordpress.org/ticket/58000
- @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
- @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.
Our next chat will be held on Tuesday, April 4, 2023 at 15:00 UTC in the #core-performance channel in Slack.