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

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

  • @spacedmonkey worked on several tickets:
  • @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 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. 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 translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. 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

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 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/. specific stuff and work on making it standard. Should that be a TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.?
    • @joemcgill I definitely think that having trac tickets that describe any improvements you’d like to see made would be useful.

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/. & CSSCSS Cascading Style Sheets.

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.

Images

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.

Measurement

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 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/ or can be cost-based plugin from a third-party 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 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, apacheApache Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free., 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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

Performance Chat Summary: 21 March 2023

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

Announcements

  • Release the Performance Lab 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/ or can be cost-based plugin from a third-party 2.1.0 yesterday

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

  • @spacedmonkey I have been working on profiling translations and looking into how we can make them faster
  • @joemcgill working with @spacedmonkey on comparing notes this week on some initial profiling that we’ve done. I’m still struggling a bit to write all of this up in a shareable way, given that I’ve got one arm in a sling, but we should have some good progress to share by next week.
  • @spacedmonkey committed the following issues
  • @spacedmonkey On autoloading, I did some quick profiling on it and a seeing slower performance after the change. Around 5ms on a home page view.
    • @flixos90 Yeah that covers roughly with benchmarks I had done a few months back
    • @spacedmonkey I tested this – https://github.com/WordPress/wordpress-develop/pull/3470 There maybe benefits for other requests types, like REST APIs
    • @flixos90 Autoloading is tricky. There is probably some memory benefit of not loading as much PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher code, but we’ll have to assess the performance impact more. Of course autoloading is a good practice, but we also need a good argument to support getting this into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. And if it actually slows down server response time, I would say we shouldn’t push it. But more research needs to be done.

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

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/. & CSSCSS Cascading Style Sheets.

Link to roadmap projects

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @10upsimon gave his update on Enhancing the 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 ahead of time
    • Engineering for the epic as a whole has been completed and is in round 1 of code review and iteration – work can be seen here. We anticipate an iterative feedback and implementation loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. to continue into next week, followed by a full and final code and functional review of all work by EOW next week, thus concluding engineering and being in a state to consider and implement a core merge proposal mid-April.
    • A developer testing plan is currently in review, which aims to support testing efforts of all engineering work carried out. This includes validation of all unit tests introduced as part of said work, and defines functional testing approaches, of which popular WordPress themes and plugins are included as part thereof.
    • An approach for documentation (automated/code reference & community) has been discussed and is soon to be executed. Draft documentation items will be produced for review, with the aim of being released as soon after the core merge as possible.

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @adamsilverstein I have an update about the image comparison game/study I ran at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia. In the game people compare two images generated by WordPress to the original uploaded image. The image quality setting between the images varies and the format changes as well, so far I’m testing with WebP and JPEG and quality settings from 70 to 90.
  • @adamsilverstein Here is a doc with a summary of the results and a bit of analysis as well as a link to a sheet with the raw data:
    • To summarize the results though:
      • People loved playing the game and also became super engaged about images
      • We didn’t gather enough data to have statistically meaningful results
      • Anecdotally, most people struggled to tell which image was closer to the original
  • @joemcgill I’m starting a high-level review of our approach to calculating the sizes attribute for images in WordPress this week. It’s the first step for me to work on ways we can improve some of the base assumptions that the current approach takes and see if we can improve it now that we have more information and 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. themes.
  • @flixos90 I have been researching the remaining problems with lazy-loaded LCP images, with some good findings. I should have something to share in a week or two. Likely this will be in form of a few new TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets with things we should fix. It’s worth noting that still more than 20% of LCP images today are being lazy-loaded with the loading attribute. This is where WordPress core can help.
    • (Additionally ~10% of LCP images today are lazy-loaded through other custom JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. technologies, so that’s something where plugins and libraries will have to do the work. Maybe something we can help facilitate)

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • @joemcgill Automated performance timing continues to be collected and was useful while reviewing potential performance regressions during release candidates for 6.2. We are starting to put some thought into what the next improvements should be. If anyone has specific ideas they think should be considered, I’d certainly love input. Will share some ideas in the coming weeks.
  • @adamsilverstein I wanted to link to a Drupal ticketticket Created for both bug reports and feature development on the bug tracker. where their  team is working on adding automated performance testing for Drupal  core: https://www.drupal.org/project/drupal/issues/3346765. The approach they are taking is quite different, with a plan to store performance traces using a tool like Open Telemetry or “jaeger” (new to me) – although they are starting more simply like we have. I feel like it is worth following their effort as we can always learn from each other

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger We are working on the final elements on the Plugin Checker infrastructure with plans to complete this by the end of the week. From next week we’ll be performing initial testing and review of the infrastructure before working on the additional checks. Progress as always can be seen on the GitHub repo here. Please feel free to take a look and leave any thoughts/ideas you may have in the repo.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

New Projects / Proposals

  • A polite reminder, our 2023 roadmap is intentionally broad. Despite there being clear workstreams envisioned within the highlighted priorities, the team aims to support contributors with additional related ideas

Open Floor

  • n/a

Our next chat will be held on Tuesday, March 28, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 14 March 2023

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

Announcements

  • As agreed in last weeks chat, this week we are following the new agenda structure below that is more aligned with our 2023 roadmap
  • During each priority project update, we will aim to tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) the individuals who contributed suggestions for that priority project in the 2023 roadmap, to get any updates on progress

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 on the SQLite database integration continues. Lots of tiny details transliterating one irregular SQL grammar to another. Nothing big to report.

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/. & CSSCSS Cascading Style Sheets.

