Yoast and Google-Sponsored Core Contributors Propose New WordPress Performance Team

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 [12].”

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 deferasynctype="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 said. “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.

15

15 responses to “Yoast and Google-Sponsored Core Contributors Propose New WordPress Performance Team”

  1. Speed is one metric and a good thing, but it shouldn’t come at a cost of creativity and uniformity. Specially don’t force AMP on us… given „Google sponsored core contributors“.

    Report

    • This was specifically called out in the proposal:

      For example, the following areas should be handled by plugins: […] Template transformation processes (e.g., AMP)

      Report

    • Haha. I was thinking the same thing. Sooo funny. But hey, good that they at least want to make wordpress faster. You could just write as first recommendation: Please do not install YOAST. YOAST makes your website slow.

      Report

  2. Sounds good to me. Performance is too important to not be a priority. While plugins and themes can do a lot to help, the core CMS needs to help make it easier.

    Report

  3. By the time anything happens, WordPress will be a Google product.

    Having said that, it is a shame WordPress core contributors have not been focusing on this issue long before now.

    Guess it’s Gutenberg and/or bust.

    Report

  4. Funny that Google has weighed in on this. I wonder if they’ll be willing to make their GA and other external scripts faster and require fewer round trips. It’d also be nice if they engineer a way to make it possible to host their scripts locally AND still get updates when available.

    Report

  5. Yoast could start making things faster by making Yoast SEO lighter and not the bloated plugin that it is. Lead by example.

    Report

  6. It would be great if plugins that force jQuery to be loaded in the head got ‘named and shamed’.

    This year I had a lot of conversation with the Gravity Forms creators, on a specific site we created that plugin was the only one that was using jQuery in the head. In the end they solved the problems, so I’m very happy with their support.

    In my opinion every plugin/theme should be fully functioning with jQuery in the footer (or better: just use vanilla JavaScript).

    Report

  7. In my opinion every plugin/theme should be fully functioning with jQuery in the footer

    jQuery in footer is loaded after rendering of page, which will break all sort of active content like sliders etc. or cause jumps of content if sliders are initialized and added after page has been displayed already in browser.

    Report

  8. How is this even an article?

    The cause is just but the stats are well off. Comparing a WordPress/WooCommerce average to a Shopify average? That is never, ever going to be accurate.

    The issue is not with Core, but with all the folks building shitty themes and plugins that offer nothing new other than a source of revenue to the creator and all the terrible bloggers copying and pasting a “How to do X with WordPress” article for SEO, when that article was bad practice 5 years ago when it was originally written, worse, these articles are given a link outreach budget which means they dominate the serps and become ‘canon’.

    WordPress is a community, not a product. To fix this issue we need to fix the community.

    Report

    • WordPress is actually a product. It is marketed as free, which is used to generate income for the rest of the empire.

      The community is just fine. Well, most of us. Some don’t look upon others as positively as they could, but that is the nature of a community.

      Core has had issues for many years. Even those who work on it admit there are significant improvements which could be made. It’s getting everyone to agree which direction needs to be taken that gets in the way sometimes.

      While there are some bad apples in the plugin/theme development, there are a whole lot of good products out there. Some in WordPress repositories and some in outside shops.

      As far as “horrible bloggers” copying and pasting, I have to agree, there are a lot of rehashings going on, but I’m not seeing where even this comment is providing much originality. We all take from someone else to get what we need out of what we are doing. Even the most arrogant do it. They just don’t admit it.

      Report

  9. Make your Yoast plugin faster too. I feel good to know that top tech companies Google and Yoast came together to improve the WordPress speed issue. That’s great !!!

    Report

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: