Title: Performance Chat Summary: 25 April 2023 Author: Emily Clarke Published: April 25, 2023 --- [ ](https://profiles.wordpress.org/clarkeemily/) [Emily Clarke](https://profiles.wordpress.org/clarkeemily/) 4:03 pm _on_ April 25, 2023 Tags: [core-media ( 116 )](https://make.wordpress.org/core/tag/core-media/), [core-performance ( 152 )](https://make.wordpress.org/core/tag/core-performance/), [performance ( 419 )](https://make.wordpress.org/core/tag/performance/), [performance-chat ( 345 )](https://make.wordpress.org/core/tag/performance-chat/), [summary ( 981 )](https://make.wordpress.org/core/tag/summary/)    # Performance Chat Summary: 25 April 2023 [Meeting agenda here](https://make.wordpress.org/core/2023/04/25/performance-chat-agenda-25-april-2023/) and the full chat log is available [beginning here on Slack](https://wordpress.slack.com/archives/C02KGN5K076/p1682434772025969). ## Announcements * Updated the cadence of bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs to be every 2 weeks– next one scheduled for [April 26, 2023 at 15:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230426T1500). * [@flixos90](https://profiles.wordpress.org/flixos90/) Also briefly sharing that I just published a performance retrospective post on WP 6.2 that I had been working on over the past few weeks: [https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/](https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/) It highlights some of the key aspects which changed in 6.2 in how we dealt with performance and also summarizes high level numbers. It can be seen as somewhat complementing [https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/](https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/), at a higher level however without looking as much at specific improvements. * Discussion regarding the **decoupling of the SQLite pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost- based plugin from a third-party. **from the performance lab work. In reference to [this conversation](https://wordpress.slack.com/archives/C02KGN5K076/p1680019422571839) that came up in a previous performance chat. Would love to have an open discussion about peoples preferences here and whether we do decouple this? - [@olliejones](https://profiles.wordpress.org/olliejones/) I favor that approach. It will usually be deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. independently of the stuff in PL. - [@10upsimon](https://profiles.wordpress.org/10upsimon/) I tend to lean more toward an agreement with [@rmccue](https://profiles.wordpress.org/rmccue/) in that SQLite is not necessarily performance improvements focused (or at least that is not the primary goal), and probably belongs outside of the realm of the performance lab work. - [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) To be clear, I think that performance team should continue to support SQlite getting into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., to much sure it done in a performant way. But SQlite is not a performance benefit on the face of it, so it is confusing why we part of performance lab plugin. - [@rmccue](https://profiles.wordpress.org/rmccue/) Yeah, that was basically my thought; I think it’s beneficial all-round to separate it out (but with performance still consulting as [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) says) - [@olliejones](https://profiles.wordpress.org/olliejones/) yes, having SQLite headed for core is good. I believe the issue is about monorepo and multifunction plugins on the one hand and a separate repo and plugin on the other. - [@aristath](https://profiles.wordpress.org/aristath/) I agree with what was mentioned above 100%. SQLite _can_ be related to performance, but is not in itself a “performance” module/plugin. It should be developed in collaboration with the performance team since it can have a big impact, but I’d vote to decouple it from the performance-lab plugin - [@olliejones](https://profiles.wordpress.org/olliejones/) Maybe in a parallel universe or another year, there can be a separate database team. But for now the perf. team has the talent. - [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) If you want to setup a meeting for a database team, that could work. Many component meetings have less than 5 people. - [@flixos90](https://profiles.wordpress.org/flixos90/) To clarify, this conversation is slightly different and mostly unrelated to the “unbundling Performance Lab plugin” effort. While we are publishing other PL modules as standalone plugins, those standalone plugins will still be directly associated with the performance team, developed in the monorepo, referenced from the PL main plugin etc. Removing / decoupling SQLite from PL would be different: We would still support getting the plugin towards WP core of course, but it wouldn’t be in any way connected to PL anymore. Maybe that was clear, but just in case. - Next steps clarification: * [@aristath](https://profiles.wordpress.org/aristath/) I think the only thing to do here would be to remove the module from PL, and add a notice so in case the user previously had the module activated, they’ll be prompted to install the standalone plugin * [@joemcgill](https://profiles.wordpress.org/joemcgill/) I assume we’ll remove the module from the performance lab plugin in the same release where we remove other modules. How we handle the transition so as to not break any active sites, is not clear to me at the moment. * [@olliejones](https://profiles.wordpress.org/olliejones/) Do we have any usage telemetry to help guide that decision? * [@flixos90](https://profiles.wordpress.org/flixos90/) Potentially. As mentioned, I think this conversation is decoupled from the general PL unbundling effort, so we could do it at the same time, but also sooner. I would love to find a way to make the transition smooth though. For sites that already have the SQLite module active, we should probably recommend activating the SQLite plugin before deactivating the feature. * [@aristath](https://profiles.wordpress.org/aristath/) That’s a good idea… * [@flixos90](https://profiles.wordpress.org/flixos90/) Has anyone tried yet to activate the SQLite standalone plugin on a site where the PL SQLite module is already active? We need to make sure it doesn’t throw fatal errors - [@aristath](https://profiles.wordpress.org/aristath/) Adding it on my TODO list for tomorrow, though from what I recall I tried it last month and I there were no issues. I’ll need to test that again just to be sure, it’s been a long time * [@10upsimon](https://profiles.wordpress.org/10upsimon/) I feel strongly about not intentionally breaking users sites, however few are using it. Perhaps we need to defer the removal to 2 versions from now, and raise a notice or similar in the adminadmin (and super admin) making it very clear that from version _n_ it will no longer be supported as a core PL module. - [@flixos90](https://profiles.wordpress.org/flixos90/) agreed [@10upsimon](https://profiles.wordpress.org/10upsimon/) adding though that for a smooth transition the plugin should be activated before deactivating the PL module, so we have to make sure that that is actually possible * [@joemcgill](https://profiles.wordpress.org/joemcgill/) A similar transition plan will be good for all of the modules, to be honest, even though SQLite is the most critical due to potential breakage. * [@flixos90](https://profiles.wordpress.org/flixos90/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) I think for the other modules we’ll handle that in a central effort as part of unbundling, but with SQLite it will now be bit different, since that plugin will not be referenced directly from PL in the future. But I agree it’s most critical there to have a smooth transition since switching back to a MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. [https://www.mysql.com](https://www.mysql.com/)/ MariaDB database accidentally will break any site that actually relies on SQLite right now ## Priority Projects ### Server Response Time [Link to roadmap projects](https://make.wordpress.org/performance/roadmap-2023/#category-server-response-time) Contributors: [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) [@aristath](https://profiles.wordpress.org/aristath/) * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) I landed lazy loading term metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. [https://github.com/WordPress/wordpress-develop/commit/2c6bf77a9e7532c6ac3a03502b44d108cae86179](https://github.com/WordPress/wordpress-develop/commit/2c6bf77a9e7532c6ac3a03502b44d108cae86179) - I hope to get comment meta in the next week. [https://github.com/WordPress/wordpress-develop/pull/4128](https://github.com/WordPress/wordpress-develop/pull/4128)– Code review welcome - Related to term meta, [https://github.com/WordPress/wordpress-develop/pull/4259](https://github.com/WordPress/wordpress-develop/pull/4259) also need code review - This saves around 15k calls to sanitise term function per page load - TLDR, there was no need to call `get_term` , we already had the term id, so just remove that - I also reviewed this – [https://github.com/WordPress/wordpress-develop/pull/4097](https://github.com/WordPress/wordpress-develop/pull/4097)( amazing work [@oandregal](https://profiles.wordpress.org/oandregal/)) - [@joemcgill](https://profiles.wordpress.org/joemcgill/) This is a huge one that I had noticed in my profiling research, so nice to see this already addressed! - [@10upsimon](https://profiles.wordpress.org/10upsimon/) Call me cheesy, but 15% _server time_ alone across many WP hosts is a positive contribution to the environment alone - [@mukesh27](https://profiles.wordpress.org/mukesh27/) With all this improvement, 6.3 is faster than 6.2 * [@flixos90](https://profiles.wordpress.org/flixos90/) Yeah, this alone will make blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme performance in 6.3 almost as much faster as it got faster in 6.2 - [@flixos90](https://profiles.wordpress.org/flixos90/) Certainly the highest performance improvement in a single PR that I’ve seen so far - [@joemcgill](https://profiles.wordpress.org/joemcgill/) Worth noting that the 15% improvement on that PR is compared against WP 6.1.1, not the commit prior to that one, so it would be interesting to A/B against the commit prior( if I’m reading the workflow correctly) * [@flixos90](https://profiles.wordpress.org/flixos90/) No, the 15% is against today’s `trunk`. The original metrics on the PR are incorrect, but then I measured it against `trunk` and that’s where the 15% come from ### Database Optimization [Link to roadmap projects](https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization) Contributors: [@aristath](https://profiles.wordpress.org/aristath/) [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) [@olliejones](https://profiles.wordpress.org/olliejones/) [@rjasdfiii](https://profiles.wordpress.org/rjasdfiii/) * [@olliejones](https://profiles.wordpress.org/olliejones/) I’ve been on the SQLite Object Cache, making it more useful for [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) hopefully – Nothing on the bigger SQLite project. * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) Not related to database, but object caching. I have been working WP CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. support new functionality object cache - [https://github.com/wp-cli/cache-command/issues/79](https://github.com/wp-cli/cache-command/issues/79) - [https://github.com/wp-cli/cache-command/issues/80](https://github.com/wp-cli/cache-command/issues/80) ### JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. 󠀁[https://www.javascript.com](https://www.javascript.com/)󠁿 & CSSCSS Cascading Style Sheets. [Link to roadmap project](https://make.wordpress.org/performance/roadmap-2023/#category-javascript-css) Contributors: [@mukesh27](https://profiles.wordpress.org/mukesh27/) [@10upsimon](https://profiles.wordpress.org/10upsimon/) [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) * [@10upsimon](https://profiles.wordpress.org/10upsimon/) Regarding “Enhancing the WP Scripts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. with a Loading Strategy”: - We’ve had a good amount of feedback and iteration on our draft PR - We’ve had some valuable feedback come in this week, so we’ll be addressing that with the goal of opening a PR against core later this week. Thanks [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) and [@westonruter](https://profiles.wordpress.org/westonruter/) for the invaluable feedback thus far (and to [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/)) - We’ve established a mostly approved documentation plan/roadmap, with slight ongoing tweaks thereto. Draft documentation and documentation updates can commence soon * [@flixos90](https://profiles.wordpress.org/flixos90/) One more thing regarding JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSS, last week I opened [https://github.com/WordPress/gutenberg/issues/49927](https://github.com/WordPress/gutenberg/issues/49927) to optimize how block CSS is loaded in classic themes (it’s great in block themes, but not so much for classic themes, and we can probably improve that). There have been some great conversations on that. [@aristath](https://profiles.wordpress.org/aristath/) has pointed out a detailed code example with how we could improve this by printing inline styles per block type right before the first block of each type is rendered - [@aristath](https://profiles.wordpress.org/aristath/) If you have some capacity to work on a PR, I think that would be a great next step - [@flixos90](https://profiles.wordpress.org/flixos90/) If we can find a solution that works reliably, maybe we can eventually even change the default behavior so that it’s no longer opt-in but just works out of the box  - [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) I have a PR for the above –  [https://github.com/spacedmonkey/wordpress-develop/tree/try/inline-styles](https://github.com/spacedmonkey/wordpress-develop/tree/try/inline-styles) It might be useful in discovery ### Images [Link to roadmap projects](https://make.wordpress.org/performance/roadmap-2023/#category-images) Contributors: [@flixos90](https://profiles.wordpress.org/flixos90/) [@thekt12](https://profiles.wordpress.org/thekt12/) [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) * No updates this week ### Measurement [Link to roadmap projects](https://make.wordpress.org/performance/roadmap-2023/#category-measurement) Contributors: [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) [@olliejones](https://profiles.wordpress.org/olliejones/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@mukesh27](https://profiles.wordpress.org/mukesh27/) * [@joemcgill](https://profiles.wordpress.org/joemcgill/) I’ve been working to prioritize a set of “next steps” for automated performance testing. For me, the“ next step” is to turn these tasks into tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets that we can address as capacity allows. - One of the big ones is to improve the stability of the results and make them more atomic, so we can use them to evaluate specific PRs (like the discussion we had earlier about the `get_block_templates` PR) ### Ecosystem Tools [Link to roadmap projects](https://make.wordpress.org/performance/roadmap-2023/#category-ecosystem-tools) Contributors: [@joegrainger](https://profiles.wordpress.org/joegrainger/) * [@joegrainger](https://profiles.wordpress.org/joegrainger/) We’re still progressing through the issues raised in the Plugin Checker Milestone 1 Review/QA and will continue to be working on these over the coming weeks. You can follow the progress on the [GitHub repo](https://github.com/10up/plugin-check/) and any thoughts/ ideas/comments are welcome. Thanks! * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) Got some feedback from the community – [https://github.com/10up/plugin-check/issues/153](https://github.com/10up/plugin-check/issues/153) ### Creating Standalone Plugins [Link to GitHub overview issue](https://github.com/WordPress/performance/issues/656) Contributors: [@flixos90](https://profiles.wordpress.org/flixos90/) [@mukesh27](https://profiles.wordpress.org/mukesh27/) [@10upsimon](https://profiles.wordpress.org/10upsimon/) * [@flixos90](https://profiles.wordpress.org/flixos90/) We’re still waiting to get the Fetchpriority standalone plugin approved, beyond that and then the same for Dominant Color, we have basically completed the work for “Milestone 1” in [https://github.com/WordPress/performance/issues/656](https://github.com/WordPress/performance/issues/656) - We should probably close [https://github.com/WordPress/performance/issues/661](https://github.com/WordPress/performance/issues/661) following the conversation earlier, or we can break it out as another issue to discuss how to remove SQLite from PL * [@flixos90](https://profiles.wordpress.org/flixos90/) Separately, we need to explore what we want the user experience for “Milestone 2” to look like, both in terms of the regular UIUI User interface of the PL plugin going forward (in which it controls certain plugins as well as the Site Health modules), and for a smooth migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. from the modules to remove to their standalone plugins ## New Projects / Proposals * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) I would love feedback on – [https://github.com/WordPress/performance/issues/718](https://github.com/WordPress/performance/issues/718) a new module proposal for adding object caching information to site health - I want to make it easier for users to understand what kind of object cache they are using and what features it supports. - Specially if your object cache drop in supports multiple gets. I got a lot of questions after this [article](https://xwp.co/object-caching-improvement-wordpress-6-2/) was published. # Open Floor * No updates **Our next chat will be held on [Tuesday, May 2, 2023 at 15:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230502T1500) in the [#core-performance channel](https://wordpress.slack.com/messages/core-performance/) in [Slack](https://make.wordpress.org/chat/).** [#core-media](https://make.wordpress.org/core/tag/core-media/), [#core-performance](https://make.wordpress.org/core/tag/core-performance/), [#performance](https://make.wordpress.org/core/tag/performance/), [#performance-chat](https://make.wordpress.org/core/tag/performance-chat/), [#summary](https://make.wordpress.org/core/tag/summary/) ### Share this: * [ Threads ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=threads) * [ Mastodon ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=mastodon) * [ Bluesky ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=bluesky) * [ X ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=x) * [ Facebook ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=facebook) * [ LinkedIn ](https://make.wordpress.org/core/2023/04/25/performance-chat-summary-25-april-2023/?share=linkedin) # Post navigation [← The benefits of prioritizing and measuring performance in WordPress 6.2](https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/) [Editor Chat Agenda: 26 April 2023 →](https://make.wordpress.org/core/2023/04/26/editor-chat-agenda-26-april-2023/)