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 our bug tracker.
Updates about focus groups POCs (point of contacts)
@aristath and @gziolo are the POCs for the JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. focus group, with the support of @sergiomdgomes.
@adamsilverstein and @audrasjb are the POCs for respectively the Images and Site Health focus groups.
Logistics, operations and projects prioritization for the focus groups
@flixos90 raised that we need to figure out the project priorities for each focus group. This document template has been prepared with some pointers on items to think about when writing down the focus group priorities. It also considers the others aspects of the projects as the technical complexity, the impact, the potential blockers, the timeline, etc.
Using a document makes asynchronous communications easier, and ad-hoc conversations can take place in the #performance channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. The POC of each focus group can now create a copy of the template and share it in the channel to allow other contributors to collaborate.
Defining the logistics for each group (tracking, POCs etc.)
Focus group projects and prioritization
Next steps for the team and the focus groups
Open Floor
Defining the logistics for each group (tracking, POCs etc.)
In order for the focus groups to function properly, we need to define how they will operate. Some ideas have already been put forward and will be shared at the meeting. Please feel free to come and share yours as well.
Focus group projects and prioritization
For each of the focus groups, there are several projects on the table. It is therefore necessary to think about the roadmaps and prioritize the projects on which efforts will be concentrated.
Team-related posts on Make/CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. will be tagged #performance and #performance-chat for agendas and meeting summaries
This spreadsheet highlights the focus areas on which this team will work.
Defining focus areas and working groups
Since the initial post on the proposal to create the team, there have been additional ideas on what it should work on. We need a bit of prioritization. Of course all performance work is important, and all contributions are welcome, as always.
To have a guideline for the next steps, the attendees decided to choose in the spreadsheet mentioned above from the aspects that have the highest number of interested contributors. These topics will be organized in working groups, that will be discussed during the weekly meetings.
Here are the working groups:
Images: Serving images in good quality but as small as possible
JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.: Optimizing JavaScript orchestration
Site Health: Providing the user with data to understand performance
Measurement: Compiling data and analysis, and reporting on performance
To make sure we are making steady progress, we asked for at least one volunteer per working group to commit to attending weekly meetings to give updates on what is being done, and possibly how other contributors could help. Here’s the thread on Slack where you can express your interest in doing so.
Next steps for this team
The next steps for the team and the working groups are the following:
Define the logistics for each group (tracking, POCs etc.)
Kickoff meeting for each 4 area
If you are interested in exploring or helping with one of these, please feel free to add their .org username in the Focus Area speadsheet.
Open Floor
Several ideas were brought up during the meeting, about the organization of the team, potential tools or ideas for exploration. Here are some of them:
About tooling/documentation/information about performance and monitoring
About some work that is already being done for performance
@audrasjb is doing some work for the Site Health focus. Audras is working on a feature plugin on Benchmarks in Site Health, number of CSSCSSCascading Style Sheets./JSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. assets loaded.
Two weeks ago, Google and Yoast WordPress contributors posted a proposal to create a Performance team responsible for coordinating efforts to increase the performance (speed) of WordPress. The proposal was very well received overall, and many other contributors showed interest in joining the effort (thanks everyone).
coordinate the initial administrative tasks (slackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, weekly meetings, schedule working groups representative nominations, etc.)
create a mission statement for the team
coordinate the areas to tackle
outline the scope and the roadmap
If you have interest in contributing to any of the above, please join the kickoff meeting, if you can, or use the comments of this post to do so.
Everybody is welcome to join working groups and contribute to performance enhancements without specific nomination 🙂
Kickoff meeting
Given the large interest from many contributors, it sounds like getting together is the first step.
By looking at the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Meetings calendar, Tuesdays at 3PM UTC seem good candidates. @justinahinon has offered to run chats ad interim, the kick-off meeting will happen on Tuesday, November 2nd 2021 at 3PM UTC in the #performance Slack channel.
Agenda
Welcome
Contributor interest open floor
Defining areas of focus
Defining focus areas and working groups
As we have seen from the initial post comments, there are no shortage of areas in need of performance enhancements in WordPress (which is a good problem to have in a way). With that in mind, we will initially aim to keep the scope limited by defining the most impactful area of focus and create working groups if need be. Defined focus areas will be the main points of discussion during weekly chats.
An agenda item for the first meetings will be to define the initial focus areas for the team. Every contributor will be asked to self-assign themselves to one or two areas, to indicate what they would like to work on. The performance projects are assembled in a spreadsheet which can already be reviewed ahead of the kickoff meeting.
This is not exclusive of any performance contributions.
Props
Thanks to the following for their involvement in authoring, proofreading and providing feedback on this post.
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.
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 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.
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.
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
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
Props
Thanks to the following for this involvement in outlining this proposal.
As a follow-up to the very active discussion around the proposal to drop support for IE11, there is a majority agreement to move forward with dropping support. The next steps are to figure out a timeline and what it means for projects/teams to drop the support.
Regarding timeline, there are two upcoming milestones where support could be dropped: 5.8 and 5.9. The argument for dropping in 5.8 is to realize the change and improvement quicker, while others are inclined to wait until 5.9 to provide a longer window between the official announcement and the effective date.
In case you missed the first post on post/page performance, I’d recommend checking it out first before digging into this post, as it helps give greater context into the breadth of work around performance improvements. This post builds on the discussion by talking specifically about the approach Core ContributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. take to managing the performance of the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor itself!
Think of Core Editor Performance as impacting the user experience when creating content. It’s the difference between a jarring experience, with the editor barely keeping up as you type, and a creative one — where adding dynamic content is a breeze with performance hardly being noticeable.
With each release of GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, a performance benchmark is run against the last few releases that compares different response times for a large post (~36,000 words, ~1,000 blocks). You can find this benchmark at the bottom of each “What’s New in Gutenberg” post. While this approach doesn’t cover every scenario, and absolute numbers are not intrinsically meaningful, it has helped identify variations in performance for different releases. Generally speaking, while the loading time of the editor is important, pay special attention to typing speed (also known as KeyPress Event speed). This is a far more important measure when it comes to user experience as this is what allows for the smooth experience when working in the editor.
Beyond an overview of neat numbers, what does focusing on Core Editor Performance entail? Pulling from the documentation, the following overall metrics are tracked:
Loading Time: The time it takes to load an editor page.
Typing Time: The time it takes for the browser to respond while typing on the editor.
BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Selection Time: The time it takes for the browser to respond after a user selects a block. (Inserting a block is also equivalent to selecting a block. Monitoring the selection is sufficient to cover both metrics).
After digging into data and reviewing previous decisions around browser support, this is a proposal to define a policy to stop supporting Internet Explorer 11 (IE11) now that usage has cumulatively fallen below ~1% across three metrics.
Current state of IE11
As of February 25th 2021, IE11 usage has cumulatively fallen below ~1% according to three sources of metrics:
0.46% from WordPress.comWordPress.comAn online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.
For comparison, the numbers above are very close to the data used to make a decision in 2017 to drop support for IE versions 8, 9, and 10. It’s important to keep in mind that when viewing these statistics in the context of WordPress, these percentages represent tens (if not hundreds) of thousands of users that could potentially be left behind if support for IE11 is dropped.
The proposed policy for WordPress is to end Internet Explorer 11 support. This was discussed most recently in the February 24th Core Editor Chat and briefly during February 23rd JavaScript office hours in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. More context and discussion have been shared over time in this original Trac issue that seeks to determine clear guidelines around what absolutely can’t be broken in order to help identify development and testing needs.
Benefits
Dropping support would result in smaller scripts, lower maintenance burden, and decrease build times. For instance, a recent exploration by @youknowriad demonstrated that not transpiling the scripts to IE11 immediately resulted in a net reduction of nearly 84kB in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. built files, representing a 7,78% total decrease in size; these scripts have seen a size contraction up to 60%, with an average reduction of 24%. This is a result of heavily relying on transpilers, further explained by Jason Miller, Web DevRel at Google. Moreover, dropping support would ultimately make WordPress’ currently included polyfill script obsolete, decreasing the enqueued scripts size up to 102kB more.
The smaller downloads would positively impact all users, especially those on slower networks, or computing devices. We expect a result of dropping IE11 support to improve performance for the vast majority of users.
Potential Concerns/Blockers
TLDR: The concerns are for those who are unable to upgrade, like financial institutions and education sectors, and those who rely on IE11 for screen readers.
There are major institutions like banking, government, and education that are unable to control when they can upgrade sometimes due to legal requirements, depending on the country. This further underscores the need to determine a policy that takes into consideration both a data-informed approach and the impacted user bases while weighing the potential benefits for the wider web.
According to a September 2019 WebAIM survey, IE11 is still used as a browser among screen readers with 11.5% share. This is an older survey and IE11’s global share was 2.9% at the time the survey was done according to the sources linked above. It takes time for screen reader software to support newer browsers and the latest versions of popular screen reader NVDA have continued improving and adding support for the Edge browser. As a result, this post embraces an assumption that IE usage among screen reader users has declined since the survey as the software improves and overall usage of IE11 has declined. Please let us know if this assumption is or if there is better data available to refer to.
Keep in mind that there are ways to patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. gaps in functionality that’s determined critical to maintain for a time. This post does not seek to go into technical implementation details though.
Share your feedback about this proposed policy change to drop support by March 18th
This is a tough decision to make and we want to solicit feedback from as many voices across the community it may impact. Please note, this post is not meant to go over any technical fallbacks at this time but to purely discuss the policy of dropping support.
Once we’ve gathered feedback, the next step will be to consolidate and decide the policy. The actual technical implementation of the policy is most practical to pursue across the numerous WordPress projects.
WordPress 4.5 includes a few performance enhancements for images.
Increased image compression for custom sizes
WordPress 4.5 increases the amount of compression applied to intermediate sizes by changing the default quality in WP_Image_Editor from 90 to 82. As noted in the proposal for this change, this results in a noticeable reduction in file sizes with little change in visual quality. Developers can override the default image quality value using the wp_editor_set_qualityfilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
Improved resizing settings for ImageMagick
For sites making use of ImageMagick, we’ve reduced file sizes further by resizing images more efficiently in WP_Image_Editor_Imagick and by stripping extraneous metadata using the new WP_Image_Editor_Imagick::strip_image() method.
For now, ‘icc’ and ‘icm’ color profiles are retained, along with ‘exif’, ‘xmp’, and ‘iptc’ profiles, which can contain copyright and orientation data. Those who want to retain additional metadata can disable profile stripping by adding a callback function to the image_strip_meta hook that returns false.
Note that the original full sized images uploaded to WordPress are unaffected by these changes.
Introduction of wp_get_upload_dir()
As Jeremy Felt mentioned in his post on Multisite changes, wp_upload_dir() received a major performance overhaul in this release. Those changes were pared with the addition of a new function, wp_get_upload_dir(), which can be used as a more performant way to display information about the uploads directory on the front end. This is particularly useful when building URLs for images in templates. (See #34359)
Note: This proposal was merged to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.CoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. in [36615]. Download the latest nightly build and give it a try!
In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.
Background
The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.
Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.
Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.
Research
With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.
We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.
Example of an image compressed using the current default quality of 90.
Example image compressed with a quality setting of 82.
In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.
Proposal
Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.
As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.
You must be logged in to post a comment.