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

Performance Chat Agenda: 24 January 2023

Here is the agenda for this week’s performance team meeting scheduled for January 24, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 17 January 2023

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

Announcements

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein One new thing this week: I am working on a game/testing tool that shows two images generated by WordPress and asks users which they prefer. The comparisons will cover a range of quality settings and mime types (and image engines) and we will collect data about the comparisons. My goal is both to have something fun and interactive as well as get some actual WordPress based data on image quality to help make a decision about where to set WebP default quality in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
    I’d love to have some testers/feedback here once I get it a little further developed (to be shared in future).
  • @pbearne I will/plan create a combined patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. with dom-color with theme flags and media lib changes for core and then create a new proposal blogblog (versus network, site) post on make for this new version
    Following from @flixos90 comment on the media lib patch
  • @spacedmonkey asked if we are hoping to get dominant color into 6.2
    • @pbearne would love to get it in but @spacedmonkey unsure if the 80% rule was met (is it useful for 80% of users)
    • @pbearne I am hoping as this is a enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to the media library and the is for every one we can get it in and with the them flag it can be pulled into a theme if wanted just like you might use the icons from core in a theme

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger: 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 work in progress (mainly infrastructure right now) and coming along nicely

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

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • @olliejones I’m seeing some very promising performance results from using SQLite as the persister for an object cache. Is this worth proposing as a Performance Lab module?
    • Performing very well on a WooCommerce site on low-end Godaddy hosting – been doing some tests on my 100K user test site, it seems good. Also works with 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
    • @pbearne suggested yes, @olliejones will write a proposal
    • @spacedmonkey +1 for this idea. Adding object caching to sites without the overhead of memcache or redis, could be massive big for smaller sites
    • @adamsilverstein would be especially great for hosts that don’t support traditional object caching and won’t for some real reasons
    • @olliejones Last week I asked whether there are any more-or-less standardized large-site benchmarking environments. This is why. Anything?

Our next chat will be held on Tuesday, January 24, 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 Agenda: 17 January 2023

Here is the agenda for this week’s performance team meeting scheduled for January 17, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 10 January 2023

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

Announcements

