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 web 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.
Investing 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 (eg Wix, Shopify, Squarespace), WordPress is lagging behind. Other platforms are getting faster than WordPress websites (see the HTTP Archive 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 that achieve "good" scores from Core Web Vitals, versus other platforms.
This gap continues to grow, despite the availability of many speed-enhancing plugins and optimized themes. This suggests that there is a discovery and / or education issue, or an upgrade / obsolescence issue, neither of which solves the ecosystem of accessories .
To meet the growing needs and expectations of site owners and end users, WordPress must actively invest in performance across WordPress Core and beyond (e.g. core code, theme and plugin requirements, setup and onboarding processes, experiences of administration / editing, content creator education).
We believe that:
- Performance is a critical part of the user experience and WordPress should aim to deliver a good user experience.
- Achieving reasonable levels of performance should not be plugin territory, but part of the core (also known as "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 technical considerations to be "built in" across the stack; And since this is rarely the case with themes / plugins, performance solutions are limited to "brute force" performance solutions on non-performance behavior (eg output buffering).
- The plugin ecosystem does not 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 / associated conversion), and we will lose ground to faster platforms.
- 'Democratizing publication' requires that published content be recognizable; that will be less likely to happen through search engines (which influence or explain most of the new content discovery) for slower sites.
Core Web Vitals metrics provide a standardized and accepted mechanism for evaluating performance.
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 (eg, AMP)
- Any non-standard performance technology
- Any experimental standard (eg API / browser capabilities with limited adoption)
These distinctions should be explored and the lines should be drawn and maintained as part of the team's activity.
Why a team specialized in WordPress?
The performance of a website 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: collaborators who are not interested in working on Core as a whole may be attracted by working specifically on improving web speed. It also opens up to contribute to new types of contributors, such as performance or data analysts.
This team could also be joined by contributions from different groups; browsers, hosting, SEO companies, etc.
Resources and efforts
Simply put, building a team requires the following:
- A label of performance in Create Websites
- A performance channel in Slack
- One meeting every two weeks; time to be determined
- Two team representatives for administrative purposes: they will be responsible for:
- Give a quarterly report to the 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 be addressed, outlining the scope and roadmap for improvements that need to be made.
- Representation in (and influence on) other Make verticals and processes (e.g. themes, plugins, etc.)
The 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 up the Slack channel and meeting calendar, and go. infrastructure of wordpress.org .
- Evaluate performance and define continuous / future success and measurement criteria
- Identify priority projects for CWV improvements with high-level timelines
- Assign responsibilities for identified projects
Source: Make WordPress