Tag Archives: performance

Héctor Prieto 7:14 pm on March 25, 2021
Tags: , , performance   

Discussion summary: Dropping support for IE11

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.

The decision when will be left to the release team for WordPress 5.8; this team is not formed yet as it depends on the April go/no-go Full Site Editing merge.

This post was written in collaboration with @mkaz, @annezazu, and @youknowriad.

#accessibility, #browser-support, #performance

annezazu 10:17 pm on March 23, 2021
Tags: , , , performance   

Core Editor Improvement: Performance Matters

Thank you to @aristath @youknowriad and @priethor who helped with this post.

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 Contributors Core 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 CoreCore Core 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 GutenbergGutenberg The 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.
  • BlockBlock Block 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).

Specifically, this work includes everything from improving how performance benchmarks are measured for PRs to smoothing out the experience of using the Block Inserter to continually tweaking block interactions to improving consistency in performance benchmarks. At the end of the day, Core developers take a comprehensive approach when working to meet or exceed these performance benchmarks while improving the user experience for all WordPress users. You can read more about the journey towards a performant web editor in this very informative post from WordPress Contributor, @youknowriad. 

The work on performance is never done though (just check this PR out) so, if you’re interested in helping in this area, make sure to join #core-editor, check out the current focuses, and attend the Core Editor weekly meeting Wednesday @ 14:00 UTC.

#core-editor, #core-editor-improvement, #gutenberg, #performance

Héctor Prieto 10:50 am on March 4, 2021
Tags: , , performance   

Discussion: Dropping support for IE11

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.71% from StatCounter’s GlobalStats.
  • 1.2% from W3 Counter.
  • 0.46% from WordPress.comWordPress.com An 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. 

In August 2020 Microsoft themselves announced that Microsoft 365 and Teams apps would stop supporting IE in the upcoming months. However, given that IE11 is a component bundled with Windows10, according to the IE Lifecycle it will still receive security updates as long as the Windows version it was shipped with continues to receive support. 

In terms of the current WordPress user experience, a flag was added to not recommend IE in BrowseHappy about 13 months ago, so by now, most WordPress users should be aware. Tied to this, the experience overall is not optimal in IE11 with a high cost of maintenance for developers.

Proposed Policy

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 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/.. 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 GutenbergGutenberg The 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/ JavaScriptJavaScript JavaScript 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 patchpatch A 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. 

Thank you to @mkaz, @annezazu, @youknowriad, @desrosj for help writing and reviewing this post. 

#accessibility, #browser-support, #performance
Joe McGill 3:46 pm on March 12, 2016
Tags: , , , , , performance   

Performance improvements for images in WordPress 4.5

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_quality filterFilter Filters 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)

#4-5, #dev-notes, #images, #media, #optimization, #performance

Joe McGill 12:51 pm on February 22, 2016
Tags: , , , performance   

Proposal: Increase the default image compression in WordPress

Note: This proposal was merged to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.Core Core 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.

Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

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.

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.

#image-editor, #images, #media, #performance

Matt Mullenweg 3:28 am on July 13, 2010
Tags: performance   

Forcing GZIP: http://www.stevesouders.co…

Forcing GZIP: http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/

This would make an excellent WordPress 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.

#performance

Ryan Boren 6:53 pm on June 18, 2008
Tags: , performance   

Performance tweaking the hierarchy walke …

Performance tweaking the hierarchy walkers and eliminating taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. queries with DD32. CategoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. listings are getting faster.

#categories, #performance

Ryan Boren 10:36 pm on April 18, 2008
Tags: performance   

Eliminated a bunch of usermeta queries f …

Eliminated a bunch of usermeta queries from the Write Post page.

#performance

Ryan Boren 1:56 am on April 18, 2008
Tags: performance   

Sped up the main query for the Manage Co …

Sped up the main query for the Manage Comments page. Shaved some time from wp_list_categories() and wp_dropdown_categories(). Working on the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. dropdowns and checkboxes on the Write Post page next.

#performance

Ryan Boren 12:19 am on April 17, 2008
Tags: performance   

Consolidated three comment count queries …

Consolidated three comment count queries on the Manage Comments page down to one.

#performance