Link to roadmap projects

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @10upsimon We’re making progress on some of the final implementation details related to handling inline scripts, and doing some internal testing and research into how other projects are already implementing async/defer to look for possible conflicts. We should have something to share in a couple of weeks. In the meantime, we’d appreciate any examples you have of projects that are manually adding async/defer, so we can check them against our approach.

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @flixos90 I have been researching remaining problems with lazy-loaded LCP images in WordPress sites in the last week, will continue to do so today. I’m using HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Archive to identify the most common problems and look at specific sites for samples to dig further
  • @flixos90 Noting that the enhancements that will hopefully come out of this work will benefit the fetchpriority="high" work as well
  • @adamsilverstein quick update from me: at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia a few weeks ago, I ran an “image comparison game” where users picked from two images (generated in WordPress at different compression levels and in WebP or JPEG) trying to tell which one was closer to the original. we had around 50 “choices” registered which isn’t much, but in any case I’m planning to analyze that data this week and should have some sort of results to share next week.

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • @clarkeemily we did have ‘Automated performance testing has been committed to the WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. repo https://core.trac.wordpress.org/changeset/55459‘ highlighted last week
  • @joemcgill We’re successfully getting automated performance data on every commit to core now, which is a cool milestone. I expect that we’ll continue to improve those capabilities over time, but this is a nice starting point.

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger We plan to complete the infrastructure for the 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/ or can be cost-based plugin from a third-party Checker by the end of next week. Once complete we will start to perform some initial testing and review the infrastructure before working on the additional checks. Progress can be seen on the GitHub repo here. Please feel free to take a look and leave any thoughts/ideas you may have in the repo.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

New Projects / Proposals

  • n/a

Open Floor

  • @spacedmonkey Can we talk about this – ‘Explore and assess 6.2 server-side performance regressionshttps://core.trac.wordpress.org/ticket/57916
    • @flixos90 Happy to answer any questions on the data I gathered
    • @spacedmonkey Doing some research, realpath seems to be taking up a lot of resources
    • @flixos90 Is the realpath() usage something that was introduced in 6.2?
    • @spacedmonkey No, but I think it has been made worse.
    • @joemcgill After thinking about the original issue some more, I’m wondering if what @flixos90 observed is mainly a side-effect of things being moved around in the application lifecycle, which means that there are more callbacks firing on init, but overall the total response time is still an improvement over 6.1.X.
    • @flixos90 The overall total response time for classic themes is now actually worse in 6.2 than 6.1
    • @joemcgill That’s not what I’m seeing in our automated tests though.
    • @spacedmonkey It might be related to this – https://github.com/WordPress/wordpress-develop/commit/6d0a691b84d411813378f1983a0a87bf78a1ccad
    • @flixos90 Yeah I also didn’t see that in my previous tests. However what I have consistently seen is init being slower than in 6.1
    • @flixos90 FWIW, the automated tests are running core trunk . The tests I have been conducting are using built ZIP releases of the Betas and RCs. Not sure how relevant that is, but it may make a difference
    • @joemcgill Even in the latest run, 6.2 seems like an improvement.
    • @flixos90 The ZIP files are in principle closer to the real world experience, that’s why I’ve been using them in addition to the development repository
    • @spacedmonkey my test runs Slack thread
    • @joemcgill Zips should be built from the build folder, which is what the automated tests are testing
    • @flixos90 request for @spacedmonkey or @joemcgill to run the comparison between 6.1.1 production ZIP and 6.2-RC1 ZIP on your machines? Just to validate, maybe something is off on my environment
    • @joemcgill Happy to double check using local profiling at the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. tester plugin later today.
    • @spacedmonkey I might try using Local envoirment and other tools and see if i can reproduce
    • @johnbillion Are all these tests using the theme unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. data?
      • @spacedmonkey I use Fakerpress to make mock data
      • @joemcgill The automated tests are. Not sure about how others are testing.
    • @flixos90 Good call @johnbillion My own local performance testing I’ve done only with the regular WP content (“Hello world”), nothing added. I know that’s not representative of real-world experience, but @joemcgill and @spacedmonkey please try to use that too for specifically the attempt to validate what I’m seeing on my end
    • @joemcgill If other folks can do A/B comparisons of the total response time for WP 6.1.1 vs 6.2-RC1 and share data on that issue, it could certainly help.
    • @spacedmonkey Fakerpress is great for generating posts from multiple authors, adds comments, terms and users.
    • @flixos90 So to summarize, just to reproduce, I’m seeing the regression locally in this environment:
      • between 6.1.1 and 6.2-RC1
      • a site with LocalWP
      • using TT1 theme
      • using Performance Lab plugin for Server-Timing, with no modules enabled
      • no content on the site other than what a clean WP core install gives you
    • Also see this sheet for more details.
    • @johnbillion Are you able to test again with the theme unit test data Felix? That way we have a somewhat unified set of data that’s in use for the tests
    • @flixos90 I certainly can. That said though, we also would still need to validate why I see a regression with the default content, so I would appreciate if someone else could run that on their end
    • @spacedmonkey https://codex.wordpress.org/Theme_Unit_Test
    • @flixos90 Last but not least, I want to highlight something here (which I tried to also call out on the ticketticket Created for both bug reports and feature development on the bug tracker.): Regardless of whether WP 6.2 is faster than 6.1, init is slower than before for classic themes. That has surfaced in all performance benchmarks I have done up to date. So while we should validate the overall test results, we should look into what is going on in init and why it has become worse in 6.2
    • @flixos90 See https://docs.google.com/spreadsheets/d/1LroIJoYz-O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=0 for example. In my new data https://docs.google.com/spreadsheets/d/1LroIJoYz-O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=1935935734 this is just more pronounced (which again could be due to a problem on my setup that wasn’t there before). If you want to get those more detailed Server-Timing metrics in your local environment, you can use https://gist.github.com/felixarntz/63c05392dbf7d51cc7f8f4a424b1ff39 for example
    • @joemcgill Back to my initial comment. I am curious if this is a side effect of some things being refactored during this release which has caused more work to be done on the init callback that was previously happening elsewhere. It could be that it’s fine that we’re doing more work on init than we were before if the overall execution time is improved.
    • @flixos90 Potentially that’s the case, in which case the “regression” would be fine. But we need to validate that
    • @joemcgill I think it would be helpful to review what is hooked to init in 6.2 vs 6.1 and compare differences.
    • @flixos90 I did that in https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit#gid=879358988
    • @spacedmonkey register_block_type_from_metadata -> register_block_script_handle -> realpath. register_block_type_from_metadata Are hooked into init
    • @flixos90 So we need to check how those functions’ code changed
  • @johnbillion Briefly from me for a core issue related to performance: I’ve been working to remove use of the now-deprecated SQL_CALC_FOUND_ROWS in core, starting with its use in WP_Query. PR here: https://github.com/WordPress/wordpress-develop/pull/3863 which continues work from a couple older PRs. There are a few outstanding items to address, I might ask for some help from interested parties on the performance team if I can’t make much progress myself over the next few weeks. Apart from that, the more eyes the merrier on this change!
  • @flixos90 Last but not least: Next Monday is the release of the Performance Lab plugin 2.1.0, so we need to get a few PRs ready
  • @flixos90 I have been working on a fix for the object-cache.php compatibility issues which I’m about to open a PR for. Would be great to get some reviews today/tomorrow so we can include it in 2.1.0

