Yoast and Google-sponsored WordPress core contributors are proposing the project add a Performance team to improve core performance as measured by Google’s Web Vitals metrics.

“Users expect and prefer fast experiences (consciously or otherwise),” Yoast-sponsored full-time core contributor Ari Stathopoulos said. “Research shows that fast websites can provide a better user experience, increase engagement, benefit SEO, increase conversion, and be more economically and ecologically friendly.”

There is no doubt that users expect and can benefit from improved performance, but there are a number of variables at play in any given WordPress site. Looking purely at core performance, Stathopoulos said WordPress is not holding up to the competition.

“Compared to other platforms (e.g., Wix, Shopify, Squarespace), WordPress is falling behind,” he said. “Other platforms are on average faster – and becoming increasingly faster – than WordPress websites (see The HTTP Archive’s Core Web Vitals report), and are actively investing in (and marketing) core performance-as-a-feature [1, 2].”

The HTTP Archive, which provides a common data set for those conducting web performance research, found that only 21.5% of sites assessed have good Core Web Vitals scores as of September 2021. While that percentage has been increasing over time, competitors that are already outperforming WordPress sites are also rapidly improving their scores. Stathopoulos described it as a “widening gap” between WordPress and other platforms.

One of the main challenges is that WordPress site owners have a lot of freedom to use whatever themes and plugins they want on their sites, which makes performance tougher to tackle than the hosted platforms cited for comparison. The proposal states that “achieving reasonable performance levels shouldn’t be plugin territory, but part of core” and that end-users should not be expected to become performance experts.

“Achieving high levels of performance requires technical considerations to be ‘built-in’ across the whole stack; and as this is often not the case with themes/plugins, performance solutions are limited to ‘brute-forcing’ performance solutions over non-performant behavior (e.g., output buffering),” Stathopoulos said.

The proposal drew a strong response from contributors, SEO consultants, and representatives from hosting companies, offering help and suggestions.

WordPress lead developer Mark Jaquith, who has a particular interest in this topic, said the biggest issues he sees today are related to frontend performance and the asset pipeline:

WordPress has no (direct) support for deferring style loading. It has no system for critical theme styles. For JavaScript, it has no support for defer, async, type="module", or nomodule. The default is to load all scripts in the header. WordPress itself shoves its extra code for emoji and the block library into the header. WordPress injects JS code and styles that eschew the asset pipeline altogether and directly attach to wp_head and wp_footer. Plugins just directly barf out bespoke script tags that are difficult to alter. By the time that you’ve added 10 plugins to your site, your odds of having jQuery loaded (in the header) on every single page load are extremely high. No one is incentivized to be a good citizen (including WordPress itself) because there’s always someone else who is polluting worse than you. “If jQuery is already enqueued by something else, I guess I better use it.”

Jaquith’s summary describes a wider ecosystem problem and concluded with a sobering warning.

“It’s a huge problem, and fixing it is going to take a lot of effort, willpower and time,” he said. “It’s worth doing. If WordPress frontend performance continues to decline, the project is going to cease to be a viable option for any site that cares about its SERPS.”

One WordPress performance consultant, Eroan Boyer, suggested adding a dedicated tool in the Site Health screen that would show how much JS and CSS is loaded on each page type (front page, post, page, CPT), and where they originated.

“Attributing where a given script or stylesheet comes from is something I’ve been working a lot on in the context of the AMP plugin,” Google Engineer Weston Ruter. “I don’t know if the implementation in the AMP plugin would be suitable for core, but I’m interested in this space.

“If we can correlate where given markup comes from to the (negative) impact on page performance, then we can begin to highlight offending themes and plugins to begin to provide some accountability for what is being added to the frontend.”

Gutenberg engineer Riad Benguella published some research in August on the impact of plugins’ performance on the editor. Chief offenders among popular plugins included WooCommerce, Yoast SEO, and Jetpack. This is another aspect of performance that affects WordPress users more than site visitors. Web developer Takis Bouyouris suggested the creation of a performance framework that plugin developers could follow to avoid making products that negatively impact core performance, both on the frontend and in the admin.

So far the proposal has not received any major objections and contributors seem eager to help in any way they can. Stathopoulos said the next steps will be to set up a Slack channel, a meeting schedule, and a space on make.wordpress.org. Once the infrastructure is in place, contributors can begin benchmarking performance, defining success criteria, and identifying priority projects for Core Web Vitals improvements.