Indianwebs echoes the news from the WordPress team responsible for coordinating efforts to increase WordPress performance.

It is based on a proposal that could work and has been developed by Yoast and Google.

What problems is WordPress having with speed?

Users prefer fast websites with good performance. Research shows that fast websites can provide a better user experience, increase engagement, benefit SEO, increase conversion, and be more economical and environmentally friendly.

The investment in a Web maintenance improves WordPress benefits and performance, further increases user expectations and, therefore, Google can penalize slower or unmaintained websites.

Compared to other platforms (e.g. Wix, Shopify, Squarespace), WordPress is lagging behind. Other platforms are increasingly faster than WordPress websites (see HTTP Archive's Core Web Vitals report ) and are actively investing in performance principal as a function.

We can see the impact of this investment in the widening gap between the proportion of WordPress sites achieving “good” Core Web Vitals scores, versus other platforms.

This gap continues to increase, despite the availability of many speed-enhancing plugins and optimized themes. This suggests that there is a discovery and/or education problem, or an upgrade/obsolescence problem, neither of which the ecosystem of accessories .

To meet the growing needs and expectations of site owners and end users, WordPress must actively invest in performance in WordPress Core and beyond (e.g. core code, theme and plugin requirements, setup and onboarding processes, user experiences). administration / editing, education for content creators).

We believe that:

• Performance is a critical part of user experience and WordPress should aim to deliver a good user experience.
• Achieving reasonable levels of performance should not be the territory of add-ons, but part of the core (aka “default performance”), because;
  • All WordPress users need a well-lit path to good performance.
  • End users cannot be expected to be performance experts.
  • Achieving high levels of performance requires that technical considerations be “built in” throughout the stack; and as this is not usually the case with themes/plugins, performance fixes are limited to "brute force" performance fixes on non-performance behavior (e.g. output buffering).
  • The plugin ecosystem doesn't help users who don't know they need help or are poorly served by the plugin ecosystem.
• Users determining which CMS to choose are/will be increasingly influenced by performance (and conversion factors/ UX / SEO / conversion associated), and we will lose ground to faster platforms.
• 'Democratizing publishing' requires that published content be discoverable; which will be less likely to occur through search engines (which influence or explain most new content discovery) for slower sites.

Core Web Vitals metrics provide a standardized and accepted mechanism for evaluating performance.

Complement Territory

While we argue that some of the performance considerations should be part of the core, there are definitely areas that should remain firmly in 'plugin territory'. For example, the following areas should be handled by plugins:

• Specific CDN Integrations
• Template transformation processes (e.g. AMP)
• Any non-standardized performance technology
• Any experimental standards (e.g. API/browser capabilities with limited adoption)

These distinctions must be explored and the lines must be drawn and maintained as part of the team's activity.

Why a team specialized in WordPress?

Website performance alone is not an issue that attracts enough attention, nor does it unify efforts and priorities since active and experienced contributors are not necessarily development experts.

A team gives more visibility to the effort: contributors who aren't interested in working on Core as a whole may be drawn to working specifically on improving web speed. It also opens up new types of contributors, such as performance or data analysts, to contribute.

Contributions from different groups could also join this team; browsers, hosting, SEO companies, etc.

Resources and efforts

Simply put, creating a team requires the following:

• Una label of performance in Create sites websites
• A performance channel in Slack
• A meeting every two weeks; time to be determined
• Two team representatives for administrative purposes: will be responsible for:
  • Provide a quarterly report to project leadership.
  • Assign roles on the website
• A team leader/product owner. They will be responsible for creating a mission statement for the team, highlighting areas to address, outlining the scope and roadmap for improvements that need to be made.
• Representation in (and influence over) other Make processes and verticals (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 event that there are no objections, the next important steps are likely to be:

• Set the channel Slack and the meeting calendar, and do. infrastructure wordpress.org .
• Evaluate performance and define ongoing/future measurement and success criteria
• Identify priority projects for CWV improvements with high-level timelines
• Assign responsibilities for identified projects

Source: Make WordPress