Our next chat will be held on Tuesday, March 21, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 7 March 2023

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

Announcements

  • Proposed update to our chat structure for future weeks to be focused more around our 2023 performance roadmap
    • @flixos90 Focusing on the roadmap items sounds great to me. I’d say some of those points are rather broad though, maybe we can still go a bit more granular per project. There’s also some projects on the roadmap that are well underway while others are merely ideas that may not see a lot of updates soon, so we need to think about how to balance that
      • @clarkeemily I think that would be the plan, to dive more into those sub-bullet point per priority as listed in our roadmap (sorry, should have clarified that!)
    • This was agreed – for future meetings, the agenda will be structured below, with the goal of diving deeper into each roadmap priority sub-project
      • Announcements
      • Roadmap priorities:
        • Server response time
        • Database optimization
        • 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/. & CSSCSS Cascading Style Sheets.
        • Images
        • Measurement
        • Ecosystem tools
      • Infrastructure
      • Open floor

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger We are working towards completing the infrastructure for the 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/ or can be cost-based plugin from a third-party Checker and once done we’ll have a working plugin with some initial checks. At that point we’ll be taking the time to do some initial testing, review the infrastructure and make any changes before working on the additional checks. You can see progress on the GitHub repo here. Feel free to leave any thoughts/ideas you may have in the repo too!
  • @mukesh27 Automated performance testing has been committed to the WP core repo https://core.trac.wordpress.org/changeset/55459
    • @joemcgill The first run of the new performance workflow ran perfectly, except for successfully posting results to the codevitals.run dashboard. I assume it’s because we either have an incorrect project token or some other change was made to the 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. there. I’ll follow up with @youknowriad to get this working when he’s back around. Regardless, this is pretty cool to see (copied over from Mar 3)

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSS

@aristath @sergiomdgomes

GitHub project

  • @10upsimon update on WRT Script Loading Strategy:
    • Trac Ticket 12009 has been updated with a comment describing the work being carried out, and brief instructions on where and how to follow progress. We encourage early feedback.
    • Work on milestone 2 issues has been completed, and all code approved, unit tested and functionally tested. Further holistic testing is underway but is not a blockerblocker A bug which is so severe that it blocks a release. to progress.
    • Milestone 3 work is underway and tracking well.
    • We continue Investigating potential interoperability issues to assess how developers most commonly solve for the async and defer script applications in the absence of this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. that is underway, so that we can better understand if and how we need to potentially solve for this in the interest of preserving the work we are doing in core, and being mindful of backward compatibility.

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones Work continues on the SQLite project. Starting to look at popular plugins with their own SQL. (Thousands of them.) Trying to get the top ten to work. (WooCommerce, Yoast, etc).
    • The work is happening in the standalone repo. Migrating to the monorepo is still in the future.
    • @spacedmonkey You can use https://wpdirectory.net/ to find plugins that do custom database queries

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @mukesh27 started working on milestone 1 tasks for creating a standalone plugin.
    • PR 662 for implementing CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. command for a build process to transform modules into standalone plugins is ready for review
    • @flixos90 I’ll give the above another review today, really excited to see it moving forward

Feedback requested

Open Floor

  • @olliejones Is there any intentional liaison between us and #hosting-community
    • @spacedmonkey I know the hosting community is keeping on eye on our work, see https://wordpress.slack.com/archives/C3D6T7F8Q/p1677695456489839
    • @spacedmonkey I meet with some hosting companies at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia, but we could do a better job at building bridges between these teams.
      • @olliejones Can you persuade your contacts to lurk here, or identify themselves? Would love to know what they wish they had from performance.
    • @olliejones I would really like to have a conversation with a couple of hosting dbms-ops people, to learn more about their problems and how we can help address them.
    • @spacedmonkey there are people like @desrosj (Bluehost) and @mikeschroder (GoDaddy) that might be able to help
    • @johnbillion that’s a conversation worth having with agencies too
    • @spacedmonkey Humanmade does a lot of hosting with their platform
    • @spacedmonkey can make some intros to help @olliejones
  • @tillkruess raised a concern over comments on https://github.com/WordPress/performance/issues/132
    • @spacedmonkey The TLDR of 132, is that as we support older version of DBs, we can’t rollout the indexes? Can we do a progressive enhancement for newer DBs?
    • @olliejones To oversimplify, (191) indexes don’t do what big sites need. “Progressive enhancement” means “two versions of the database definition”. Is there testing capability? https://www.plumislandmedia.net/index-wp-mysql-for-speed/wordpresss-prefix-keys/ is a writeup on the topic.
    • @spacedmonkey There are other examples of progressive enhancements in core. And there is a different schema for the user table for multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site for example. Any thoughts on progressive enhancements like this @johnbillion
    • @tillkruess I’m strongly in favor of databases indices as an opt-in feature.
    • @olliejones In schema.php we’d put if (the database uses the barracuda storage engine ) { lots of data definition language }
    • @johnbillion The answer I always give when talking about introducing optional features is, is the intended user capable of making an informed decision about whether or not to enable the feature? If the “user” in this context is a large scale web host then yes, if the “user” is a freelance integrator without much SQL experience then no. So if we can guide an informed decision to be made then I’m in favor of these indices enhancements being opt-in, as much as I’m not a fan of differing schemas the benefit outweighs that here IMO