Discussion: Unbundling Performance Lab

  • @flixos90: Want to emphasize that we should decouple how we develop these features from how we distribute them, with this conversation focused on the latter. We can keep working in a mono repo to keep development overhead low no matter which approach we choose for distribution.
  • @olliejones: It seems like any attempt to figure out what a “canonical 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” is might be a waste of time, as it’s up to Matt, not us
    • @flixos90: The canonical plugins topic is related but not really connected. Agreed it’s not on us to decide, but also don’t think we need to do that to determine how to unbundle Performance Lab. The ask is to distribute the features as individual plugins – whether or not they’ll become “canonical” plugins isn’t directly relevant to the unbundling.
  • @flixos90: As comment notes, we’ve considered three options so far:
    • Option 1: Keep PL as is, but additionally deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. modules as individual plugins
    • Option 2: Make PL a “wrapper” focused on central infrastructure and recommendation of individual plugins
    • Option 3: Deprecate PL completely in favor of individual plugins
  • @masteradhoc: Don’t see SQLite as something that needs to be in PL and WebP can also be standalone. How do you define if a feature should get into the plugin or be standalone? Would go for option 3 to keep everything separated and have some sort of list to keep track on what is being worked on. However, this still doesn’t solve the bigger issue – what happens if the argument is still to not merge them into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? What will make a canonical plugin in the end? How can we really move WP further in performance?
    • @flixos90: The idea is that all modules of PL are standalone features, so option 3 would mean each module would become its own plugin. The PL plugin has a lot of benefits that we would lose if we go with this option, which is why it’s the most unfavorable to me. There are several feature plugins that weren’t merged into core – either they continue to be developed to eventually get there or they get archived.
    • @masteradhoc: In that case, think more of option 2. Wouldn’t do option 1 as it seems like duplication.
    • @flixos90: Yes, there would be duplicates, but it’s not necessarily bad. It’s the best of both wolds, similar to how Jetpack works as of today.
  • @spacedmonkey: Could a feature be both a standalone plugin and in PL?
  • @olliejones: We have one canonical plugin now, Akismet, that’s available to every WP install but not required – is that what Matt wants for performance?
    • @flixos90: Nothing would be pre-installed; let’s focus on unbundling as opposed to canonical plugins since we don’t know what those are
  • @spacedmonkey: It seems to only make sense to break off larger feature like WebP or SQLite into separate plugins
    • @masteradhoc: I wouldn’t install a plugin just to get additional Health Checks
    • @flixos90: It’s a blurry line – it would require the overhead of a discussion on every single feature to decide if it should be a standalone plugin. Would be in favor of a single consistent decision to save ourselves the overhead later. This is how feature plugins have always worked. FWIW several plugins have only ~50 installs because they’re so specific.
  • @spacedmonkey: Could have a Performance Lab module and a GH repo template for them, would help with maintenance
  • @joegrainger: If we deploy modules as individual plugins, will they have their own repos and if so will they be in the WordPress organization?
    • @flixos90: Yes, only on wp.org would there be separate repos
  • @mxbclang: Are we comfortable that keeping PL and deployingDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. separate plugins fulfills Matt’s request? We would still have a single plugin with all of these features
    • @flixos90: We’ll have to see of course, but main ask was individual plugins
    • @adamsilverstein: Not sure this really meets his requests, he very explicitly said of SQLite that we should “stop putting additional things like this into Performance Lab”
    • @flixos90: From my perspective, since Jetpack does Option 1, this should be a reasonable approach
  • @spacedmonkey: Jetpack is an example of a mono repo with multiple plugin projects: https://github.com/Automattic/jetpack/tree/trunk/projects/plugins, which is a good example of how Option 1 would work
    • @kraft: Jetpack system uses composer packages for things shared between plugins and they get called in via them, happy to answer any questions about the setup
  • @mxbclang: Option 3 is also a burden for support, since each plugin has its own support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations. that would need to be monitored
  • @spacedmonkey: Marketing is also an issue, where do we push people to?
    • @flixos90: Depends on the context, likely PL primarily, but individual plugins would also be available. A feature proposal post would highlight both as equal options for testing.
  • @olliejones: Option 1 lets us keep moving on development, but it carries the risk of Matt pushing back
    • @flixos90: FWIW both Options 1 and 2 carry that risk
    • @adamsilverstein: Makes me lean toward Option 2
    • @flixos90: Benefit of Option 1 is that it would continue to work as is for the people who have PL currently installed; Option 2 would require a complex migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. that users likely would not understand
    • @adamsilverstein: Good point, thinking more of the end user who hasn’t tried “feature X” yet and having a separate plugin might be a better experience
    • @flixos90: Options 1 and 2 would be have separate plugins for each module
  • @spacedmonkey: Having each functionality in its own plugin helps with testing
  • @spacedmonkey: What defines a module? Would the current Site Health checks all be together, for example? SQLite and WebP are clearly their own modules, but what about smaller things?
    • @flixos90: Great question and another thing to discuss for the future
    • @spacedmonkey: Defining how we break the plugin up helps with what option we pick – don’t want a bunch of “sub”-plugins
    • @flixos90: Yes, but this doesn’t affect which option we choose
    • @spacedmonkey: It does for Option 3
  • @olliejones: Plugin discoverability is a huge issue in today’s WP ecosystem and Option 1 helps discoverability. The categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. “canonical plugin” does seem to help with discoverability.
    • @flixos90: Fair to say that discoverability would suffer with Option 3.
    • @spacedmonkey: Marketing and support would also suffer
    • @adamsilverstein: Not sure about discoverability, if I want a SQLite feature for my site, a canonical plugin that does just that would be easier to discover than a feature within PL
    • @flixos90: Yes, but the standalone plugin would always exist with any option
  • @spacedmonkey: If there’s a standalone plugin, will anyone bother with a PL plugin? What’s the point of it?
    • @flixos90: Depends on the audience. There are people that want one feature at a time and others who want everything in one place.
  • @olliejones: Happy with Option 1 for now. Taking a step back, discoverability is a REALLY big problem for WP themes, plugins, etc. The reason I suggested working on the definition of “canonical” is that it has the potential to address that. Know that we can’t solve that problem but it’s what Matt cares about.
    • @masteradhoc: Agree, maybe next meeting could focus on how these initiatives can be moved forward
  • @spacedmonkey: Personally think that all PL functionality should be opt-in
  • @adamsilverstein: Love the idea of canonical plugins at install time, Drupal does something exactly like this with their 10-minute install
  • @flixos90: That’s how I’ve been thinking about canonical plugins, as well, with WP core providing contextual recommendations
  • @spacedmonkey: Maybe we could have a setup wizard where you opt-in to the features that you want, like Web Stories
  • @olliejones: Is there any way to get Matt’s approval of our choice, or do we have to do a bunch of work and risk it getting shot down?
    • @flixos90: We’d definitely reach out to him with a proposal once we have alignment within the team; we wouldn’t start any work before having buy-in from him
    • @olliejones: Who will do that?
    • @flixos90: Potentially, will help in figuring out how to do that
  • @flixos90: For next week, perhaps: I think are our options when it comes to the scope of how the current modules would be distributed as plugins:
    • Every module becomes its own plugin
    • Modules are grouped together based on their focus into a few “topic specific” plugins
    • Decisions are made individually, some modules become standalone while others are grouped into a topic specific plugin

