The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
The WordPress Performance Team recently published a new plugin called “Speculative Loading” which enables a new technology of the same name to automatically prerender certain URLs on the page, which can lead to near-instant page load times. The functionality is powered by the Speculation Rules APIAPIAn 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., a new web API that allows defining rules for which kinds of URLs to prefetch or prerender.
Please install and test the pluginPluginA 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 to provide feedback to inform further improvements before a potential consideration to include such a feature in WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. You can install the plugin by searching “speculative loading” in WP Adminadmin(and super admin), or via the Performance Lab plugin.
A brief history of prefetch and prerender in WordPress
WordPress core has for several years provided a simple Resource Hints API which allows injecting <link> tags into the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. document that can be used to prefetch or prerender certain resources, among other actions. While prefetching can be useful for certain sub-resources of an HTML document, such as third-party script providers, prerendering goes as far as processing the resource and already performing some rendering offscreen and thus can be useful for entire web pages.
However, using the approach of injecting link[rel="prefetch|prerender"] tags is not very flexible, as the URLs to prefetch or prerender need to be defined as soon as the HTML is loaded. Providing a <link>tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) for every potential anchor link a user may click on the page would be wasteful, while not providing any misses a great opportunity for performance optimization. So far, solutions like Quicklink could be used to dynamically insert <link> tags to prefetch resources in the user’s viewport, which is more flexible, but still far from ideal as it may still excessively prefetch too many resources and requires a JavaScriptJavaScriptJavaScript 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/. library.
More importantly though, link[rel="prerender"] does not actually support prerendering, as the “prerender” value is in fact used for something called NoState Prefetch, which means it is still only prefetching certain resources rather than prerendering them, which for instance would include running JavaScript. Last but not least, the “prerender” value is deprecated at this point.
Introducing the Speculation Rules API
The Speculation Rules API is a new web API that solves the above problems. It allows defining rules to dynamically prefetch and/or prerender URLs of certain structure based on user interaction, in JSONJSONJSON, 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. syntax—or in other words, speculatively preload those URLs before the navigation. This API can be used, for example, to prerender any links on a page whenever the user hovers over them. Also, with the Speculation Rules API, “prerender” actually means to prerender the entire page, including running JavaScript. This can lead to near-instant load times once the user clicks on the link as the page would have most likely already been loaded in its entirety. However that is only one of the possible configurations.
The following code example shows the general syntax of the Speculation Rules API JSON spec and outlines a configuration where any links other than WP Admin or login URLs are prerendered.
The Speculation Rules API allows defining URL patterns for which kind of URLs should be eligible for speculative loading. Rules can be configured to either prefetch or prerender certain URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org patterns. A so-called “eagerness” value can also be specified which dictates how eagerly the prefetching or prerendering should be applied. For example, a value of “moderate” triggers the speculative loading when the user hovers over the link. A value of “conservative” delays this until the user clicks on the link (which still provides a decent performance benefit), while a value of “eager” acts as soon as there is the slightest suggestion a user may click the link. Note that caution is advised with the “eager” configuration in particular as it increases the likelihood of loading URLs wastefully.
In other words, at the time of writing this post end users will need to use either Chrome 121+ or Edge 121+ to get the benefits of this feature. However there are no adverse effects for users on other browsers, as this is a progressive enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. Therefore using the Speculation Rules API on your website is safe regardless of the user base.
As mentioned in the beginning of this post, the WordPress Performance Team recently published a new feature plugin “Speculative Loading” which enables speculative loading of other frontend URLs linked on the page. It inserts a JSON script similar to the previous code example. By default, any URLs linked on the page are prerendered with an eagerness configuration of “moderate”, which typically triggers when hovering over a link. As such, you don’t need to do anything after activating the plugin: it just works out of the box. The plugin also provides a few customization options to tweak the behavior to the site owner’s preference.
The default behavior can be modified via a new “Speculative Loading” section in the Settings > Reading screen. For example, if the site is using JavaScript that is not yet adapted for being loaded while prerendering, the plugin could be configured to only prefetch documents. One could set the eagerness to “conservative” to reduce the likelihood of URLs being loaded without the user navigating to them. Or one could set it to “eager” to increase the chance of the speculative loading already being completed by the time the user lands on the linked URL, which however runs at the risk of wastefully loading several resources. The default of “moderate” strikes a good balance between sustainability and performance.
The rules for which kinds of URLs to speculatively preload can be customized using a filterFilterFilters 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. called “plsr_speculation_rules_href_exclude_paths”. For example, plugins that add URLs to a WordPress site which modify user state just from being loaded could use that filter to exclude those URLs from being prerendered or prefetched.
Here is a code example which would would ensure that URLs like https://example.com/cart/ or https://example.com/cart/foo/ would be excluded from prefetching and prerendering:
At the moment, the plugin should be used to test the feature, and the Performance Team is eager to receive feedback as well as analyze the plugin’s performance benefits on load times.
Down the road, as the browser API and the plugin mature, the possibility of including the feature in WordPress core will be explored. However, in order to get there, additional feedback is needed.
Testing and feedback
Your testing and feedback is crucial to improve the feature ahead of exploring its potential usage in WordPress core. Please consider the following ways to help:
Try different configurations via the “Speculative Loading” section under Settings > Reading.
Debug how the rules added by the plugin trigger speculative loading to understand the feature better and find potential bugs. Refer to ”Debugging speculation rules”.
Integrate your plugins with the “plsr_speculation_rules_href_exclude_paths” filter to exclude certain URLs from prefetching and/or prerendering, if you develop plugins that add interactive or dynamic content to a WordPress site’s frontend.
The WordPress performance team is excited to learn more about how the Speculation Rules API is being used in WordPress sites. Please try the plugin and share your feedback!
This post proposes adding the fetchpriority=”high” attribute to LCP images in WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. to enhance LCP performance. The proposal was created as a collaboration between members of the Core Performance Team.
Context
The fetchpriority attribute is a standard HTML attribute that can be used to indicate to the browser that a given resource should have a particular priority for when it should be considered for loading. Most commonly, using the attribute is recommended with a value of “high”, only on the most important image on a page.
It is a performance best practice to provide fetchpriority=”high” on the single image that is the “Largest Contentful Paint element” in the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. markup, to indicate to the browser that this image should be prioritized over other resources that would compete with it for networknetwork(versus site, blog) bandwidth.
Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text blockBlockBlock 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. is rendered within the viewport.
As mentioned above, the Largest Contentful Paint element can take different forms, it may be an image, text, video, or other resource. However, most commonly the LCP element on WordPress sites is an image, concretely 42.4% on desktop and 38.2% on mobile based on HTTP Archive data from February 2023. Of those sites, less than 0.03% have fetchpriority=”high” on their LCP image, so it is safe to say that introducing support in WordPress core will benefit almost all of them.
You can learn more about the fetchpriority attribute and how it should be used to optimize image performance in this article.
Proposed solution
WordPress core already comes with a mechanism to detect which image(s) not to lazy-load because they are likely in the viewport, which includes the potential LCP image. Bringing fetchpriority=”high” to images in WordPress core should make use of that existing logic for the loading attribute, which was added in WordPress 5.9. However, the two attributes should still function independently of each other. Furthermore, a few additional aspects need to be taken into consideration and implemented as additional heuristics that only apply to the fetchpriority attribute, but not the loading attribute.
Initially, the two attributes may seem like they are opposites. An image that should be lazy-loaded should not have a high priority, and vice-versa. The usage of fetchpriority=”high” however needs to be a bit more nuanced: It should only be loaded on the single most important image on the page. This is different from loading=”lazy” which should be omitted on any image above the fold — which sometimes may be just the LCP image, while in other cases it may be multiple images.
In other words, fetchpriority=”high” should only ever appear on a single image at most.
Scope
While the fetchpriority attribute is available on a few different HTML elements, the scope of this proposal is only to use the attribute on images, specifically to add it to the likely LCP image of a page so that the browser knows to load it earlier than other resources that may be competing with it.
Performance impact
Based on benchmarks conducted by members of the Core Performance Team, adding fetchpriority=”high” to the LCP image typically improves LCP performance by 5-10%, which is a notable win for adding a simple attribute to an image tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). In some instances the enhancements can even be close to 30%, like in an example from the aforementioned article.
Browser compatibility
While the fetchpriority attribute is a relatively new attribute first introduced in 2022, it was standardized in February 2023 and is supported by all Chromium based browsers, which make up for ~70% of browser usage based on caniuse.com. Support was recently added in WebKit, and is currently available in the Safari 167 Tech Preview. Firefox has expressed positive feedback on the feature, and a ticket to support it is available. Despite not every major browser supporting the attribute, it is a progressive enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., i.e. fully backward compatible: A browser that does not understand the attribute will ignore it, and its presence won’t cause any adverse effects.
Effectively, this enhancement is only about adding the fetchpriority=”high” attribute to the LCP image, which does not pose any risk of breaking backward compatibility.
Default behavior and customization
Similar to how WordPress core handles omitting the loading attribute on specific images, it should add the fetchpriority attribute by default on the LCP image based on server-side heuristics. While the exact heuristics are still being defined, it should be noted that the two attributes will never be used on the same image as they should be mutually exclusive.
Developers will be able to customize where the attribute should be used, e.g. when using the functions wp_get_attachment_image() and get_the_post_thumbnail(), both of which should receive support for the attribute. The default addition of the attribute to in-content images will also be customizable using a new filterFilterFilters 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., which will likely be similar to existing image attribute filters like wp_img_tag_add_loading_attr or wp_img_tag_add_width_and_height_attr.
Alternatives considered
Alternatively to fetchpriority=”high”, images can also be prioritized through other means, e.g. a link[rel=”preload”] tag in the head, or a Link response headerHeaderThe 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.. While those two approaches in principle allow the browser to know about loading the image even earlier, in practice there isn’t a notable difference, especially when using the tag, as at that point the entire HTML will already be loaded.
Either of the alternative approaches would furthermore require WordPress core knowing about the image in the page load lifecycle before it is even included in the output, which makes them more complex to implement in a way that is not justifiable given the little benefits it would bring over using fetchpriority=”high” on the actual image tag.
Contributing and testing this enhancement
An early version of the proposed enhancement can already be tested through the Performance Lab plugin, by enabling its Fetchpriority module, or alternatively through the Fetchpriority standalone plugin which uses the same underlying logic. It should be noted that the implementation is still being refined with additional heuristics to detect the LCP image, and since it is part of a pluginPluginA 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 rather than within WordPress core, the customization options outlined above cannot be part of this early implementation. It should furthermore be noted that the plugin implementation relies heavily on WordPress core’s lazy-loading heuristics, whereas the plan for the eventual core implementation would be to decouple the two.
A WordPress Core TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#58235 has been opened, and a pull request for WordPress core, including the aforementioned customization options will be worked on soon. Your testing and feedback is much appreciated. Please share your ideas, questions and thoughts either in a comment on this post, in the plugin’s support forum on wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, or on the GitHub repository.
As part of the WordPress 6.1 release, the Performance Team has added two Site Health checks (Persistent Object Cache and Page Cache). These checks were previously tested in the Performance Lab plugin. You can read more about them in the original proposal.
Both checks will run only in a production environment.
Persistent Object Cache
This new check determines whether the site uses a persistent object cache or not and recommends it if it makes sense for the site. It also links to a support resource created for the check.
A few filters have been included aiming for hosting providers to provide more specific steps regarding their environment.
Hosts may use the site_status_persistent_object_cache_urlfilterFilterFilters 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 replace the original WordPress guide with their own guide.
Hosts may use the site_status_persistent_object_cache_notes filter to customize the notes to recommend their preferred object cache solution.
/**
* Update the persistent object cache notes.
*/
add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
$notes = __( 'The updated notes can go here as text.', 'text-domain' );
return $notes;
} );
The site_status_persistent_object_cache_thresholds filter allows modifying the thresholds above WordPress considers using a persistent object cache beneficial.
/**
* Override the whole $thresholds array, or any specific indexes as required.
*/
add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
$thresholds = array(
'alloptions_count' => 600,
'alloptions_bytes' => 200000,
'comments_count' => 2000,
'options_count' => 2000,
'posts_count' => 2000,
'terms_count' => 2000,
'users_count' => 2000,
);
return $thresholds;
} );
Alternatively, site_status_should_suggest_persistent_object_cache is a short-circuit filter that allows using entirely custom logic to determine whether a persistent object cache would make sense for the site.
/**
* Opt in for suggesting the persistent object cache
*/
add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );
For additional context on this new check, see #56040.
Full Page Cache
This new check determines whether the site is using a full page cache solution and if the response time is acceptable.
It also adds a couple of filters aiming for hosting companies to customize the response threshold and add their own cache headers to be detected.
The site_status_good_response_time_threshold filter allows modifying the current threshold of 600ms. Everything below this will be considered acceptable.
/**
* Filter the response time threshold
*/
add_filter( 'site_status_good_response_time_threshold', function() {
return 200;
} );
Additional custom cache headers ( and optionally their verification callbacks) can be added through the site_status_page_cache_supported_cache_headers filter.
/**
* Filter the page cache supported cache headers
* $cache_headers contains List of client caching headers and their (optional) verification callbacks.
*/
add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers ) {
// Add new header to the existing list.
$cache_headers['cf-cache-status'] = static function ( $header_value ) {
return false !== strpos( strtolower( $header_value ), 'hit' );
};
return $cache_headers;
});
For additional context on this new check, see #56041.
This proposal seeks to integrate two new Site Health checks for Persistent Object Cache and Full Page Cache into WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., targeting the WordPress 6.1 release.
Context
Providing valuable recommendations for site owners is crucial to improving WordPress performance. These two modules are the first in a series of Site Health modules that the performance team is working on. Acknowledging performance problems is the first step to solving them.
The modules were originally proposed and developed by members of the performance team and are available as modules inside the Performance Lab plugin.
The recently released version 1.2.0 of the Performance Lab plugin contains both modules in a state that is ready to merge into core.
The team is currently migrating the module code into WordPress core patches in 2 TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets:
Persistent Object Cache Health Check from performance pluginPluginA 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 to core (#56040)
Port Audit Full Page Cache from performance plugin to core (#56041)
Any reviews and feedback on the core patches would be greatly appreciated.
Customizing the audits
We’ve added a series of filters to make messaging and suggestions customizable. These filters can be used by hosting providers to provide their own personalized suggestions on how to address the Site Health feedback.
Persistent Object Cache filters
Hosts may want to replace the notes to recommend their preferred object caching solution:
Hosts or site owners may want to bypass thresholds and force suggestions, or filterFilterFilters 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. them to determine whether to suggest the use of a persistent object cache:
You can test the modules in v1.2.0 or later of the Performance Lab plugin. Both modules should be enabled by default, but you can double-check that they are enabled in Settings > Performance:
Once enabled, you can view the test results on the Site Health Status screen at Tools > Site Health > Status.
We encourage you to test these modules (and others) from the Performance Lab Plugin, report any bugs in our GitHub repository, or contribute with fixes and ideas. You can also share any feedback, concerns, or questions to improve these features further in the comments.
The first stable version 1.0.0 of the Performance Lab pluginPluginA 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 has been released. You can download it from the WordPress plugin repository or via GitHub.
The stable release means that the Performance Lab plugin’s infrastructure is now out of betaBetaA 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. testing stage. The plugin’s primary purpose remains to facilitate beta testing for future WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. performance features and enhancements, as outlined in the original plugin announcement post. The initial beta phase for the plugin was primarily to allow the performance team to discover early infrastructure bugs and fix them before the stable launch.
Included modules
The following modules are included in the 1.0.0 release:
WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
Audit Autoloaded Options (experimental): Adds a check for autoloaded options in Site Health status. View related GitHub issues
Audit Enqueued Assets (experimental): Adds a CSSCSSCascading Style Sheets. and JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues
Next steps
The performance team is going to continue enhancing the existing modules and evaluating additional modules to add in the future. The cadence and versioning strategy for upcoming releases is currently up for discussion. Please provide your feedback on plugin versioning in this issue if you are interested. There is an ongoing vote in that issue which is open until 2022-05-02 17:00 UTC.
Kudos to all the people that have contributed to and tested the Performance Lab plugin so far and made this first stable release possible! Let’s keep testing and iterating on the individual features to bring each of them closer to an eventual WordPress core merge.
Introducing the Performance Lab pluginPluginA 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: After the WordPress performance team began work on it in November 2021, the first version of the plugin is finally here and ready for testing. You can download it or install it directly from your WordPress dashboard. Your testing and feedback will allow iterating towards adding future performance optimizations in WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
What is the Performance Lab plugin?
The Performance Lab plugin is a set of modules that aim to improve performance in WordPress. While this may sound similar to the numerous other performance plugins in the WordPress ecosystem, the Performance Lab plugin exists for an entirely different purpose: It is a collection of performance-related “feature projects” for WordPress core.
Feature projects are intended to gather a group of people to explore potential ideas for WordPress core.
Historically, feature projects have usually been implemented as separate feature plugins. The Performance Lab plugin provides a centralized location for performance-related features which are intended to eventually be merged into WordPress core. Therefore, it should be considered a betaBetaA 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.-testing plugin. The plugin’s performance modules can be individually enabled in the plugin’s settings screen, so that they can be tested in isolation or in combination. Being able to activate/deactivate modules is similar to activating individual plugins, but the Performance Lab approach comes with benefits: For both developers and end users, it removes the burden of keeping track of several plugins. For developers, it additionally reduces maintenance and encourages collaboration between developers.
Another benefit of the single plugin approach taken with the Performance Lab plugin is that it provides room for experimentation. Some modules included in the plugin are explicitly marked as experimental, and while the entire plugin is for testing WordPress performance features, those modules are at a particularly early stage of exploration and therefore could lead to unexpected results This also leads to the clarification that all performance modules bundled in the Performance Lab plugin are at different stages of development. For example, some may already be official WordPress core feature projects, others may be proposed as feature projects in the near future. Some experimental modules may remain in exploration for a few months to come.
Because the Performance Lab plugin is a collection of potential WordPress core feature modules, the list of modules included may drastically change over time. New modules may be added regularly, while other modules may be removed in a future plugin version once they have landed in a WordPress core release. Also keep in mind that the Performance Lab plugin is not a full replacement for other WordPress performance plugins you may be using already.
Who develops the Performance Lab plugin?
The Performance Lab plugin is being actively worked on by the WordPress performance team, which was formed in late October 2021. The plugin is the primary project of the team where new performance features are being explored and implemented. It complements the direct contributions to WordPress core, which happen for smaller fixes or for features that already have seen significant testing in the plugin.
The modules included in the plugin are based on the priorities of the performance team contributors who meet weekly in the #performance Slack channel to discuss the ongoing efforts and priorities. The performance team takes into account the impact of different features while prioritizing work, and the modules included are also influenced by contributor interest. So far, over 250 people have joined the performance SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, with many of them participating in the weekly chats and reporting issues on GitHub. While code contributions to the plugin so far have been limited to just slightly more than 10 contributors, the performance team is confident that the volume of code contributions will increase over time, especially as the plugin starts seeing increased usage.
Which features come with this initial Performance Lab plugin version?
This initial release of the Performance Lab plugin (1.0.0-beta.1) comes with the following modules:
WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
Audit Enqueued Assets (experimental): Adds a CSSCSSCascading Style Sheets. and JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues
To test the WebP Uploads module, upload some JPEG images to the Media Library, and the module should ensure that the sub-sized versions are also generated in WebP and then used in the front-end when embedding such uploaded images in a post.
To test the other three modules, visit the Site Health status tab, where each module adds a corresponding new check:
The Audit Enqueued Assets module monitors the amount of scripts and stylesheets enqueued on your homepage.
The WebP support module checks whether your server environment supports creating WebP images.
The Persistent Object Cache Health Check promotes usage of an external object cache depending on the amount of data on your site.
Remember that each module you would like to test has to be activated via the plugin’s settings screen at Settings > Performance. Non-experimental modules are enabled by default. If you want to test the modules individually in isolation, you can toggle them one by one.
To learn more about the modules, you can use the GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ labels to follow along their development via the links from the list above. You can also review the full release changelog.
How can I support the Performance Lab plugin?
Since the Performance Lab plugin is a beta testing plugin, the most straightforward way of contributing is to use it! Test the individual modules, try to break them, explore edge-cases etc. Any feedback or bugbugA 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. reports are welcome as GitHub issues or alternatively as wordpress.org support forum requests. If you have found a bug and already discovered a fix for it, you can submit a pull request. You’re also invited to share your feedback in a review. Last but not least, share the news! Only with a solid number of regular testers can the features in this plugin mature over time.
If you would like to participate in developing or shaping the direction of the plugin, the performance team would be pleased to have you join the weekly chats in the #performance Slack channel! The next one will take place at March 8, 2022, at 16:00 UTC.
Another area to contribute to the plugin is localization. If you speak a language other than English, help make the Performance Lab plugin available in your localeLocaleA locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. by contributing translations.
Many thanks to all the community volunteers that have contributed to the Performance Lab plugin and the overall efforts of the performance team so far! This beta release is a major milestone and just the beginning – let’s continue from here.
You must be logged in to post a comment.