Our next chat will be held on Tuesday, March 14, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 28 February 2023

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

Announcements

  • Team rep nomination decision – consensus from the group is to skip the voting stage and allocate @clarkeemily as Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts., as there were no other nominees
  • WordPress 6.2 performance improvements:
    • @flixos90 it’s just great news: WordPress 6.2 is notably faster than 6.1 :partying_face:
    • Both on the server-side and the client-side: See Web Vitals and the more granular server-side Server-Timing metrics
    • All these are based on lab metrics for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but after several weeks of different testing methodologies being tried, I believe we now have an approach that works well for this type of benchmarking (I plan to document it soon)
    • One note here is to please be mindful that those are metrics for just WordPress core. Since actual WordPress sites will be heavily influenced by the theme and plugins, the real improvements across the WordPress ecosystem will not be that high
    • With that said, it’s a major accomplishment for the WordPress core release itself, and WordPress core getting that much faster certainly helps all sites out there to get at least a little bit faster

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • No updates this week

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger we are working towards completing the infrastructure for the 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/ or can be cost-based plugin from a third-party Checker. Once done we will be at a point where we’ll have a working plugin running with initial checks. You can see progress on the GitHub repo here. Feel free to leave any thoughts/ideas you may have in that repo too.
  • @mukesh27 Automated performance testing core PR is ready for review

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • @10upsimon update on WRT Script Loading Strategy:
    • Engineering work for Milestone 1 has been completed and issues closed out.
    • Engineering for Milestone 2 is almost complete and in a state of iteration and ongoing revision. It is almost ready for approval after which functional testing of Milestone 2 will commence
    • On completion of Milestone 2, we will have a functional means of executing loading strategies on registered scripts, and work on Milestone 3 (relating to inline scripts) will commence.
    • The epic is tracking well, with no concerns from my part (here’s the repo for folks to view)
    • @joemcgill That’s all pre-work on an approach for #12009 that we’re hoping to have ready for 6.3. I think Simon plans on posting an update to that ticketticket Created for both bug reports and feature development on the bug tracker. that briefly outlines the approach later this week.

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones SQLite: Lots of compatibility issues https://github.com/WordPress/performance/issues?q=is%3Aissue+is%3Aopen+label%3A%22%5BModule%5D+SQLite%22 are coming up. This isn’t surprising considering two decades’ history in core using one particular SQL dialect, then trying to add another.
  • We’ll need at least one epic to turn this from experimental stuff into deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. stuff.
  • Is it possible wordpress.com people have a closed-source compatibility layer for something like Oracle or postgres that we can learn from?
  • @aristath Currently OTP, but just a quick update on SQLite: @zieladam and I completely rewrote the implementation using a lexer and a parser. Almost all WordPress phpunit tests are passing now, and all the issues that have already been reported, have already been resolved. The implementation has already been released in the standalone plugin, and I’ll be back porting the changes to the PL plugin as soon as we push a couple more minor tweaks

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90 All the issues that are part of milestone 1 for creating standalone plugins are now defined with their individual requirements. See https://github.com/WordPress/performance/issues/656 for the overview
  • You can from there go into the Milestone 1 issues to review, any additional feedback would be much appreciated
  • I think we can start engineering on the first issue this week
  • @flixos90 Also noting that the idea is to eventually maintain SQLite in the monorepo as well, see https://github.com/WordPress/performance/issues/661; right now developing the code in two places is a maintenance burden as seen above (cc @aristath)
  • Though we will only be able to unify the two codebases once the WordPress/performance repository is set up to deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. standalone plugins, so it’ll be a few more weeks

Feedback requested

Open Floor

  • @clarkeemily Circling back to Team Rep nominations, there were quite a few thumbs up to the comment so I presume we can agree on myself being the new Team Rep – general consensus is yes!

Our next chat will be held on Tuesday, March 7, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 21 February 2023

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

