Performance Chat Summary: 23 January 2024

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

Announcements

Priority Projects

Server Response Time

Notes from today’s call:

Database Optimization

Notes from today’s call:

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 project and link to the GitHub project board
  • Contributors: @mukesh27 @flixos90 @westonruter
  • Projects from the 2024 roadmap:
    • INP opportunities research
    • Interactivity 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.
    • Speculative prerendering

Notes from today’s call:

  • No updates this week

Images

Notes from today’s call:

  • @westonruter For Image Loading Optimization, the PR to preload the background-image for the LCP element just needs one more review to merge. Again, I found this change to reduce LCP-TTFB by ~9% when, for example, the LCP elemment is a Group 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. with a background image or a Cover block with parallax. Otherwise, I’ve been working with @thelovekesh on eliminating loading the web-vitals library from unpkg.
  • @adamsilverstein The PR to land AVIF is ready for testing; at this point I am waiting for support to land in Edge stable before committing, not sure that will in time for 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. cutoff though
  • @swissspidy For client side image compression I’m currently working on ways to make the performance impact more measurable and documenting that. In the meantime, my Media Experiments 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 can now be tested on WordPress Playground to familiarize oneself with how seamless it all is.
  • @joemcgill As mentioned earlier, the experimental plugin for supporting auto-sizes is now available. I’m tracking an issue that is effecting WP galleries when this is in use. Additional testing and feedback of this feature (requires Chrome 121+) would be appreciated.

Measurement

Notes from today’s call:

  • @joemcgill Still need to look into the failures on the 6.4 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". #60127

Ecosystem Tools

Notes from today’s call:

Open Floor

  • No updates today

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

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

Performance Chat Summary: 16 January 2024

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

Announcements

  • Welcome to our new members of #core-performance
  • 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 release today for version 2.8.0

Priority Projects

Server Response Time

Notes from today’s call:

  • @thekt12 I was exploring use of transient for sites that don’t have persistent cache.
    https://core.trac.wordpress.org/ticket/60120#comment:8
    However I have paused the above for a while and started with #59532 as this is a bit similar to https://github.com/WordPress/wordpress-develop/pull/5718.
    Also, https://github.com/WordPress/wordpress-develop/pull/5718 is ready for mostly final review
  • @joemcgill #59969 seems to be very close on the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. side, just needing a couple of changes to the PR. Can we get that sorted soon @thekt12 or are you waiting on some additional feedback?
    • I think that blocks the supporting work you’ve started in the GB repo at present
    • @flixos90 Yeah it’s tricky and somewhat clunky to figure out the sequencing there
    • @flixos90 If the core change needs to come first, let’s commit that very soon and then update  and merge 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/ change and aim for a back port not too far away
    • I reviewed @swissspidy‘s performant translations PR yesterday, and it looks great to me. It would be great if a few more folks here could take a look too since it’s a big change
  • @swissspidy The performant translations PR is close to be mergeable, it‘s in very good shape already
  • @joemcgill Also, for #60120, @spacedmonkey are you planning on continuing the PR you started, or is your intent for someone else to pick up that work? Either is fine, just wasn’t sure
    • Almost ready for commit

Database Optimization

Notes from today’s call:

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 project and link to the GitHub project board
  • Contributors: @mukesh27 @flixos90 @westonruter
  • Projects from the 2024 roadmap:
    • INP opportunities research
    • Interactivity 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.
    • Speculative prerendering

Notes from today’s call:

  • @flixos90 I opened pull requests for most of the remaining work for the first Speculation Rules plugin MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia yesterday, see https://github.com/WordPress/performance/issues/908 (everything linked from there)

Images

Notes from today’s call:

  • @joemcgill I submitted the plugin for auto-sizes last week and already heard back on some feedback to address. I’ll get that sorted and hopefully will be available soon. In the mean time, it’s ready to be merged to the Performance Lab after 2.8.0 is released later today.
  • @flixos90 I plan to commit the PR for https://core.trac.wordpress.org/ticket/59352 shortly
  • @westonruter For Image Loading Optimization, the tests PR has been merged. I have the pull request for optimizing the loading of background images ready for review. In some quick testing I found this to reduce LCP-TTFB by ~9% when a Cover 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. has parallax and is the LCP element: https://github.com/WordPress/performance/pull/914
  • @swissspidy Regarding client-side image compression a new blogblog (versus network, site) post just got published about it: https://www.codeinwp.com/blog/pascal-birchler-interview-wordpress-media-experiements/

Measurement

Notes from today’s call:

  • @joemcgill The main thing that is on my mind is that we need to fix the performance tests that are failing in the 6.4 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". #60127. This would be good to get fixed before the next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., which is being organized for the next few weeks

Ecosystem Tools

Notes from today’s call:

Open Floor

  • @pbearne I am thinking of tackling Improving the calculation of image sizes attributes#760 but would like a quick chat/call to agree on the approach before I start. Could we plan that?
    • @joemcgill I’ve got an ongoing project internally where I’ve been working on that, @pbearne. Probably best to wait on more definition before diving into anything.
    • @joemcgill Would be happy to have you collaborate though. I most likely won’t have anything ready to share this week though
  • @flixos90 Just a reminder that the Performance Lab 2.8.0 release party will be in a good 1 hour from now, at 18:00 UTC. Please stop by and help out if you’re available!

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

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

Performance Chat Summary: 9 January 2024

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

Announcements

  • Welcome to our new members of #core-performance
  • Request for reviewers of the draft 2024 Performance Roadmap document please
    • @clarkeemily We are aiming to receive feedback on the above document by the end of this week please – we would greatly appreciate everyone’s feedback and input into shaping 2024
    • You will notice in this document that the Priority Projects have changed shape to being:
      • WordPress interactivity performance
      • WordPress load time performance
      • Ecosystem activation
      • Performance measurement
    • I’d be interested in opinions as to whether we structure the sections of this meeting aligned to those projects from next week onwards?

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @swissspidy For performance translations I just pinged some folks for code review again now that the holiday break is over
  • @pbearne can add an issue to create PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher-based translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files in the build tools?
  • @thekt12 Working on final bits of #59969 PR#5718 addressing review changes, 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. and updating corresponding Guttenberg PR.
  • @thekt12 Also, started working on #60120 I’ll give it for first review this week
  • @joemcgill At the end of this meeting last week, @flixos90 @spacedmonkey and I had a useful conversation about improving our caching strategy 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. theme files (#59719), which has unblocked #60120. Jonny already created a PR for that issue which is ready for review.
  • @joemcgill @pereirinha also updated the PR for #59595, and I left some feedback yesterday. I think this is close save for a few details.

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • @pbearne I updated the options autoload 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. follow the term changes

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 project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

  • No updates this week

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @adamsilverstein I have an update on AVIF image support – Microsoft has added support for AVIF in Edge, since version 1.121, (release data Jan 7, 2024) – see https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#feature-update
    • I also confirmed this manually be opening test AVIF images in Edge (Canary) and everything worked as expected.
    • Assuming this lands in stable, we should be able to add support for AVIF to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., see #51228
    • @mukesh27 Like WebP do we needs to make a module first for testing then merge into core?
    • @flixos90 I think to merely add support for the format, we could work directly against core. That was done the same way with WebP. Only if we wanted to make it a default or something, we’d need a module IMO. Although at some point we may just ditch WebP and try to progress with AVIF only, depending on browser support
    • @adamsilverstein Support can already be tested with https://github.com/WordPress/wordpress-develop/pull/4612, note you need a server that supports AVIF for it to work, typically PHP 8.1+ or Imagick built with AVIF support
    • @flixos90 mentioned @swissspidy your client-side image efforts would be super useful for this too, as it would unlock AVIF support for a lot more sites
  • @joemcgill An initial module for implementing auto-sizes for lazy-loaded images is ready in 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. This web feature is already in Chrome Betas, and will likely roll out in the next few weeks, so I’d like to get this out for people to start testing. See: https://github.com/WordPress/performance/pull/904
  • @swissspidy For client-side image compression aka media experiments I’m working on a PRD and trying things out in my media experiments plugin

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • @joemcgill Nothing new this week, but wanted to flag that the Performance Tests started failing in the 6.4 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". recently, in case anyone has time to dig into it later this week: #60127

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo for Plugin Checker

Contributors: @mukesh27 @swissspidy

  • @mukesh27 For the Plugin Check, I’ve been providing support by conducting code reviews for open PRs. Additionally, I’ve raised an issue regarding Behat test issue in PHP 8.0 for investigation
  • @flixos90 Several PRs have landed in the plugin checker repo last week from I believe a new contributor? I’m not sure what their SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. user name is, but that effort definitely deserves recognition! @rabmalin thanks!
  • @joemcgill It also looks like @foosantos left some feedback on https://github.com/WordPress/plugin-check/issues/283#issuecomment-1882241470 regarding steps to releasing 1.0.0 of the plugin. It sounds like the Plugin Review team have several new blockers that need to be handled prior to that release, though I’m not sure where all of that is being coordinated. One of us should respond and see if we can get some visibility into issues @bordoni has been working on and whether we can support in order to relieve some pressure from their team. @flixos90 I’m happy to take this on if you don’t have time, but will defer to you, given you started that convo. @pbearne also offered to help.
  • @flixos90 It would definitely be great to find ways to better collaborate on both efforts. I don’t understand the problems at this point since I have no insight in the discussions that are happening. We could also actively support addressing their blockers which I think would be good for everyone
    • @clarkeemily asked @bordini how can we help here, and also get visibility into the behind the scenes planning that was mentioned in the comment above?

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

  • @mukesh27 We have successfully completed the Milestone 2a tasks and their respective follow-up PRs for the Creating Standalone Plugins feature. This is set to be released in the upcoming version 2.8.0.

Open Floor

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

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

Performance Chat Summary: 2 January 2024

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

Announcements

  • Welcome to our new members of #core-performance
  • Call for 2024 roadmap priorities https://github.com/WordPress/performance/issues/903 – the issue will remain open for project priorities until January 5, 2024

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @mukesh27 plan to review Jonny’s Lazy load varients PR
  • @joemcgill Just getting back into things after the long holiday break. Left a review on @spacedmonkey PR on #59969, which @thekt12 has also been working on. I think we’re close to having something there, just need to align on some details of the approach, I think
    • @spacedmonkey I think we need to consider b/c I think adding a new parameter of variations callback is the only way forward. We need to think about how we are going to implement this in 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/ as well. We have to support 2 versions back of WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The 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. PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher code is in Gutenberg.
    • @joemcgill agreed. If you can outline those concerns in the PR or ticketticket Created for both bug reports and feature development on the bug tracker., that would be helpful. I left you some feedback just about 30 min ago there
  • @pereirinha I plan to circle back this week to #59595

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • No updates this week

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 project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @joemcgill I think the Performance Lab module proposal for lazy sizes is about ready. @flixos90 do you have any timing considerations before that is merged? https://github.com/WordPress/performance/pull/904
    • @flixos90 I’m not sure we should merge it right now given we’re in the last bits of unbundling 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, and it would introduce a new module that ideally should be a standalone plugin. Potentially we could still merge it, but IMO the more pressing point would be to submit it to the .org directory. So that it can go to the review chain. Since it’s a community feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., potentially we could request to expedite
    • @joemcgill Makes sense. I do think we’ll end up wanting it to be in the PL plugin while we await the review, though, so we can get some early testing and feedback on the approach prior to potentially getting this into core during this cycle
    • @flixos90 I think my proposal at the end of https://github.com/WordPress/performance/issues/911#issuecomment-1866602771 would allow for that. Curious what y’all think about this. It would allow us long-term to start anything as a module, then make it a plugin once it’s approved in the directory
    • @joemcgill I like the idea. I would prefer we work towards a clean code separation between modules and plugins, so it’s obvious which are which.
    • @flixos90 There would still be a transition involved though. For instance, if we merge this now, it would go into the modules folder, as only those are actually included and loaded in PL.
      Once it would be approved on .org, we could then move the code to the plugins folder, with (probably) the only code change being the module headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. turning into the plugin header

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • No updates this week

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo for Plugin Checker

Contributors: @mukesh27 @swissspidy

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

Open Floor

  • Discuss #60120 
    • @spacedmonkey I don’t think this ticket should be blocked by other ticket. That ticket might take a long time to resolve. This issue can’t be resolved by the next release. The only thing to decide is if we make the cache group global.
    • @joemcgill I would hope to have an approach for #59719 (the blocking ticket) resolved very shortly and I agree that #60120 should be resolved in this release cycle.
    • @spacedmonkey With theme data, most of it should be global caches in 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 context
    • @flixos90 I completely agree that this should receive a cache group. I’m curious though why that is urgent. What are the actual problems of having this in the global cache group?
    • @spacedmonkey The default cache group isn’t a global cache group. Not being in a cache group, means that the cache group can not be cleared.
    • @joemcgill By “default cache group” I assume you are talking about the “themes” cache group. That group is also not persistent without a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., so one of the questions is whether we need to introduce a new cache group, or revisit the way theme data is cached.
    • @spacedmonkey The default cache group is that, a group called default which is where is stored if no group is defined, as current.
    • @pbearne I would be happy to make the changes as needed
    • @joemcgill Thanks for clarifying what you meant by default. What do you mean by “global”
      • @flixos90 Global groups apply to an entire multisite
    • @flixos90 Makes sense that it’s probably not optimal to use a non-global cache group. But we shouldn’t just use themes, that’s the tricky part. Surely we could just make up a new group name for a new global group and fix this issue, but I think then it could be that group name would need to be changed based on the decision from #59719
    • @spacedmonkey Cache groups can be local to a site like posts or global in multisite like networknetwork (versus site, blog) or user
    • @flixos90 To be fair, even the themes group is only global if it’s set to persistently cache. Since we probably want the data here to be persistently cached, it would make sense to make that group (whatever it would be called) global
    • The rest of this discussion continues in Slack from here https://wordpress.slack.com/archives/C02KGN5K076/p1704215017254669

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

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

Performance Chat Summary: 19 December 2023

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

Announcements

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • No updates this week

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 project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

  • @flixos90 No real update, just that I’m currently experimenting with the Interactivity 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., specifically to use it in classic default themes to replace more manual custom JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.. Partly to familiarize myself with the API, partly for a first prototype of something we could potentially do in the future. Should have a first draft PR up for later today. Really for reference more than anything

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @joemcgill Last week I put together a small experiment to see how the new auto-sizes for lazy-loaded images feature is working now that it’s being implemented in browsers. Based on that exploration, I put together an initial module implementation that can already be used for testing. I plan to update the PR this week.
    • Related – I also opened a new issue to discuss how we want to handle new modules once the unbundling project is complete. Feedback would be appreciated.

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • No updates this week

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo for 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

Contributors: @mukesh27 @swissspidy

  • @mukesh27 For the Plugin Check, I have been addressing issue 342 and have opened PR 347, which is now ready for review and I also supported in code review process. Moreover, there is positive news that some community contributors are actively working on several issues and have raised corresponding PRs for them. 

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

Open Floor

  • @desrosj I noticed that the performance tests started failing in some older branches while working on some E2E test related changes. Well, it only seems to be happening for the 6.4 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". currently. But I’m wondering if the needed conditions just haven’t been met for the other branches.
    • @joemcgill I’m only seeing the latest commit fail according to this list. Am I looking at the wrong thing?
    • @desrosj That’s accurate. I was confusing the additional E2E failures with something (potentially) unrelated that I’ve fixed separately. #60095 is what I was working on. The step that is failing seems to be checking 6.1.1 for a baseline if I’m reading it correctly.
    • @joemcgill I’m going to try rerunning that one, since the same commit to the 6.3 branch worked fine.
    • @desrosj
    • FWIW, I committed the fix for 60095 in the 6.1 branch this morning, and this workflow was from yesterday. Maybe the re-run does not include changes for the other branch because they were not there when this change was made? Started a manual run for 6.4 to try and rule that out.

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

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

WordPress performance impact on Core Web Vitals in 2023

This post summarizes and highlights the impact that WordPress has had on Core Web Vitals (CWV) in the field in 2023, providing a metric-based retrospective at the end of the year.

TL;DR: The WordPress performance team and all WordPress contributors can be very proud of the accomplishments: The overall CWV passing rate across all WordPress sites has improved from 28.31% to 36.44% (+8.13%) on mobile devices and from 32.55% to 40.80% (+8.25%) on desktop devices. 🎉

These improvements led to a visible increase of CWV passing rates even for the entire web. The performance team is currently discussing additional findings to define the focus for 2024 and is looking for further proposals and contributors for next year.

Note: This post is based on the slide deck used in a presentation for the WordPress performance year-end hallway hangout (also see recording). Feel free to review the deck as well as an alternative way to consume the numbers.

A few notes on CWV field metrics

Before looking at the 2023 metrics in more depth, a few things should be clarified.

The metrics shared in this post are exclusively field metrics. They are distinctively different from lab metrics, which are the metrics that have typically been shared in the WordPress release performance summary posts this year:

Lab metrics are benchmarks conducted on demand, typically as a synthetic A/B performance comparison. They provide an indication of whether/how a specific change is anticipated to impact performance. For example, for the lab metrics shared for the WordPress releases in the aforementioned posts, the load time performance of the respective new WordPress version was compared to that of the previous version, on the exact same setup, so that the only different variable is the WordPress version.

Field metrics on the other hand are analytics data collected from site usage and provide an indication of how performance is actually experienced by real users on real sites. For example, the Chrome User Experience Report (CrUX) provides a public dataset of performance field data from opted-in Chrome users, aggregated at the site level. The WordPress 6.3 field impact summary post shared metrics queried from that dataset, granularly broken down for just that release compared to the previous 6.2 release.

When reviewing field metrics, it is important to consider the following:

  • Field metrics are influenced by a myriad of factors, for example the active plugins and theme, the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. version, the hosting stack, the browser(s) used by end users, their networknetwork (versus site, blog) connection, and more. So when comparing field data between two months, for example, it is impossible to limit the comparison to just one specific aspect of those.
  • Field metrics do not allow direct correlation between specific enhancements and their concrete metric impact. This is closely related to the previous point: Even if you compare the performance of a dataset of sites that enabled a specific feature before and after the change, for example, there may have been numerous other changes during that time that influence the data. Effectively, it is impossible to conduct clean A/B tests in the field.
  • Field metrics are more meaningful the larger the dataset is. Because of them being only indicators rather than “proof”, the larger the relevant dataset the more a specific metric observation from it can be trusted. It’s also worth considering that the web’s user base is incredibly diverse, so even the audience that a specific site has matters significantly for its field performance.

And yet, despite all these caveats, field metrics are the only way to validate how beneficial performance changes really are. If a performance “improvement” doesn’t impact real users, it effectively doesn’t matter even if it looked great in the lab.

CWV breakdown and assessment

For a brief recap on Core Web Vitals (CWV), they are a set of three specific metrics:

Each of these metrics has thresholds for whether a value is considered “good”, whether it “needs improvement” or whether it is “poor”.

The CWV metrics LCP ("good" threshold of 2.5s or lower), FID ("good" threshold of 100ms or lower), and CLS ("good" threshold of 0.1 or lower)
This visualization shows the three CWV metrics and their thresholds.

These metrics can be captured for every single navigation / page load. A page load is then only considered to have “good” CWV if all three metrics show a “good” value. In other words, for a single navigation the CWV assessment is simply a binary metric of “good” or “not good”.

When looking at actual CWV datasets in the field, metrics are always aggregated, typically at the site / origin level. In other words, such an aggregation encompasses all navigations that happened on that site in a given time frame. In that dimension, the CWV assessment is considered “good” if 75% or more of the navigations have a “good” CWV assessment.

Last but not least, CWV can also be assessed at a larger scale, for example across all sites using a specific technology, like WordPress. In that scenario, CWV are typically measured through a “passing rate” which describes the percentage of sites that have a “good” CWV assessment. For example, if in a dataset of 1 million sites 200,000 of them have a “good” CWV assessment, the resulting passing rate is 20%.

Note that not only the overarching CWV passing rate can be measured, but also the passing rates for the individual metrics (LCP, FID, CLS and others). The CWV passing rate is however the most meaningful single metric as it is a summary of all of them.

But now let’s take a look at the data. Note: All metrics highlighted in this post are CrUX passing rates from the field, based on year-over-year comparisons between October 2023 and October 2022 (unless otherwise indicated).

WordPress CWV in 2023

As already mentioned in the “TL;DR” at the beginning of this post, CWV for WordPress have improved significantly this year:

  • Mobile CWV passing rate improved 8.13% (from 28.31% to 36.44%).
  • Desktop CWV passing rate improved 8.25% (from 32.55% to 40.80%).

While at first glance ~8% may not sound like much, it is a quite substantial boost to the passing rates, particularly when considering their base values. Relatively speaking, the new passing rate is ~29% higher than the old one on mobile and ~25% higher on desktop.

For reference: The previous year’s improvement for CWV passing rate was 6.99% on mobile and 6.25% for desktop. So while WordPress already did a great job in the previous year, this year even exceeded those accomplishments.

Line chart of WordPress's mobile CWV passing rate gradually improving from below 30% to over 35%. There is a small drop between March and April 2023, annotated with "LCP algorithm slightly changed".
This chart shows WordPress’s mobile CWV passing rate throughout the year. Note that the decline between March and April is not a result of a WordPress-specific problem (or any performance issue at all), but rather due to a change in how the LCP metric is being calculated, which was rolled out in that month.

Let’s take a closer look at the individual metrics that make up CWV and how they changed this year. For simplicity, only the mobile numbers are shown below. They are slightly more important than desktop results since mobile traffic overall is higher than desktop traffic. More importantly, performance improvements carry more importance for mobile devices as they are typically less powerful and are subject to worse network conditions. It is also worth noting that the corresponding desktop numbers don’t show any notable differences in trend.

  • Mobile LCP passing rate improved 8.89% (from 34.48% to 43.37%).
  • Mobile CLS passing rate improved 4.22% (from 74.76% to 78.98%).
  • Mobile FID passing rate improved 0.87% (from 96.55% to 97.42%).

As you can see, LCP saw by far the largest boost. This is an excellent outcome, as improving LCP was the main focus for the WordPress performance team this year. The rationale behind this may also be obvious when looking at the base values: The LCP passing rate of WordPress sites is the lowest performing metric, so it deserves the most attention. On the flip side, even though FID only improved by less than 1%, that is perfectly fine given its passing rate is already so high.

Based on these metrics, it can furthermore be concluded that LCP was the primary driver behind the overall CWV passing rate improvements, which confirms the focus on this metric has made sense.

Last but not least, the Time to First Byte (TTFB) passing rate should be highlighted as well: While TTFB is not a Core Web Vitals metric, it is a direct part of LCP (specifically denoting its server-side load time performance portion), and it was another partial focus this year both because of its impact on LCP and because its passing rate is very low. Here is how it improved this year:

  • Mobile TTFB passing rate improved 3.10% (from 18.67% to 21.77%).
  • Desktop TTFB passing rate improved 3.53% (from 28.44% to 31.97%).

WordPress 2023 releases impact

This section focuses on the load time performance impact of the three new WordPress versions released this year, 6.2, 6.3, and 6.4. Since the focus for all of these releases was load time performance, it is sufficient to focus solely on LCP and TTFB.

While the overarching WordPress metrics from the previous section were based on a broad year-over-year comparison, the metrics to assess the release impact were queried with a more granular approach: For each WordPress version, a dataset was established between two months based on only the intersection of sites that were on the previous WordPress version in the first month and on the newer WordPress version in the second month. The months were then chosen in a way to maximize the size of the dataset (e.g. a WordPress version always sees the highest usage in the month before the subsequent version is released).

While that approach is still by no means an A/B comparison, it eliminates at least a good portion of noise e.g. from sites on other WordPress versions or sites that newly entered or dropped out of the dataset.

WordPress 6.2 LCP and TTFB

All metric comparisons are based on the intersection of WordPress 6.1 sites in March and WordPress 6.2 sites in July. See relevant WordPress 6.2 slide.

  • Mobile LCP passing rate improved 0.01% (from 34.98% to 34.99%).
  • Mobile TTFB passing rate improved 0.65% (from 18.47% to 19.12%).
  • Desktop LCP passing rate improved 2.13% (from 46.85% to 48.98%).
  • Desktop TTFB passing rate improved 3.89% (from 25.79% to 29.68%).

WordPress 6.3 LCP and TTFB

All metric comparisons are based on the intersection of WordPress 6.2 sites in July and WordPress 6.3 sites in October. See relevant WordPress 6.3 slide.

  • Mobile LCP passing rate improved 4.72% (from 34.46% to 39.18%).
  • Mobile TTFB passing rate improved 0.78% (from 18.78% to 19.56%).
  • Desktop LCP passing rate improved 1.96% (from 48.55% to 50.51%).
  • Desktop TTFB passing rate decreased 2.15% (from 29.28% to 27.13%).

WordPress 6.4 LCP and TTFB

All metric comparisons are based on the intersection of WordPress 6.3 sites in October and WordPress 6.4 sites in November (since newer data is not available yet). See relevant WordPress 6.4 slide.

  • Mobile LCP passing rate improved 0.30% (from 37.40% to 37.70%)
  • Mobile TTFB passing rate improved 0.11% (from 18.21% to 18.32%).
  • Desktop LCP passing rate improved 0.13% (from 49.46% to 49.59%).
  • Desktop TTFB passing rate decreased 0.31% (from 25.88% to 25.57%).

Remember that all of the above metrics are just indicators and an approximation of the field impact of those releases, influenced by several factors. It’s also great to keep in mind that the adoption of those versions will continue to grow. For example, as of November ~68% of all WordPress sites were using version 6.2 or newer based on the dataset. As the adoption increases further, the performance wins from those releases will continue to scale horizontally and benefit more sites.

WordPress 2023 impact on the web

WordPress, with its high usage, has a large footprint on the web, making a significant impact on the entire internet. When WordPress performance improves, the web’s performance improves. Therefore, last but not least, let’s look at the performance impact that WordPress has had on the web overall.

A good starting point for that is to compare the 2023 CWV passing rate improvement of all WordPress sites with that of all sites not using WordPress:

  • As mentioned before, WordPress’s mobile CWV passing rate improved 8.13%.
  • The non-WordPress mobile CWV passing rate improved by 3.68%.
  • Similarly as mentioned before, WordPress’s desktop CWV passing rate improved 8.25%.
  • The non-WordPress desktop CWV passing rate improved by 5.29%.

From those numbers alone, it is clear that WordPress has made notably more progress in performance than the rest of the web, which is an amazing achievement.

It is furthermore possible to draw some conclusions on how much WordPress’s impact on the overall web’s improvements are. For reference, the overall web’s CWV passing rate improved 5.35% on mobile and 6.26% on desktop. Based on that, a simple calculation can be used, subtracting the non-WordPress CWV passing rate improvement from that of the entire web. This leads to the following results:

  • 1.67% of the overall web’s mobile CWV improvement of 5.35% comes directly from WordPress.
  • 0.97% of the overall web’s desktop CWV improvement of 6.26% comes directly from WordPress.

While those numbers may seem small, this is literally WordPress’s impact on CWV for the entire web! It is an excellent reminder of how important WordPress’s role is for the web and how contributing to WordPress not only improves the WordPress ecosystem but also the entire web.

Considerations for 2024

With this recap of the 2023 CWV impact of WordPress, it is time to look ahead and plan for 2024. In particular there are two important considerations for the performance focus next year.

INP replaces FID as a Core Web Vitals metric

Earlier this year, a notable change to the CWV metrics was announced: The more recently introduced metric Interaction to Next Paint (INP) will replace First Input Delay (FID) in early 2024. Please refer to the linked articles for additional information on the metric and that change. The very short summary is that INP measures interactivity more accurately than FID, and due to its limitations FID ended up having very high passing rates throughout the web ecosystem – almost perfect as seen in the WordPress numbers before.

The INP metric and its "good" threshold of 200ms or lower
This visualization shows the new INP metric and its thresholds.

Since INP measures interactivity more comprehensively than FID, it implies that passing the INP assessment is more difficult than passing the FID assessment. In other words, the INP passing rate is expected to be lower than the FID passing rate. Once INP is taken into account for CWV instead of FID, this will therefore lead to a decline in the overall CWV passing rate as well. In reality, the difference is particularly relevant on mobile devices. Here is a comparison of the FID passing rate and INP passing rate of WordPress sites, based on October 2023:

  • Mobile FID passing rate is 97.42%, while mobile INP passing rate is 71.48%.
  • Desktop FID passing rate is 99.97%, while desktop INP passing rate is 98.47%.

While there is a small decline on desktop, it isn’t really worth focusing on as the value is still extremely good. But for mobile, the decline is significant. In other words, it will be important in 2024 to find ways in which WordPress can improve INP passing rates on mobile, in order to make up for the loss compared to FID.

Of course this is not only relevant for WordPress, but for the entire web. Here is how the mobile CWV passing rate would change if INP was already replacing FID today (data based on October 2023):

  • WordPress’s mobile CWV passing rate would be 3.64% lower (32.80% instead of 36.44%).
  • The non-WordPress mobile CWV passing rate would be 7.39% lower (40.58% instead of 48.02%).

Based on these numbers, it is at least a little comforting that WordPress will struggle with this change less than the rest of the web. Nevertheless, 3.64% CWV passing rate decline is a significant drop, so part of next year’s performance goals will be to make up for that loss, likely through a combination of INP focused improvements and a continuation of the LCP focused efforts.

TTFB focus was less impactful than (client-side) LCP focus

The second consideration for 2024 is not related to a metric change, but rather a potential takeaway from the 2023 metrics highlighted in this post: When looking at the WordPress release specific impact, it can be noted that the mobile LCP improvement was by far the highest in the 6.3 release (4.72%, compared to <1% for 6.2 and 6.4).

The WordPress 6.3 release included a number of client-side LCP enhancements, which likely led to a large chunk of those improvements, as more granularly indicated by the findings from the related field analysis from a few months ago. WordPress 6.4 and especially WordPress 6.2 were more focused on server-side LCP enhancements (i.e. TTFB enhancements), and based on the field results those releases did not lead to as large LCP wins. Even for TTFB, the picture isn’t entirely clear: As expected, WordPress 6.2 has a much better TTFB win than 6.3 on desktop, but on mobile devices the two releases show almost equal TTFB wins, with 6.3 even slightly higher.

While those numbers are by no means evidence, they raise the question whether the TTFB focus in WordPress core is the right way to move the needle for load time performance. Potentially the influence of other factors outside of WordPress core on TTFB, such as plugins, themes, hosting stack, or network connection, are just too large for the core-specific server-side improvements to make an impact in the field.

This does not imply the TTFB efforts should be dropped – but likely a shift is needed. Potentially, the TTFB issues need to be addressed through other means than directly enhancing the server response time of WordPress core itself. Further research should likely be conducted to get a better understanding of how much WordPress’s low TTFB passing rate stems from 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 ecosystem’s performance or other aspects not directly code-related such as hosting.

2024 planning is underway

The WordPress performance team is currently working on their roadmap for 2024. A GitHub issue for performance focused project proposals has been opened and awaiting input. You’re invited to contribute any WordPress performance related proposals or ideas you may have on that issue.

While the 2024 roadmap is currently being planned, let’s once again circle back to 2023: The amazing metrics shared here speak for themselves. Thank you to everyone who contributed to WordPress’s incredible performance impact in 2023!

Props to @annezazu @westonruter for review and proofreading.

#analysis, #core-web-vitals, #core-performance, #performance, #retrospective

Performance Chat Summary: 12 December 2023

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

Announcements

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @thekt12 update on various items:
  • @joemcgill Essentially, block variations for several dynamic blocks are built dynamically on every request, but from what we can tell, they’re only needed in the editor, so we should be able to support registering a callable that will dynamically build the variations when requested. I’d like to get feedback from someone on 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/ side more familiar with how these are consumed (e.g., @mamaduka, etc).

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • No updates this week

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 project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

  • @flixos90 I drafted a module proposal for the Speculation Rules 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. integration last week: https://github.com/WordPress/performance/issues/897
    • The formerly experimental draft PR has been polished to become the foundation for that new module: https://github.com/WordPress/performance/pull/733
      It’s targeting a feature 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". as it’s not yet the entire MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia module functionality yet, as outlined in the module proposal issue

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @westonruter For Image Loading Optimization, the pull request for improved breadcrumb handling of images to optimize is still ready for review.
    • I have a sub-PR off of that in which I’m nearing full PHPUnit test coverage. Hopefully I’ll complete this today and it will also be ready for review.
    • After these are reviewed and merged, I’m eager to enhance with background-image optimization. I’ll probably start with a sub-PR while waiting for the above to be merged.
  • @flixos90 I wonder whether we should focus on getting the module ready for launch first before moving on to another feature like BG image support. I feel like optimizing <img> tags is the primary focus here, so probably sufficient for an MVP
  • @westonruter It won’t be much additional code though and the groundwork is in place, so that’s why I want to target it.
  • @flixos90 Sounds good, we can assess further in the PR, that’s helpful to have regardless
  • @flixos90 From my side, I ran a couple queries last week to kick off further field research on fetchpriority accuracy problems: https://colab.sandbox.google.com/drive/1KCowq4J2oPnxmjXjQVTpO5d6sC9qi8s1 At this point I’ve only gathered some data, and I still have to think further what to make of it or what else to query. But it’s a good starting point I think
    • The approach for these queries was to only consider URLs that have the same LCP image element for both desktop and mobile, as that’s the only problem vector we can address with the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality. If the LCP element differs, it’s more difficult and can’t be addressed with the fetchpriority="high" attribute. That part is covered by the image loading optimization module @westonruter has been working on
  • @swissspidy Regarding images, I have been working on this client-side image compression project a little bit: https://x.com/swissspidy/status/1733138082591912154?s=46&t=f5Z4bXmUuYQYdSgET7F2UQ
  • @swissspidy Speaking of fetchpriority, that just landed in Safari 17.2 yesterday

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • No updates this week

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo for 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

Contributors: @mukesh27 @swissspidy

  • No updates this week

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

Open Floor

  • @pbearne I have replied/updated the Disable autoload for large options 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. https://core.trac.wordpress.org/ticket/42441

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

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

Performance Chat Summary: 5 December 2023

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

Announcements

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @joemcgill #58196 has a PR that could use another set of eyes, but can probably be committed. However, turns out this does not solve a big performance issue, but instead the parent function needs to be looked into instead.
  • @swissspidy For i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. performance I am nagging people for code reviews again at the moment. Otherwise there hasn’t really been any progress.
  • @joemcgill I was reviewing #55595 earlier today, and noticed that widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. registration itself does not really account for much of a performance cost, but rather rendering widgets that can be costly. I think we can likely close that ticketticket Created for both bug reports and feature development on the bug tracker. as `maybelater` but would like a 2nd opinion.
    • Additionally, I noticed that you can already use the `load_default_widgets` filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to keep WP from loading default widgets, but doing so will cause a fatal if you don’t also unhook `wp_widgets_init`, because that function will try to register the default widgets even if they haven’t been loaded. This seems like a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., although not a critical one.
  • @thekt12 Removing call to build_template_part_block_variations on the fontend showed a decent performance improvement -> https://core.trac.wordpress.org/ticket/59969#comment:8 Additionally we did identify two more palaces where the same improvement could be made. Currently I am addressing PR review comments.

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

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 project and link to the GitHub project board

Contributors: @mukesh27 @flixos90 @westonruter

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @westonruter Pull request for applying the image optimizations is in review and nearing merge (to the feature 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".)
    • I also have sub-PR opened which makes breadcrumb processing more reliable. (In other words, an XPath for a given image that needs optimization.) Also ready for review.
    • Now that the feature is fully functional I’m going to add test coverage (which I neglected before getting a working prototype in place).
    • I also want to extend the existing logic to also handle CSS background images, whereas currently only img elements are optimized.
    • I’ve also started filing issues under the module’s label for areas where others can contribute.
  • @joemcgill Still working on a proposal for improving the default sizes implementation in WP using available layout data. Also, seeing some progress being made on the browser side implementing the new auto sizes HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. spec, which would be a huge improvement for WP, since we lazy-load many images by default.
  • @swissspidy As for images, I have been looking a bit more into client-side image compression (in 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/) lately to see where this could fit in 2024 plans.

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • No updates this week

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo

Contributors: @mukesh27 @swissspidy

  • @swissspidy No update either from my side, though I just published a small blog post to help spread the word a little bit about 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 Check

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27

Open Floor

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

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

Hallway Hangout: Performance End of Year Review 2023

Following up on the prior performance related hallway hangout for WordPress 6.3, and hallway hangout for WordPress 6.4, @flixos90 @joemcgill and @clarkeemily co-hosted an end of year hallway hangout to review the WordPress performance enhancements from 2023, and a look ahead to 2024!

The Hallway Hangout took place at 2023-12-07 16:00 and the Zoom link was shared in the #core-performance SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel before starting.

At a high level, we went through the following agenda:

  • Quick intros (what each person does/focuses on)
  • Review of WordPress performance improvements throughout 2023
  • Retrospective sharing field data for the cumulative performance impact of the team’s work in 2023
  • Discussion around interpretation of metrics
  • A look ahead to 2024 plans

As a reminder, hallway hangouts are meant to be casual and collaborative so folks came prepared with a kind, curious mind along with any questions or items they wanted to discuss around this important area of the project, especially since the agenda was intentionally loose to allow for it.

Noting this specifically for folks who expressed interest previously or who are involved directly in this work cc @hellofromtonya @aristath @oandregal @annezazu @tweetythierry @desrosj @youknowriad @dmsnell @pbearne @swissspidy @westonruter @adamsilverstein @mukesh27 @joemcgill @johnbillion @10upsimon @thekt12 @linsoftware @pereirinha

Recording

Attendees:

@pbearne @joemcgill @clarkeemily @flixos90 @thekt12 @swissspidy @adamsilverstein @westonruter 

Notes

@flixos90 presented the WordPress Performance 2023 CWV Impact Retrospective slide deck, thank you very much for pulling this together Felix.

Please click the image above to view the slide deck

INP Discussion

@adamsilverstein @flixos90 @pbearne were discussing whether INP mobile scores are due to lower powered mobile devices. The team discussed whether there may be an answer we can find. Mobile passing rate is more of a problem with INP (high chance it’s because of low powered devices). It could be networknetwork (versus site, blog) conditions as well, but lower powered devices likely to be the cause. @pbearne did raise: what would be the fix, low res images? How could we support under-powered devices? @flixos90 commented that for INP specifically it’s about 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/.. The amount, and how it’s executed, i.e. using a worker thread comes to mind that can improve INP. WordPress doesn’t have support for worker thread. This could be a good opportunity. More about the actual JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. code, reduction of JS code and optimizing JS code. 

It was suggested that 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 tool could help with? Are there any optimization tools to help here? General consensus is that folks are just not sure. @adamsilverstein mentioned that it’s not just static analysis, these INP issues don’t tend to come up, it’s more in the field when there’s a lot of JS interacting on the page simultaneously. Complicated layouts also contribute to low INP, DOM layouts — but unsure if this is our problem. Maybe likely to be in the front end, themes. Also in the combination of things, animations, app providers, tracking etc, these things add up and compete for resources on a low powered device. @westonruter shared How to diagnose slow INP in the lab: https://web.dev/articles/manually-diagnose-slow-interactions-in-the-lab.

@flixos90 highlighted the Interactivity 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. (very new and not publicly available) this is the first WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. own JS API that is just starting to be rolled out. This would allow plugins to use an API allowed by core, htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. directives, could we improve INP through the interactivity API — great potential opportunity for the future. Static analysis in the plugin checker, could look to pointing plugin checker to interactivity API. Prevalence of cookie consent policies, are these contributing to low INP scores? The team feel this is potentially low hanging fruit as 90% of sites need one now.

@joemcgill mentioned the tricky part here is the big services that provide cookie consent provide their own JS code to drop in the page, integrations would be more challenging. @pbearne mentioned a simple basic one that works would be great. Could it be done in a way where you don’t get penalized in the stats. The team agree this is worth looking into. @pbearne asked if this could this be the case of analyzing the top 20 cookie consent plugins and see if they can be made into a canonical plugin and build from the ground up? However the potentially, tricky thing is building something into core will require extensibility similar to how the privacy policy feature was built, driven by legal requirements that are different in all places. If the extensibility is made too flexible, it may cause more INP problems.

Cost Analysis

@pbearne highlighted that there’s no tie back to numbers, costs etc in the presentation from @flixos90 — cost of search engines crawling the save in value, cost saving of hosting companies etc — wondered if there’s a way we can obtain any dollar values against what these performance improvements actually mean. @flixos90 advised that we can try to draw general conclusions but mostly to get real numbers is do individual case studies, maybe there are hosting providers that are happy to share how much LCP improved and what this means for revenue / cost, specific case studies would be the way forward here, it would be difficult to establish this more widely. Maybe there’s a call we can put out to ask any hosting providers if they’re willing to do a case study

TTFB Improvements

@joemcgill went on to discuss the second to last slide, idea that we can get more benefit from focusing on FE LCP improvements, the underlying TTFB improvements — this was Joe’s initial gut instinct, websites that care about performance fix TTFB by not hitting WP application at all, using aggressive page caching etc. However, mindful at the fact that WP 6.3 we had 2 big opportunities that had a big impact on client slide: removal of emoji loading script and image loading improvements (the addition of fetchpriority and the lazy loading improvements). Whilst focusing on FE LCP improvements are easier, do we have opportunities of similar scale that would make sense, or are we just driving server side?

@flixos90 added that the difference is that most of client side improvements that we have done are larger efforts, whereas improving server side cut off milliseconds that add up over time. There may be a point where we have no idea what to improve on the client side, but there are a few things mentioned on image sizes attribute is one of them, optimizing how large images are loaded, continuing to optimize fetchpriority and lazy loading are applied, will drive up the passing rate more. Felix added, the main indicator is when we look at mobile, this is where the big difference is happening, when you look at LCP and TTFB together, but LCP in 6.3 was a lot more (probably came from client side improvements predominantly). Desktop TTFB was more visible than mobile. We always benchmark on a desktop machine, so mobile devices are lower powered. Maybe it’s just because for mobile specifically TTFB improvements have a lower role, and it’s more about the device configuration.

@joemcgill went on to ask whether we’re just looking at the % that are getting good scores, rather than the value of TTFB or change in TTFB metric. Could we have made the same amount of improvement as desktop, but not a big enough value to go over the threshold of the passing rate. Felix mentioned he has looked at these numbers as he has assumed the same thing. When you look at aggregated data, there weren’t major improvements in similar ways. Overall scale is still not visible. 

2024 Suggestions

@pbearne suggested images, do the amounts of images in the media library impact going through file numbers, orphan image sizes left around — should we have a tool to help clean this up? Some images are left behind from changing themes etc, does this bloat the number of images in the file system? If it does, would a simple tool help remove images that are not current. Here, @adamsilverstein suggested that some regenerate thumbnails plugins, URLs still point to old images if they’re removed. Thinks everyone has things in folders, if people have them in one giant directory it would impact. File loading may not be an image, but one place to look at was maybe the attachments in posts database, when doing lookups etc, maybe there are places we can eliminate here — but suspect this is a small improvement. The remaining images are mostly about storage space wasted and incurring costs. For performance on end users, doubt this has a notable impact.

@pbearne also added that the interactivity API would be a great place to investigate. @flixos90 added we should think for next year what can we do to improve interactivity, facilitate WP sites having more responsive interactions. The new metrics means this is more significant. Load time performance, but split this more to cover interactivity. The team discussed any other intentional research what leads to lower INP passing rate, hypotheses have been created but could do with having confidence in knowing where the problems lie. More research is definitely needed.

@flixos90 continued, what do the TTFB numbers mean for us? This year we have been focused on improving TTFB in core, but thinking about mobile representation, are there other ways we should try to move forward TTFB — what about enhancing APIs to provide more guardrails to plugins, there are a lot of other components to this, could argue that small changes don’t cover lower powered — something core can do better to facilitate caching for more people. Can we unlock caching for sites that have hosts that don’t provide this feature etc. @joemcgill added that we had talked about trying to use the SQLite Database as an object cache for sites that don’t have a better option — could we think on this again?

@flixos90 liked this idea, worth exploring — this would be for object caching, could we use it for page caching? Persistent object cache avoids using database requests, not that significant for overall performance. Full page caching would be more beneficial to focus on. Avoiding hitting application altogether could be better. Was looking at full page caching in the CWV dashboard, surprised that the popular caching plugins their TTFB scores are not beating the general WP TTFB numbers, seems counter intuitive. Could we dive into this more? Were these plugins specific to having the full page caching, could not be turned on. @adamsilverstein added that we can get a geographical bias, if the plugin is popular in a region with slower internet, it’s not their problem its the users. @adamsilverstein highlighted that you can breakdown on the settings page of the CWV report by geographical region. Could query this in 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 see if there are patterns. Other considerations are all WP plugins that offer full page caching offer this at the application level, not as good as having the layer at the hosting level.

Concluding Statements

@pbearne raised that as a plugin developer, having good tests or validations that I’m doing it right, i.e. plugin checker, improving this and helping you recognise where improvements should be made, is something that can improve overall performance. More work in this field would benefit overall, especially if we can do themes as well.

@joemcgill concluded that the team are thankful to Felix for pulling these numbers together, easy to not be able to see the big picture. But really great to see the impact the performance team has made is great to see!

Props to @joemcgill for proof-reading and to @flixos90 for the excellent presentation.

#core-performance, #hallwayhangout, #performance

Performance Chat Summary: 28 November 2023

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

Announcements

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @joemcgill Main thing happening here at the moment is the ongoing template loading work, captured in this tracking issue
  • @thekt12 Did some profiling for #58196 Performance metrics didn’t show any improvement which is kind of not what was observed in blackfire. https://github.com/WordPress/wordpress-develop/pull/5281#issuecomment-1830164940
    • @joemcgill That’s interesting. I wonder if it’s due to profilers like Blackfire not getting the benefits of the opcode cache? I can try to reproduce locally
    • @thekt12 I am not so sure about that. May be you could try and see what you observer.
    • @joemcgill Will do. I like the removal of the file_exists check and memoizing the path list regardless, so we may want to commit this anyway as a test to see if we could cache this for longer than the current request?
    • @thekt12 Yes we can do that
    • @johnbillion Last time I did some profiling with Blackfire I also saw a very different scale of improvements compared to profiling the code in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher without it. It has a much greater overhead than I expected.

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • @mukesh27 I worked following PRs:
  • @thekt12 not a performance related thing but still something introduced by caching #59661
    • 2nd scenario in this – https://core.trac.wordpress.org/ticket/59661#comment:7 is something I feel is hard to solve, I just wanted to know do we add dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. in such a scenario.
  • @pbearne Mad Idea (may not be new): Could we store all the files in site in a cache and then only check file exists if not in cache and invalidate when we fail to open a file that cache said it had and was missing
  • @joemcgill file_exists checks have shown to really not be that expensive in production due to the opcode cache, but there are places where we could avoid using them and instead read the file in a try/catch 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. and handle the errors gracefully.
  • @joemcgill For longer-term caching of file content that is expensive to read and parse (e.g., block patterns, etc.) this issue is worth following: #59719

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 project and link to the GitHub project board

Contributors: @mukesh27 @westonruter @flixos90

  • @joemcgill Last week I resolved #58632 as maybelater based on @westonruter analysis that showed that >86% of inline scripts are printed before the script they’re attached to, so making inline scripts deferrable do not seem like a priority for now. Better to document for developers how to use this feature in a way that ensures they’re not forcing their scripts to be blocking. I think we can conduct another analysis in the future to see how often async/defer scripts are being downgraded to blocking scripts due to this problem, using the data-wp-strategy attribute we add to mark intended strategy for debugging purposes

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @westonruter Image Loading Optimization is now working end-to-end! After the pull requests for detection and storage have been merged, I’ve now got drafted a PR for the optimization piece. It’s nearing ready for review, hopefully today.
  • @joemcgill I’ve got a draft of a proposal for updating our default sizes attribute in progress using the layout properties from theme.json an observation is that it would be really nice to find a more declarative way to understand the root padding values that are currently referenced in theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. by their CSS variable names. Not sure if anyone is aware of any other conversations related to that idea that have been started elsewhere.
  • @joemcgill Meanwhile, I noticed several places where 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/ is setting images as background CSS, where our optimizations are not being applied. That could be worth an exploration to see how we can optimize.
  • @westonruter I’m intending to target this as well with Image Loading Optimization
    • @joemcgill I can open a tracking issue in our performance repo
  • @westonruter At the moment it’s just targeting img elements to optimize, but it has the pieces to also preload background images.
  • @joemcgill I’m more concerned about the use of very large file sizes, but proper resource hinting would be good to handle as well
  • @swissspidy Speaking of very large file sizes, I’m looking into the client-side image compression work in GB, to see what can be done for 6.5
    • @dmsnell not sure if you know libvips or not, but I noticed they have a WASM build. it’s killer feature, in my opinion, is the ability to stream image operations and avoid loading entire large images in memory at once. Also it’s just a really high quality library

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • @adamsilverstein I’ve been working on getting 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 / automated performance testing adoption, making some slow progress
  • @joemcgill There was a strange issue with @mukesh27 PR earlier today. The Performance Test failed due to twentytwentyone not being available. There is a new PR running now that I’m watching to see if it also suffers from the same issue. Something we may need to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. today

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo

Contributors: @mukesh27 @swissspidy @westonruter

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

  • No updates this week

Open Floor

  • @adamsilverstein I have a couple of items. First, I wanted to share this Issue on WooCommerce – https://github.com/woocommerce/woocommerce/issues/41556 which reports some compatibility issues after they moved a script to the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and used defer (originally it was in the footer)
    • … after they adopted the script strategy feature
    • some of the issues may be fixed “upstream” or they may revert the change. in any case, I think it is interesting to see the challenges large plugins like this have making a change/adopting a new approach
  • @adamsilverstein 2nd: I have created a proposal for an oEmbed optimization module for the PL plugin – https://github.com/WordPress/performance/issues/888 appreciate any feedback
  • @pbearne #42441 has moved on, do we need a proposal for this to go into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.?
    • @swissspidy To me that ticketticket Created for both bug reports and feature development on the bug tracker. is the proposal 
    • @flixos90 Yeah, I don’t think it needs a proposal. Just potentially further discussion on the ticket. I left some thoughts there last week
    • @joemcgill I’d like to get feedback from more folks outside this group. I’m still personally uneasy about making this decision without more input outside this group. I’d raise it in a dev-chat at minimum

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

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