Performance plugin from the WordPress Performance Group, which is a collection of standalone performance modules.
Home Page: https://wordpress.org/plugins/performance-lab/
License: GNU General Public License v2.0
Monorepo for the WordPress Performance Team, primarily for the Performance Lab plugin, which is a collection of standalone performance features.
Details about the Performance Lab plugin, including instructions for getting started and contributing, are available in the Performance Team Handbook here.
For WordPress and PHP version requirements, please see the CONTRIBUTING.md file here.
See previous discussion: WordPress/gutenberg#33578
As outlined in the original proposal doc, the performance plugin doesn't have a name yet. Some ideas were previously discussed in the doc and on Slack, but we can follow up here.
Once a name (and slug!) have been decided for, we need to replace the following in the scaffolded codebase:
TODO-SLUG with plugin slug/textdomainTODO-NAME with (human-friendly) plugin nametodo_snakecaseslug with snake_case version of the plugin slug (e.g. prefix for functions, options, etc.)TODO_CONSTANTSLUG with CONSTANT_CASE version of the plugin slug (e.g. prefix for constants)Each module should include some basic documentation (both user facing and developer oriented) about what it does and how to use it.
README.md in each module's folder root. Primarily for developers who would be browsing the repository.Cache groups are a core concept of the WordPress object cache and it’s an often requested feature to flush an individual group, without flushing the entire cache.
function wp_cache_flush_group(string $group): bool;This would be most in-line with the currently signatures.
We could optionally accept an array as well, I'm not sure about the WP conventions around this.
Blackfire.io is willing to help the performance initiative by providing:
Blackfire provides Profiling, Monitoring and automated Performance Testing.
In the longer run, WordPress.org would have its own organization.
We can use Blackfire to help reach most of the performance targets (as long as PHP is involved).
Blackfire can help us understand how WP is behaving, what happens through time using the timeline, and give us hints on how to improve its behavior. We can also compare profiles, to precisely measure the impact of the changes.
With automated performance tests, we may write up metrics, tests, and scenarios to run on a periodic basis, or even on each PR/push.
Let's discuss this 🙂
As the number of modules is gonna grow, having just /modules/{module-slug} can lead to difficulties when trying to find one.
Maybe a different approach would help us in the future to easily identify, to which focus area they belong to, for instance:
/modules/{focus}/{module-slug}
/modules/{focus}-{module-slug}
@khoipro: Seems most finished and needs testing. If there is an option to toggle this option, it will be the same toggle loading=”lazy” option in each image.
Trac ticket: https://core.trac.wordpress.org/ticket/53232
Recommend the use of an object cache under Site Health for sites with non-trivial amounts of data.
Would you see this as being something that checks for APCu, or a reachable memcache / redis install?
Adds the ability to regenerate existing images in core via a user interface.
This is an overview of related issues. This may not necessarily be comprehensive, for a full list see all issues related to the "Regenerate Existing Images" module here. When opening a new issue related to this feature, make sure to add the [Module] Regenerate Existing Images label.
Module proposal: #445
The purpose of this module is to provide administrators with a user interface to regenerate images in core without the need for an additional plugin or use of WP-CLI. This makes the feature more accessible to non-technical users.
As the regeneration of images is time consuming, and cannot be performed in a single request or a few AJAX requests, a new background process infrastructure will be created to handle long running tasks.
As part of an effort to improve performance within WordPress, the Performance team has introduced WebP images into core. Providing administrators with a means to regenerate their existing images to create WebP versions will improve performance across their site.
Additionally, when administrators install and activate a new theme, existing images may be served at incorrect sizes, which can have a negative impact on performance. By providing an accessible way to regenerate these images, we can ensure that the correct sizes are served on the frontend and improve the site's performance.
The module can be seen as 2 parts: 1) the background processing infrastructure, and 2) the admin user interface and job to regenerate images.
The background processing infrastructure will be created to handle long-running, time-intensive tasks. It will be decoupled from the logic to regenerate existing images and can be used for any types of jobs.
The Regenerate Images job will utilize the background processing infrastructure to handle the regeneration of images. This will work alongside with a new admin settings screen to trigger the regeneration of images.
Additionally, other entry points across WP Admin can be created to trigger the regeneration of one or more images more contextually: for example, a bulk action in the Media Library or Gutenberg controls to regenerate all images in a post.
As this is a large feature, it will need to be broken down into multiple phases that build from one another. Each phase of the feature will first be introduced into the Performance Lab plugin and released before the next phase for testing.
To help with the release a separate branch will be created to act as a feature trunk branch. This branch will be used to develop and review the feature in parts. Once the feature is complete the feature trunk branch will then be merged into the Performance Lab plugin.
The first phases will include creating the Background Processing Infrastructure, the Regenerate Images Job, and Admin settings screen. Each phase will first be released to the Performance Lab plugin for testing and ultimately later merged into WordPress core.
A breakdown of the phases can be seen below:
WP_User_Query class (40613)wp_term_query on cache ids (37189)posts_request_ids query (22176)WP_Query (36904)get_terms internally (36949)WP_Term_Query (54511)wp_cache_*_multiple functions (54574)This task was suggested by Aymen Loukil for the image focus, however it may fit better in the measurement focus.
This issue is about creating a /docs/Getting-started.md file with the most important information needed to contribute to the performance plugin. That documentation should follow a similar structure like Gutenberg's https://github.com/WordPress/gutenberg/blob/trunk/docs/contributors/code/getting-started-with-code-contribution.md, e.g.:
We should also include there with which WordPress and PHP versions the code should be compatible, which ties into a greater product question: Which WordPress and PHP version should we require and how far back do we support?
^ That is probably the main question to answer here before we can get started with the documentation.
In addition to the above file, which is the main part of this issue, we should also add the regular CONTRIBUTING.md file. That one can be really short and mostly link to the above documentation file. At a high level, we can look at Gutenberg's https://github.com/WordPress/gutenberg/blob/trunk/docs/contributors/code/README.md and https://github.com/WordPress/gutenberg/blob/trunk/CONTRIBUTING.md for inspiration what to include here.
The main part of this issue will be coming up with the above documentation in a PR and reviewing it.
At the moment, WordPress does not store the file (storage) sizes for uploaded files, or the sizes of media generated, in the database. At the moment, whenever WordPress needs to find out this information, it needs to read from the filesystem, or make remote requests in the case of a CDN. This keeps WordPress from using this information to make more informed decisions about responsive images or resizing in a performant fashion.
We should store file sizes as attachments are uploaded, and use this information in appropriate existing locations in core where file size is queried.
Trac ticket: https://core.trac.wordpress.org/ticket/49412
See https://web.dev/preload-responsive-images/
https://web.dev/priority-hints/
https://caniuse.com/?search=resource%20hints
related "Automatic link preload of first user-entered image (hero image)" (suggested by Aymen Loukil)
related trac ticket: https://core.trac.wordpress.org/ticket/42438 (focused on scripts so far, could include images)
Open Question: when is preloading images helpful?
As per @felixarntz suggestion in #2, should we set up a CODEOWNERS file to automatically assign issues and PRs?
It would help reduce the noise.
Based on #41 (comment), we should have a GitHub workflow that ensures that every pull request has the necessary labels and milestones. This can later be set up as a requirement that has to be met before a pull request can be merged.
Here's the specifications that the GitHub workflow should implemented (based on #41 as well):
[Type] xyz labels. This is used to group pull requests in the changelog.[Focus] xyz labels or the Infrastructure label. This is used to further categorize and prefix pull requests in the changelog.no milestone label. This is used to define which release a pull request belongs to, or to explicitly define that a certain issue is "release-irrelevant" and therefore does not need a milestone.It's a good idea to add the files to our repository. I suggest we use exactly the same those from Gutenberg which would apply just like that to this repository as well:
In the PR that adds these two files, it may also be good to update the CONTRIBUTING.md file (from #47) to link to those - we could use the exact same content from the Gutenberg repository (see https://github.com/WordPress/gutenberg/blob/trunk/CONTRIBUTING.md#guidelines and https://github.com/WordPress/gutenberg/blob/trunk/CONTRIBUTING.md#reporting-security-issues) as well.
WP VIP has several wrappers for core functions that are cached, should we adopt some?
Similar to #4.
When images are inserted from a URL in the block editor, the resulting HTML should include the image width and height in order to avoid layout shift. Currently it does not.
Fix might need to be in Gutenberg, adding this ticket here since it can impact image performance.
Trac ticket: https://core.trac.wordpress.org/ticket/54356
Current in progress PR: #73
Related trac ticket: https://core.trac.wordpress.org/ticket/42920
See this comment for a detailed description: #21 (comment)
Original description:
Use picture element to enable modern formats like AVIF with fallback to more widely supported format like WebP or JPEG, including responsive srcset markup like current images. Issue - adamsilverstein/modern-images-wp#1 . references: The anatomy of responsive images - JakeArchibald.com & markup: I just want an image on my page
A good initial test case for this feature would be generating WebP images and JPEG images on upload, then using the picture element to specify the WebP with JPEG as the fallback. Although this scenario isn't likely to be that useful, it will set the path for the same approach with other formats.
The LQIP approach, popularized by Medium, uses a very small placeholder image to enable a quicker initial page load. The idea is the placeholder gives the user a sense of the image shapes and color while consuming minimal bytes. The hires image then replaces the placeholder later in the page load cycle.
The approach may help with perceived performance, although in general more bytes will be consumed overall - the extra image, plus the JavaScript to make the placeholder work. This approach deserves more research and might remain plugin territory.
previously: adamsilverstein/modern-images-wp#19
Trac ticket: https://core.trac.wordpress.org/ticket/52788
@adamsilverstein has been working on a POC for webP images by default in WordPress. Once we have the Performance plugin skeleton almost in place, we could add a WebP module and port the applicable code over.
Looking at WP_Object_Cache to see if we can improve it overall, including the handling of mega objects, such as the alloptions key.
Platform.sh is a PaaS that can be easily leveraged to deploy any app.
In addition to #43 (P.sh owns Blackfire), we're also willing to help on the infrastructure side by providing one or several free Platform.sh projects.
We would be able to deploy automatically any branch/PR, and thus run some tests (e.g. Blackfire automated tests).
WDYT?
Trac ticket: https://core.trac.wordpress.org/ticket/51228
This issue is to discuss creating a standard VM for performance testing of WordPress.
The idea is to create a reproducible VM (using Docker/Vagrant/whatever) for testing WordPress with all tooling included' and 'Base WordPress installs' that could encompass a generic blogging setup (possibly using https://wordpress.org/plugins/fakerpress/), a generic ecommerce setup (100's of products, categories, etc), and a generic business full-site editor setup (Divi/Elementor/etc).
For a local VM, a few options exist that could be 'the standard':
https://hub.docker.com/_/wordpress
https://bitnami.com/stack/wordpress/installer
https://marketplace.cloud.vmware.com/services/details/turnkey-wordpress-appliance/?slug=true
http://vccw.cc
https://varyingvagrantvagrants.org
There would need to be a common list of plugins that would be installed as well for each reference installation as well as its database (pages, posts, media). Thoughts ?
This is an overview of related issues. This may not necessarily be comprehensive, for a full list see all issues related to the "WebP Uploads" module here. When opening a new issue related to this feature, make sure to add the [Module] WebP Uploads label.
The repository already contains the foundation for PHP unit testing and linting, particularly the latter already works out of the box right now. This issue is about completing the setup so that the repository offers easy PHP unit testing capabilities that can be run locally and in CI (GitHub actions) without separately setting up WordPress or a MySQL database.
The suggested approach is to mostly copy how Gutenberg does this, as it allows us to rely on an established approach and reuse the @wordpress/env package - this way we don't need to worry about most of the complexities, plus we get a development environment for the plugin out of the box.
For the scope of this issue, linting and testing of non-PHP code (e.g. JS, CSS) should be excluded. This is to keep things simple and since PHP linting and test coverage is the most crucial for this plugin initially, since the plugin at its foundation is PHP, and we don't have any JS or CSS code yet.
Before starting to write code for any modules, we will need to define exactly what a module should look like. Some ideas for this were already mentioned in the plugin proposal doc, so let's use this issue to expand on those.
The performance plugin should eventually include a settings page that lists all available modules, where the user can individually toggle them on/off.
The proposal is the following:
/modules/{moduleSlug} directory./tests/modules/{moduleSlug} directory./modules/{moduleSlug}/load.php file that should be the "initialization" file of that module. Simply requiring that file in other PHP code should trigger that module's functionality - i.e. it should be similar to how WordPress plugins work.Module Name: The title of the module (comparable to Plugin Name for plugins). This should be displayed on the performnace plugin's settings page.Module Description: Brief description of the module (comparable to Description for plugins). This should be displayed next to the module name on the performance plugin's settings page.Module Focus: Identifier of a single focus area (e.g. images, or javascript, or site-health). This should correspond to a section on the performance plugin's settings page.Experimental: Either Yes or No. If Yes, the module will be marked as explicitly experimental on the performance plugin's settings page. While all modules are experimental to a degree (since they are like feature plugins), for some this may apply more than others. For example, certain modules we would encourage limited testing in production for, where we've already established a certain level of reliability/quality, in other cases modules shouldn't be used in production at all.Here's a sample module header based on the above:
/**
* Module Name: My Performance Module
* Module Description: Optimizes x by doing y.
* Module Focus: images
* Experimental: No
*/Let's discuss here. Once we've decided on the approach, a good takeaway from this issue would be to create a PR where we put the resulting specification into either README.md or another (documentation) markdown file in the repository.
Like every plugin, the performance plugin needs a readme.txt. We already have a plugin name (see #1) and a preliminary plugin description (https://github.com/WordPress/performance/blob/trunk/load.php#L5), and we are currently defining WP and PHP version support as part of #39.
What should our readme.txt contain? Any ideas on the detailed outline, what to put in the FAQ etc? Let's brainstorm.
We need to conduct a list of metrics that we need to measure in order to understand whether our changes improve the performance or not. This is the first step we need to make before we can start discussing tools that can help us to measure desired metrics and environments where we will run performance tests.
Since this plugin is intended to improve frontend and backend performance, we will need to conduct two lists of metrics. Please, suggest metrics that you think we need to track and provide some details about why we need them.
Opening this issue to discuss if modules should be activated by default or not, maybe all modules other than the experimental for instance. When someone install the plugin, the expectation is generally that there is some preset for features right away.
If it is justified not to have any modules activated, we should at least guide plugin users to the module activation page, for instance redirecting to settings page upon plugin activation with a notice informing them to activate modules (and/or wp tooltip maybe).
As the performance plugin will be released in the WordPress plugin repository at some point (and also in general 😄), we should think about how to create and maintain a changelog for new features, enhancements, and bug fixes.
Some high level questions:
CHANGELOG.md on GitHub), have the changelog only on the release tags on GitHub, or should the changelog be within the readme.txt file (visible on wordpress.org directly)?The decision for the latter will also tie into #40 - the readme.txt file either needs to continue the changelog itself or a link to where it is at.
The plugin should provide a simple UI (filterable) to enable/disable modules broken down by focus area.
PERFLAB_MODULES_SCREEN constant) should be implemented, with a dynamic list of all modules and a checkbox to toggle each one on/off.Focus definition (see #2).PERFLAB_MODULES_SETTING.modules directory and gathers all available module information from each module's load.php file header. This can largely be copied from the WordPress core function get_plugins() which includes all necessary parsing logic.manage_options via add_options_page().images, javascript, site-health, measurement, and object-caching, as well as a generic other section.enabled sub-setting, associated with the settings section specified in the module's Focus header field.PERFLAB_MODULES_SETTING option.This issue depends on #2 for finalizing the module specification and on #28 for completing the PHPUnit infrastructure necessary to validate that the changes included here work correctly.
Use correct image engine for image type (adamsilverstein/modern-images-wp#13)
Ensure images/feeds use compatible image formats - adamsilverstein/modern-images-wp#25
Once the plugin is released on the wordpress.org plugin repository, we will need to regularly push updates. Since this is somewhat of a tedious and potentially error-prone process, it should be automated: We need a GitHub action that deploys the plugin release to wordpress.org when a GitHub release is published.
Some potential approaches / inspiration:
We don't need this yet, but it certainly doesn't hurt starting to already think about and discuss how we should go about it.
There's a lot of good content — e.g., see (1), (2), (3) — on various preload use cases that can be useful within core and themes. I'll just highlight a few...
- early load of late discovered resources: fonts, stylesheets, hero images, media, etc.
- decoupling fetch and execution: simple "async CSS" (with help of onload), manual scheduling of JS parse+execute, etc.
- as a mechanism to signal H2 push to servers/CDNs
Picked up from track ticket #42438, just parking an issue here which may be closed if it continues to get worked directly as a patch.
#2, #27, and #46 have established the required infrastructure for modules in the performance plugin. While this approach is what we want to use going forward, at this point there is still a crucial problem with it, which is that the user-facing strings within the module header (most importantly the module description) are not translatable, because they are a PHP comment and therefore don't go through any WordPress translation function (e.g. __).
Therefore, wordpress.org currently won't recognize these strings as translatable if we upload the plugin in that state. This issue is about implementing a similar approach to translate that data that is also used to translate plugin header values in WordPress core.
The main difference here will be that we need to generate a PHP file with those translations somewhere. That file doesn't even need to be required anywhere, but it must be included in the deployment to the WordPress plugin repository so that it can recognize the strings accordingly. This is somewhat similar to what Gutenberg used to do early in its development phase where JS translations were not yet available via WordPress core and wordpress.org.
Based on the settings screen from #27 which allows to toggle individual modules on/off via UI, it should alternatively be possible to programmatically control which modules should be enabled. This can be useful for advanced users or environments which would like to use certain modules from the plugin without confronting end users with control over them.
Suggested approach:
perflab_active_modules that filters the return value of the perflab_get_active_modules() function.perflab_add_modules_page()) if the above filter is being used (check via WP core's has_filter() function).#51 and #60 implemented initial JS functionality (not in production, but for plugin maintenance tooling). This includes basic ES linting and formatting relying on @wordpress/scripts, which is what we should rely on here to have an easy-to-maintain setup. What's still missing is a GitHub workflow js-lint.yml that performs the linting check on commits and pull-requests.
See the existing php-lint.yml workflow for when exactly this new workflow should run.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.