Announcements

  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023
  • Next steps on sharing the public roadmap for 2023 now the GitHub issue has been closed
  • Next steps on creating standalone plugins [summarized in this GitHub issue]
    • The performance team received feedback from Matt and Josepha regarding the 3 approaches in this comment
    • @flixos90 As such, we should move forward with option 2. While that’s not the same option we initially voted for, I think that’s still a great option, and it’s great that we now have a clear path forward
      • As mentioned before, Option 2 is technically a bit more work than Option 1, but it effectively includes the work we would need to do for Option 1 as well. So I think it makes sense to do this work in two stages
      • @flixos90 has opened a couple of follow up issues as well as this overview issue to keep track of all the work: https://github.com/WordPress/performance/issues/656
      • Call to please review and share any ideas or feedback you have on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ (either in the overview issue if it’s high level feedback, or on the specific issues if it’s a more concrete feedback regarding one of the tasks)
      • The idea is that for milestone 1, which is already fairly well defined, to get it across the finish line by end of March
      • So at that point we would have the standalone plugins available already, which is a big step regarding the overall effort

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger we are working towards completing the infrastructure for the 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/ or can be cost-based plugin from a third-party Checker over the coming weeks. Once done we will reach a major milestone where we’ll have a working plugin running with some initial checks. You can see progress on the GitHub repo here. Feel free to leave any thoughts/ideas you may have in that repo too.
  • @joemcgill sharing on behalf of @mukesh27 who is out for WC Asia
    • he is very close to having the automated performance measurements workflow implementation for WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ready to share. There is one new requirement that needs to be addressed, which we discovered when coordinating with @youknowriad about logging data with the dashboard he’s set up at https://www.codevitals.run/project/2. Hoping to have that wrapped up later this week.
  • @joemcgill Also, I opened an initial draft PR for adding XHProf support directly in the wp-env package. I’m planning on making updates to that approach this week that would simplify setting up XHGui for analyzing profiling data, but am already able to use this setup to do profiling of WP, which has been useful in testing for possible regressions in 6.2.

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones work proceeds on the SQLite integration
  • @clarkeemily spotted a few new issues added recently re. SQLite integration which I added to the [Focus] Database label [see here]
  • @joemcgill There were also a few issues that came up during the Performance Lab release party yesterday, that I wanted to make sure we get added

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90 No updates from my end, other than the news I already shared about creating standalone plugins and unbundling the Performance Lab plugin, and that version 2.0.0 was released yesterday

Feedback requested

Open Floor

  • @olliejones The drop-in method of loading run-early code is reaching the limit of its flexibility. And the workarounds are, imho, too brittle to release broadly; they’ll drive site owners ’round the bend.
  • A lot of this performance work will depend on run-early code. Can we imagine a more extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. way of handling it that will work better when, say, 50% of all sites use SQLite, and they all use other drop-in activated features?
  • It will likely take some sort of core change to improve this corner of WordPress. What’s the process for working out all that stuff?
  • It might be as simple as modifying the mu-plugin load order so some of them load early.
    • @joemcgill I think it’s a great question, and one that we could begin thinking about by focusing on examples of where the current functionality of WP is limiting our ability to deliver the kind of user-facing improvements we’re trying to make. If solving an underlying architectural issue unblocks a whole lot of other improvements, then I think it’s worth prioritizing, but hard to say without concrete examples.
    • @olliejones the following come to mind:
      • Collisions between the performanceServer timing part of PL and various persistent object caches.
      • Collision between Query Monitor and the SQLite integration
      • And, conceptually it should be possible to run both Query Monitor and SQLite integration, and activate/deactivate them in whatever order the site owner wants. (except obvs deactivating SQLite on a install that uses it would break it.). The same logic applies to object caching.
    • @olliejones to create an issue to capture next steps here
  • @joemcgill flagged a critical issue to address this week https://core.trac.wordpress.org/ticket/57150 

Our next chat will be held on Tuesday, February 28, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 14 February 2023

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

Announcements

  • Performance team roadmap for 2023 reminder, if you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue before end of day Wednesday February 15, 2023
  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @flixos90: we got the lazy-loading fix for 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. themes committed to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. yesterday: https://core.trac.wordpress.org/changeset/55318 – just in time for the WP 6.2 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @spacedmonkey: Would like to get feedback on #57701 and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ PRs 48003, 48001, 48000, 47999, 47997

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger: Progress on the 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/ or can be cost-based plugin from a third-party Checker infrastructure is moving along nicely. We’re aiming to have a working plugin running with some initial checks by end of the month. You can track progress on the GitHub repo and feel free to leave any thoughts/ideas you may have (the repo will be moved to the WordPress organisation when ready).
  • @joemcgill: I’ve got a working implementation of a profiler setup, using XHProf in a wp-env environment that I plan on cleaning up and submitting as a PR to the @wordpress/env package this week and will write up detailed instructions for how others can use these tools to profile WordPress locally.
  • @joemcgill: I’ve also been supporting @mukesh27 (who is also traveling today) on an initial implementation of adding automated server timing measurements to the wordpress-develop repo so we could begin measuring the performance impact of specific commits to core. Looking to try and open a PR later this week.
  • @flixos90: I quickly hackedhacked the WP core dev environment yesterday using @joemcgill‘s XHProf approach above to get it running there too: https://github.com/felixarntz/wordpress-develop/commit/ed096270d817eb9850ea54e4a30662cf2d9492d8
    This is by no means a clean implementation, but something to potentially explore later; would be nice to get this optionally baked into the core dev environment as well so we can easily do profiling as we develop
  • @joemcgill: One thing to note there is that there is an observability cost to profiling, so it’s not meant to be a way of measuring performance from a user’s point of view, but instead to inspect the performance attributes of specific subsystems within a WordPress request lifecycle

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones: SQLite integration: Lots of testing coming in.  Ari Stathopoulos and Adam Zielinski have been hammering away on the SQL dialect translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. issues. This PR will be an ongoing job.
  • @olliejones: It would be nice to integrate some database query stuff into the Server-Timing 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. — that reports to the browser. I’ll do a module proposal.

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • Approach for publishing modules as standalone plugins
    • @joemcgill: That seems like a conversation about “which” modules should be published outside the Performance lab plugin, which is the same as this issue, correct?
    • @flixos90: Yes 640 is related, but this is about our policy. Basically, if we decide every module is a standalone plugin, there will never need to be any discussions on which modules to publish and which not to
    • @joemcgill: I think the only thing that is unclear is whether we’re going to intentionally not publish certain types of modules (e.g., site health checks) as separate individual plugins. I’m still of the opinion that those types of features, which don’t modify the user experience of WordPress, but are instead meant to help measure and/or provide performance feedback should remain part of the Performance Lab plugin itself, rather than being shipped separately.
    • @flixos90: So I guess we have to decide between 3 alternatives
    • @joemcgill: I think that’s a good initial set of options. As a thought experiment, we should apply these options to the current list of modules
    • @flixos90: I took your request to heart and posted a list of modules here