Voting on an approach is now open in this GitHub comment through Friday, January 20.

Our next chat will be held on Tuesday, January 17, 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 Agenda: 10 January 2023

Here is the agenda for this week’s performance team meeting scheduled for January 10, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 3 January 2023

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

Announcements

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @pbearne: Dominant color in Media Library code is ready for review: https://github.com/WordPress/performance/pull/587

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @joegrainger: 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 work in progress and coming along nicely

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

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Matt’s request will be a major Infrastructure topic. Will leave some thoughts on https://github.com/WordPress/performance/issues/618 so we can begin to discuss, but a real discussion should occur in next week’s chat since it’s more synchronous. See also @tweetythierry‘s reply to Matt here which mentions some potential options for us to think about.
    • @olliejones: Is there any prospect of getting coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to add a new drop-in slot to avoid overloading object-cache.php with the monitoring stuff?
      • @flixos90: Adding a new slot will be challenging; defining the scope and whether it’s justified will likely take quite a while. That said, worth exploring in 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., but should probably come up with a solid proposal first.
      • @manuilov: If we need to split the plugin, seems like the most appropriate option is the second approach suggested by Thierry. Will need to extract modules as individual plugins and keep PL as a wrapper focused on central infrastructure and recommending individual plugins. Otherwise, if we deprecate PL, people will be less able to find new modules/plugins.

Feedback requested

Open floor

  • @olliejones: Is there a load-testing/performance benchmarking setup? Maybe a sample big site with a bunch of jmeter scripts or something similar?

Our next chat will be held on Tuesday, January 10, 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 Agenda: 3 January 2023

Here is the agenda for this week’s performance team meeting scheduled for January 3, 2023 at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance Chat Summary: 20 December 2022

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

Announcements

  • @mxbclang: Should we hold our chat next week on December 27, or cancel due to the holidays?
    • 9 voted to cancel, none to hold
    • Chat next week is canceled and next chat will be on Tuesday, January 3, 2023

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • No updates

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • @flixos90: 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. launched in Performance Lab yesterday!
    • Received a report of a conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with W3TC around the object-cache.php file that we’ll investigate. Our approach is to maintain the other file, but maybe their check for whether the file is in place is overly strict.

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

  • No updates

Feedback requested

Open floor

  • @olliejones: Are there any plans to create an ingestion module to move 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/. contents to SQLite?
    • @mxbclang: Good question for Ari, maybe comment on his post?

Our regularly scheduled chat for Tuesday, December 27, 2022, is canceled due to the holidays. Our next chat will be held on Tuesday, January 3, 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 Agenda: 20 December 2022

Here is the agenda for this week’s performance team meeting scheduled for December 20, 2022, at 16:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat