A WordPress proposal admits it is falling behind Wix and similar platforms and suggests they need to create a performance team to coordinate speed improvements.
While some may find it controversial for someone at WordPress to admit they were falling behind in the race to improve speed scores, it’s a fact that platforms that manage the technical side of publishing are pulling ahead of WordPress in terms of speed.
Objective speed metrics from Chrome users, reported in Google’s monthly CrUX (Chrome User Experience Report) unquestionably shows that WordPress is slowly being left behind by platforms that are better able to control software development so that it conforms to best practices for speed.
Because the WordPress platform is relatively decentralized compared to platforms like Wix and Squarespace they are less able to influence best practices for speed performance across the entire WordPress ecosystem.
WordPress Admits Falling Behind Wix, Shopify and Squarespace
The proposal was blunt in its assessment that WordPress was falling behind:
“Compared to other platforms (e.g., Wix, Shopify, Squarespace), WordPress is falling behind.
Other platforms are on average faster – and becoming increasingly faster – than WordPress websites…”
That’s not an opinion, it’s a statement of fact that WordPress is falling behind Wix.
The Core Web Vitals Scores revealed from the Chrome User Experience Report show that it is a fact that WordPress is gradually falling behind Wix in terms of Core Web Vitals.
This proposal aims to take action to change that situation.
Being open-minded to the possibility that things need to improve is a positive sign because the first step to becoming the best often involves identifying areas of improvement.
The proposal is being spearheaded by WordPress developers from Google and Yoast.
WordPress Needs a Performance Team
The proposal states that it needs an official team to coordinate the performance side of WordPress core development.
So instead of performance being almost an afterthought to improvements to other areas of WordPress, speed performance can move to the front because of advocates who can now help coordinate improvements.
The proposal states:
“We believe that WordPress needs an official Performance Team responsible for coordinating efforts to increase the performance (speed) of WordPress.”
Why WordPress Needs a Performance Team
The next section of the proposal outlines why they feel a Performance Team is necessary.
The statement references user experience, user expectations, SEO and also economic and ecological benefits.
That last part is a reference to the little known fact that websites that are difficult to render are said to be “expensive.”
That means that devices need to expend more resources to build web pages that are complex and have multiple resources necessary for rendering the web page.
This in turn impacts energy consumption of the mobile device downloading the web page.
The impact is not only to the battery but also influences how much energy society needs to generate to keep on downloading inefficiently coded websites.
The proposal notes:
“Users expect and prefer fast experiences (consciously or otherwise). Research shows that fast websites can provide a better user experience, increase engagement, benefit SEO, increase conversion, and be more economically and ecologically friendly.”
WordPress Speed Should Not be the Job of a Plugin
The proposal says that the job of optimizing WordPress should not fall to third party plugins and that it should not be the burden of those who use WordPress to fix it and make it better.
It states:
“Average end-users can’t be expected to be performance experts.”
This is something that I suggested in February 2021 in the article:
Core Web Vitals Not Really Your Problem?
Google is burdening the USERS of software like WordPress and not the developers to fix it for Core Web Vitals. Is that fair?
Software publishers have created plugins to help WordPress cache files in order to serve the faster, plugins that shrink CSS files and some plugins that remove JavaScript so that it is only downloaded when it is needed.
WordPress is proposing that this job of optimizing WordPress should be performed natively by WordPress itself instead of relying on third party plugins.
The proposal introduces the concept of “performance by default” as a way to internalize a focus on speed throughout the development ecosystem.
“Achieving reasonable performance levels shouldn’t be plugin territory, but part of core (aka, “performance by default”)
Highlights of the proposal:
- Average end-users can’t be expected to be performance experts.
- Achieving high levels of performance requires technical considerations to be ‘built-in’ across the whole stack;
- The plugin ecosystem doesn’t help users who don’t know that they need help, or who are poorly served by the plugin ecosystem.
- Users determining which CMS to choose are / will be increasingly influenced by performance (and the associated UX/SEO/conversion factors), and we’ll lose ground to faster platforms.
- Democratizing publishing’ requires that published content be discoverable; which will be less likely to occur via search engines (which influence or account for the majority of new content discovery) for slow(er) sites”
WordPress Proposes Reconsidering Role of Plugins for Optimization
The proposal also suggests a reconsideration of dependence on third party plugins for optimization issues while also stating that there are some areas where plugins are better suited.
The WordPress proposal offered examples of where plugins were the preferred solution:
- “Integrations with specific CDNs
- Template transformation processes (e.g., AMP)
- Any non-standardized performance technology
- Any experimental standards (e.g., browser APIs / capabilities with limited adoption)
These distinctions will need exploring and lines will need drawing (and maintaining) as part of the team’s activity.”
How WordPress Performance Team May Proceed
If the proposal is accepted the proposal suggests steps to get the project organized:
- “Set up Slack channel and meeting schedule, and make.wordpress.org infrastructure.
- Benchmark performance and define ongoing/future measurement & success criteria
- Identify priority projects for CWV improvements with high-level timelines
- Assign responsibilities for the projects identified”
Response to the Proposal by the WordPress Community
Joost de Valk, founder of Yoast SEO Plugin underlined that this is a proposal and not a done-deal.
“This isn’t saying “we’re going to do this, just so you know”, it is: “we want to do this, will you join us?””
The response to the proposal was overwhelmingly positive.
Typical responses:
“This is a great initiative. It might finally get the attention it deserves.
I am deeply excited by this proposal! Looking forward to the discussion here and being able to pitch in as things…
Excellent proposal! In the past year(s) WordPress has been making a lot of steps to tackle some front-end performance problems: lazy loading, WebP support, Gutenberg (yes, I will put this here). But overall there is much more potential and opportunities here. Sign me up”
A non-developer member of the WordPress community noted all the plugins they currently used and expressed how it would be an improvement to not have to rely on so many third party plugins:
“As someone who is not a developer but uses an array of plugins (Autoptimize, ASYNC CriticalCSS, Page Speed Booster, CAOS, OMFG, and ShortPixel – all in combination with WP Engine hosting and Cloudflare CDN, as well as now native Lazy Load feature of WordPress) to optimize my sites and those of my clients, I would like not to have to depend on this suite of tools all the time to increase performance.”
WordPress Performance Team is a Great Idea
The formation of a WordPress Performance Team is not just a good idea, it’s a great idea.
It’s arguable that WordPress should have had a performance team since day one. Nevertheless it’s super exciting to see this initiative given a breath of life.
Citation
Read the WordPress Proposal
Proposal for a Performance Team