Our next chat will be held on Tuesday, February 21, 2023 at 16:00 UTC in the #core-performance channel in Slack.

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

Performance Chat Summary: 7 February 2023

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

Announcements

  • Reminder: Performance team roadmap for 2023 https://github.com/WordPress/performance/issues/631 If you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue before end of day Wednesday February 15, 2023
  • Team rep nomination reminder, please add your nominations for Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. by Friday, February 24 2023

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger making good progress on the 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/ or can be cost-based plugin from a third-party Checker. We’re starting to finalise the infrastructure and should have a working plugin running some initial checks by end of the month. You can track progress on the GitHub repo and leave any thoughts/ideas you may have. The repo will be moved to the WordPress organisation when ready
  • @mukesh27 I would like to share an update for Automated Performance Testing that @adamsilverstein already share blog post on WordPress core.
    • Issues that completed and merged in feature/automated-performance-testing-mvp branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..
    • AC ready for review.
    • We will open a PR against the WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. once the initial version is complete. Feel free to take a look at the issues and leave any thoughts or ideas you may have.
  • @joemcgill Additionally, I’ve been starting to work on an experimental implementation of XHProf with wp-env to help make it easier for folks to do general performance profiling tasks. See: https://github.com/joemcgill/gutenberg/pull/1 as a starting point.
  • @10upsimon updates on Enhancing the 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
    • Documentation approved, although there was a comment added post approval that I have addressed. It does not change the work, but it does result in the need to confirm that the blocking strategy is not to be confused with the blocking  script attribute itself.
    • GitHub issues have been finalized and broken down into 4x milestones in a separate sheet, estimates are present for all issues in the sheet, although not all issues are in GH yet.
    • GH Issues and AC’s have been added to the project board for Milestones 1, 2 and 3 and have been assigned to @joemcgill for review. It looks like all except for one have been approved (at the time of writing) as they’ve been moved to the backlog
    • I’m in the process of breaking down issues for Milestone 4
    • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. to be posted by Friday, I see no risks thereto.
    • Engineering will commence next week on Milestones 1, 2 and 3

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @olliejones I’ve been hammering on the low end persistent object cache, looks good.
  • @aristath These past couple of weeks I continued working on the SQLite database implementation. There’s a lot of work to do, but things are looking good. Started collaborating with @zieladam as well in an effort to improve some things and make the implementation more stable.

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • @flixos90 Just sharing here that I discovered (probably?) a major performance regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. in 6.2 for classic themes: https://core.trac.wordpress.org/ticket/57648
    • I’m going to follow up on that ticket shortly to collaborate with @oandregal as he is seeing slightly different results. Of course there is a chance that something specifically in my analysis went wrong, but we will have to validate that data

Our next chat will be held on Tuesday, February 14, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#core-performance, #meta

Performance Chat Summary: 31 January 2023

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

Announcements

  • Performance team roadmap for 2023 https://github.com/WordPress/performance/issues/631 If you’re actively contributing to the WordPress Performance Team or plan to do so this year, please share your priorities for 2023 as a comment on this issue!
    • @flixos90 Anyone that is more or less regularly contributing to the team is asked to think about and share their priorities for this year, if possible
    • @spacedmonkey There is also SQLite database and object cache that are in play
      • @flixos90 I think SQLite is clearly a focus. What is on the issue right now is not at all a complete roadmap. The idea is that anyone can post comments with what they would like to prioritize
    • @olliejones It’s my impression that almost nothing, except @flixos90 contributions, are on the priority list yet. So, it’s up to the rest of us.
      • @flixos90 Exactly, I just posted 2 things that we already have proposal posts for, as a starting point. So yes, it’s explicitly a call for anyone involved in the team to contribute to this roadmap
    • @spacedmonkey One thing I have not discussed publicly, but want to look into lazy loading meta data in core. We have a problem that more and more WP_Queries are being run per page and lots of post meta is being loaded when not needed https://core.trac.wordpress.org/ticket/57496
  • The GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ team recently added TTFB measurement to their repo, which is being collected in the code health dashboard here: https://codehealth.vercel.app/project/1. It’s making visible the performance regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. in 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 rendering when compared with classic themes for a simple “hello world” page. As a team, we would like to make sure we’re properly prioritizing the tickets we have for 6.2 that would positively impact this metric—particularly anything that we need to land before the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 milestone next week.
    • @joemcgill I think much of the work for 6.2 that was focused on improving server response times for block themes has already been merged, but I’m mindful of the beta milestone coming next week and want to help prioritize helping land anything that I can that is still in the air.
      • @spacedmonkey me and @flixos90 have worked a lot on block theme performance. Any questions on what I am working on, please feel free to pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me
      • @joemcgill Main thing is whether there are any enhancements that still need to land that you’re waiting on review for?
    • @clarkeemily we also have the Bug Scrub tomorrow at 16:00 UTC time where we can talk through other 6.2 performance items
    • @mukesh27 Is anyone on the Gutenberg team checking those regressions, or do we have to?
      • @joemcgill Good question. I think they are, but there’s no reason we shouldn’t take a look every so often. Really, it would be nice to do something similar for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
      • @mukesh27 Are those changes incorporated into the core of WordPress?
      • @johnbillion I’d love to do something similar for core, the main problem is how to avoid variance so the reporting over time is accurate
      • @flixos90 We have talked about it before in that recent hallway hangout earlier in January. In fact @adamsilversteinis working on a Make post that should go out this week
      • @spacedmonkey I would also have some way of query count per page load.
      • @joemcgill I think long term variance is a concern, but maybe not a blockerblocker A bug which is so severe that it blocks a release. as long as the short term trends are instructive/useful.
  • Plan to have quick-fire focus area updates (15m) so we can focus the remainder of todays chat on Next steps for Unbundling the Performance Lab 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/ or can be cost-based plugin from a third-party (proposal)

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger Still making good progress on the Plugin Checker, starting to approach the remaining issues on the infrastructure so will soon be in a position to run some of the initial checks and do some testing. Feel free to track progress on the GitHub repo and leave any thoughts/ideas on issues. The repo will be eventually moved to the WordPress organisation when ready.

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90 nothing to update for Infrastructure

Feedback requested

Open Floor

  • Unbundling Performance Lab plugin
  • TL:DR; the team are in agreement to proceed with working towards splitting out standalone plugins and keeping the Performance Lab plugin as it is for now
  • Detailed conversation below:
    • @flixos90 We are still waiting to get feedback from Matt on the 3 alternative options that we have outlined and discussed earlier in January. However, I think it would be unwise to just wait and do nothing until we hear back, for which we don’t have a timeline. Therefore my proposal is to work towards simply splitting out standalone plugins and keeping the Performance Lab plugin as is for now
    • A bit more context on the reasoning behind that proposal: The “for now” here is important, as that would likely be a temporary solution. Doing so is effectively our option 1 that we voted for in https://github.com/WordPress/performance/issues/618#issuecomment-1377598692, but the main reason I’m proposing to already work towards it here is that that option is the least disruptive and the least effort, and even if we eventually go with option 2 or 3, we would need to implement the same changes as part of that
    • It is also the most natural transition, for example @aristath‘s SQLite standalone plugin has already been broken out as a standalone plugin
    • The idea is that with the above we would work in the right direction no matter what the eventual final outcome should be. And in any case we would not be wasting time doing work that would potentially not be needed
    • @joemcgill So, if I’m understanding properly, you’re proposing that the performance lab plugin would still include the modules that have been split out. Correct?
    • @flixos90 Yes, it is effectively like option 1 in https://github.com/WordPress/performance/issues/618#issuecomment-1377598692
    • @joemcgill What other plugins need to be split out that aren’t already?
    • @flixos90 I think that we need to discuss. But first I wanted to get feedback on the general idea I shared above. Is that a reasonable next step, as a temporary measure to work in the right direction?
    • @johnbillion Does that duplicate any work or is there a handy build/deployment step for publishing the separate plugins?
    • @flixos90 We would have a build step that simply replaces module headers with plugin headers and deploys those as individual plugins. All modules already work standalone, so there’s no extra work involved in that regard. The main work would be to implement the build and deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. step.
    • @joemcgill At least the SQLite integration plugin is already moved to a separate repo, so it’s a bit clunky to have some of these modules in a mono-repo and some not. It would be nice to align on a development approach.
    • @flixos90 Absolutely; if we go with this approach, we would likely move the SQLite repo back into the PL repo (just for development, the plugin repos on .org would of course remain separate)
    • @johnbillion +1 on a monorepo otherwise we introduce more 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. problems maintaining separate repos
  • No other thoughts on the above from todays meeting, @flixos90 based on the feedback above I think it’s reasonable to proceed with this option for now, to work in the right direction. What we should discuss then though is our approach on how to break out modules as standalone plugins (which we already started talking about a few weeks back)
    • @joemcgill My initial question is whether all modules should be standalone plugins, or if some of them are better suited to stay as part of central infrastructure or smaller experiments as “core modules” of the performance plugin?
    • @flixos90 Exactly, I would outline these alternative ways to go about it:
      • Every module becomes a plugin?
      • Some modules are grouped together into “focus” plugins?
      • Only some modules get broken out as a plugin?
    • @olliejones Specifically, does it make sense to have a standalone “Enhanced Site Health” plugin containing the various site health modules?
      • @flixos90 Potentially. Though my personal take is that we should avoid grouping modules as then we are still going the slippery slope of not having individual plugins for individual features. FWIW, we used to have plugins like https://github.com/audrasjb/site-health-audit-enqueued-assets, and I think that’s the most appropriate approach, even if those plugins are extremely niche
    • @joemcgill Personally, I would keep things like audits, health checks, and small feature experiments like fetchpriority in the main plugin, and break out larger feature plugins.
      • @flixos90 If we do this, we won’t fully address the request of having individual plugins for individual features. What if someone just wants to test fetchpriority? Yes, it’s much simpler than e.g. WebP, but I’m not sure that justifies going a different route for the two
      • @joemcgill That may have been a bad example, and also the part that I’m least confident about, but seems it would be nice for us to have a place to experiment with smaller changes that we are thinking of proposing as enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. in core and not have to spin each one out to a separate plugin until/unless it matures to the point where it’s warranted.
      • @flixos90 Ah okay, that idea sounds interesting. Certain things could start out as a module in the PL plugin and only become plugins as they mature?
    • @olliejones So, PL contains stuff that’s bound to be included in core, AND stuff that’s bound for standalone plugins? Is that right? Or is the criterion for putting a module into PL still that it is bound for core?
      • @joemcgill Right, or if they’re a large enough feature that it makes sense being its own thing. I would say the SQLite persistent cache fits that qualification for me
      • @flixos90 All of that would be things to be included in core. Whether it’s a module in the PL plugin or a standalone plugin is just different ways to “test-drive”. So if we did that, we would still have a mapping that a module can be mapped directly to a standalone plugin, but we would decide for each module whether/when to do that on a case by case basis?
      • @olliejones Is that too limiting? Is Matt thinking along the lines of Drupal’s Core Modules? Is that the direction his “canonical plugins” want to go? Should this team stay away from doing stuff UNLESS it’s bound for core? That’s what I mean. There’s plenty of perf work that only applies to some installs, not all.  Like the persistent object caches. Maybe like webp.
        • @flixos90 we can totally work on things that are not for core; for example the plugin checker project we’re working on. It’s just that the scope of the Performance Lab plugin has been for features targeted for WordPress core. Of course it can always happen that a feature is never deemed eligible or ready. But features in the PL plugin should have the intent to land in core eventually
      • Conclusions: @flixos90think we are converging on the approach of “decide on a case by case basis for each module whether/when it becomes a standalone plugin”, but it’s been only a short conversation with few voices heard, so maybe we can defer a hard decision until next week; I’ll summarize in https://github.com/WordPress/performance/issues/618 and we can keep discussing there
      • @olliejones add to roadmap https://github.com/WordPress/performance/issues/631 for future discussion

Our next chat will be held on Tuesday, February 7, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#core-performance, #meta

Performance Chat Summary: 24 January 2023

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

Announcements

  • None this week

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein not much to update from my end this week. I have been mostly thinking about/planning for WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia & contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/., coming up with a plan for that. I’d love feedback about good ways to engage new contributors on performance

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger: been away for a few days but have been making progress on the 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/ or can be cost-based plugin from a third-party Checker infrastructure. Still more to be done, but you can see the work carried out here https://github.com/10up/plugin-check (we’re developing the project here, but will be eventually moved to the WordPress organisation).
  • The plugin checker will be run through both the CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. and the WP Adminadmin (and super admin). Feel free to take a look at the issues and leave thoughts/ideas you may have

Feedback requested

JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & CSSCSS Cascading Style Sheets.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Database

@olliejones

GitHub project

  • @aristath Last week, SQLite was released as a stand-alone plugin. No announcement action etc was taken. I left that TBD so we can coordinate our policy and strategy as a performance team. The submission was done early to get a head-start with the plugin review process etc – which made sense since this was a direct request from Matt.
  • The repo for the stand-alone plugin was moved to the WordPress organization on GitHub
  • The call-for testing post was updated to include links both to the PL plugin as well as the stand-alone plugin.
  • @olliejones Ari released the SQLite DBMS engine integration as a standalone plugin https://wordpress.org/plugins/sqlite-database-integration/   … And I assume we’ll take up https://github.com/WordPress/performance/issues/625 during the open-floor time
  • @olliejones The SQLite DBMS project is going to require large-scale testing to get to betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. status
  • @spacedmonkey asked where is the best place to provide feedback for this plugin – best course of action to create an issue here https://github.com/OllieJones/sqlite-object-cache/issues
    • @flixos90 Note that we now have both the separate GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repo and the module in the PL GitHub repo, so we need to figure out how to handle that. The duplicate code between those 2 repos is certainly not good
    • @spacedmonkey noticed that cache values were not being set

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90 No recent updates, however I opened https://github.com/WordPress/performance/issues/627 yesterday. What I’m proposing in that issue is to bump the minimum version requirement of Performance Lab to WordPress 6.1. This will allow us to remove the two Site Health cache modules that were already launched in WordPress 6.1, which at this point are a bit of unnecessary baggage to still have in there
  • Note that per our version support policy our commitment is to only support the latest WordPress release anyway, so this should be okay
  • Discussion around plugin versioning:
    • @flixos90 I see there’s a suggestion by @joemcgill to potentially have a 1.10.0 with that code being deprecated first. I don’t think that would help here. FWIW, the modules are already not loaded today when you have WP 6.1. So nothing changes for you either way when they’re removed:
    • Either you are on WP <6.1, so you cannot update to the new PL release.
    • Or you are on WP 6.1, which means you already are using the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. feature, and the PL modules for the same purpose are not loaded.
    • That was behind the https://make.wordpress.org/performance/handbook/performance-lab/version-support-policy/
    • @joemcgill Makes sense to me. Just getting up to speed on the process here now that I have time dedicated to work on these performance projects. The documented policy seems quite clear
    • Agreed no vote required on this

Feedback requested

Open Floor

  • @olliejones discussed the module proposal for SQLite Persistent Object Cache
    • It’s a standalone plugin. Does it make sense to build it into PL, to put it onto a track to go into core?
    • @spacedmonkey I think it needs to live as a plugin for a while
    • @flixos90 A bit of a tricky question. Of course we are working towards unbundling the PL plugin. But we’re still pending a decision on how exactly, and at this point it may make sense in the PL plugin. Is it already published on wp.org or not?
    • @olliejones Absolutely live as a plugin.  There’s no other way to get decent field experience. And this kind of thing requires field experience.
    • @spacedmonkey I want to test it on bigger sites, multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, ensure cache invalidation works, support wp_cache_get_multiple and some other stuff
    • @olliejones
    • Yes, published,  https://wordpress.org/plugins/sqlite-object-cache/ If it goes into PL, we’ll need to sort out the use of the object-cache.php drop-in module.
    • @flixos90 Okay, we should definitely keep it published like that then. I think at this point, let’s just keep it like that? We could potentially add it as a PL module too, but depending on the path decided on for unbundling the PL plugin, that would just be unnecessary work – so probably most efficient (until we have a decision) to work in its own repo for now
  • @spacedmonkey discussed the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. for making php 7.2 the minimum version of support php in WordPress https://core.trac.wordpress.org/ticket/57345 and asked if this is something we should be pushing for as the performance team
    • @olliejones I say yes, smaller QA matrices are always good
    • @joemcgill It could certainly have some positive performance implications, though I’m not sure how much impact we would have since the process for bumping versions is pretty well established (unless I’m wrong). It would be nice to help support that effort with some evidence about the performance benefits from any automated testing we do against different versions.

Our next chat will be held on Tuesday, January 31, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#core-performance, #meta