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.
Note: a follow up post was published with information about next steps for this proposal.
We (the undersigned) believe that WordPress needs an official Performance team responsible for coordinating efforts to increase the performance (speed) of WordPress.
This proposal outlines why we believe that this is necessary, how we envision such a team might function, and some potential initial areas of focus. It is authored by contributors from Yoast and Google.
What problems are we trying to solve?
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.
The benefits of improving performance driving investment across the web [ref]. This further raises users’ expectations, and thus may comparatively ‘harm’ slow(er) things.
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 (see The HTTP Archive’s Core Web Vitals report), and are actively investing in (and marketing) coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. performance-as-a-feature [1, 2].
We can see the impact of this investment in the widening gap between the proportion of WordPress sites which achieve ‘good’ Core Web Vitals scores, vs other platforms.
This gap continues to widen, despite the availability of many performance plugins and performance-focused themes. This suggests that there’s a discovery and/or education problem, or an updating/staleness problem – neither of which 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 ecosystem solves for.
In order to meet the increasing needs and expectations of site owners and end-users, WordPress needs to be actively investing in performance in WordPress Core and beyond (e.g., core code, themes & plugins requirements, setup and onboarding processes, adminadmin(and super admin)/editing experiences, education for content creators).
We believe that:
Performance is a fundamental part of user experience, and WordPress should aim to deliver a good user experience.
Achieving reasonable performance levels shouldn’t be plugin territory, but part of core (aka, “performance by default”), because;
All WordPress users (of all types) need a well lit path to good performance.
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; and as this is often not the case with themes/plugins, performance solutions are limited to ‘brute-forcing’ performance solutions over non-performant behaviour (e.g., output buffering).
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 UXUXUser experience/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.
Web Vitals metrics provide a standardized and accepted mechanism for evaluating performance.
Whilst we argue that some (perhaps most) performance considerations should be part of core, there are definitely areas that should remain firmly in ‘plugin territory’. For example, the following areas should be handled by plugins:
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.
A team gives more visibility to the effort: contributors that are not interested in working on Core as a whole can be attracted by working on performance specifically. It also opens up contributing to new types of contributors, like performance or data analysts.
A performance team could also attract contributions from different groups; browsers, hosting, SEO companies, etc.
Resources and efforts
In practical terms, the creation of a performance team requires the following:
A performance 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.) on Make websites
Two team representatives for administrative purposes: they will be responsible for:
Giving a quarterly report to the project leadership
Assigning roles in the website
A team lead/product owner. They will be responsible to create a mission statement for the team, highlight the areas to tackle, outline the scope and the roadmap for the improvements that need to be made.
Representation in (and influence on) other Make verticals and processes (e.g., themes, plugins, etc)
Next steps should be discussed and determined as part of the process of exploring and responding to this proposal.
In the case that there are no objections, the next major steps are likely to be:
Set up Slack channel and meeting schedule, and make.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/ 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
Thanks to the following for this involvement in outlining this proposal.
You must be logged in to post a comment.