Ari Stathopoulos 6:35 pm on October 12, 2021
Tags: , ,   

Proposal for a Performance team

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.

References:

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) coreCore Core 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.

Performance graph for CMSs on desktop clients.
Performance graph for CMSs on mobile clients.

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 pluginPlugin A 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 UXUX User 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.

Plugin territory

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.

Why a team?

Performance is already a focus in Trac and a label in the Gutenberg GitHub repository; but these alone don’t attract enough attention to the issues, nor unify efforts and priorities. Experienced and active contributors are not necessarily performance experts.

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 tagtag A 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
  • A performance channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
  • A meeting every two weeks; time to be determined
  • 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

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.org The 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

Props

Thanks to the following for this involvement in outlining this proposal.

@francina, @adamsilverstein, @tweetythierry, @joostdevalk, @jonoaldersonwp, @flixos90, @aristath (in no particular order)

#performance, #proposal, #team