Bethany Chobanian Lang 4:31 pm on April 5, 2022
Tags: , , , , ,   

Performance team meeting summary 5 April 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus group updates

Announcements

@mxbclang

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Site Health

N/A

GitHub project

Feedback requested

Measurement

@wp-source @josephscott

GitHub project

  • No updates

Feedback requested

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/.

@aristath @sergiomdgomes

GitHub project

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Images

@adamsilverstein @mikeschroder

GitHub project

Enabling webP by default discussion

@adamsilverstein

  • There has been quite a bit of feedback on the proposal to Enable WebP by default in core
  • Originally proposed in the WP 5.8 WebP support post in June 2021 and implemented in the Modern Images plugin for testing in July 2021, then merged into the Performance Lab 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 in December 2021
  • This approach is gaining popularity because WebP is becoming so widely popular – Wix and Shopify are both moving in this direction
  • Original feature focused on replacing JPEG subsize output with WebP output; during dev, it became clear that adding WebP as a second type was safer and more backwards compatible
  • This approach is a trade off that favors backwards compatibility over storage space or number of files
  • The important criticisms shared in the comments on the proposal were (in order of number of times mentioned):
    • There should be controls (toggle) for the feature under Settings->Media
    • Adding an additional sizes to image generation will consume too much disk space, causing sites or backups to fail or increase storage cost
    • WebP problems: not supported everywhere (email clients, RSS readers, lazy loading), enabling by default will cause problems (for example saving images from site), AVIF or MozJPEG is better
    • The feature should default to off, or default to off for existing sites
  • Given this feedback, here are the options that we want to consider moving forward:
    • Add controls in Settings->Media – most popular request. What should this look like?
      • A simple, single toggle: “Enable modern image formats” (?)
      • Plugin for full controls: source mime -> output mimes mapping, output preference
      • Should we include an option for “only modern formats”?
    • Change the default behavior – second most popular request:
      • Disabled by default for existing sites (opt in)
      • Enabled by default for new sites (opt out)
      • Consider enabling by default for all sites in WordPress 6.1 (opt out)
  • @loop9: This should not be a forced change or require a 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. to opt-out. It should be opt-in with a simple toggle to opt in.
  • @eatingrules: There needs to be explanation alognside the controls, as well, to explain the pros/cons
  • @jb510: Add a toggle; WebP could be on by default for new installs, but not existing
    • @eatingrules: That’s just kicking the can down the road for space/inodes issues
    • @jb510: Difference on new installs is that storage requirements would grow over time with uploaded images
    • @eatingrules: Yes, but still doubling down on technical debt
  • @OllieJones: If enabled, viewing/downloads should not be made the default until a bulletproof <picture> <source> way of generating images is also available
  • @dainemawer: If you choose to go with WebP, storage issues will always be a possibility, so how does a toggle solve this?
    • @adamsilverstein: Good point, it would help if there was an option to only generate WebP
    • @dainemawer: Yes, and the very existence of add_image_size is more of an argument about storage than a change in format
  • @eatingrules: Another concern: WebP is not always smaller than JPG
  • @jb510: We ought to be focusing first on eliminating the needless creation of thumbnails, but that’s out of scope here
    • @eatingrules: May be out of scope, but should be fixed before this doubling of images happens
    • @adamsilverstein: See https://github.com/WordPress/performance/issues/14
  • @blogaid: Why is fixing the thumbnails issue out of scope here? That is the greatest concern with the WebP generation of more images. It should be addressed to further cut down on image bloat.
    • @jb510: This is about supporting WebP in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The thumbnails issue is regardless of media type, so that ought to be its own topic
    • @blogaid: But it needs to be addressed before adding WebP images
    • @loop9: Opt-in movement is being pushed aside and it seems like it’s not even being considered
  • @flixos90: The storage problem only happens because we are generating WebP and JPEG subsizes. The original proposal was to only generate WebP subsizes, which would reduce necessary storage. How commonly would a site still need to use JPEG versions? Do we really need to do this?
  • @adamsilverstein: One idea was to generate only WebP except for “full” size images, which could be in both WebP and JPEG
  • @eatingrules: One issue that has surfaced for us in the past is when site owners do a right-click > Save As, WebP causes significant confusion and problems
    • @flixos90: Fair point, but not a WebP issue only
    • @eatingrules: Yes, but will still be an issue until a format 100% replaces JPEG
  • @adamsilverstein: Having some kind of control in settings would alleviate most concerns, but what exactly would that look like?
    • @zero4281: Agreed that most of this could be handled by limiting controls
  • @eatingrules: This should be a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. and not in core. Would love to see this as an easy-to-use, more compatible plugin that optimizes images.
  • @blogaid: Need to reevaluate if this feature is needed at all instead of spending more time fixing it. Where is the documentation that shows that the majority of site owners want this feature and how many sites it may harm?
  • @flixos90: We need to be careful to not interpret comments as a vote. It’s natural that concerns are more likely to be raised than agreement. We want to see concerns addressed, but want to talk about concerns instead of just “people don’t want it in core”
  • @loop9: Zero thought seems to be going to those who care more about quality vs. actual speed, like photographers
    • @dainemawer: There is no degradation of quality with WebP
  • @seedsca: This will cause compatibility issues across several use cases, vote not to implement
  • @blogaid: Would instead like to see MozJPEG supported all the way through thumbnails so that they also have progressive load and a modern format
  • @eatingrules: The discussion here should be whether or not this should be in core in the first place. Has that already happened?
    • @jb510: Yes, there’s a large consensus and this discussion is about how best to move to modern file types in WP
  • @flixos90: There are three focuses that we need to keep in mind: 1. most backward compatibility, 2. best performance, and 3. least filesystem storage
  • @seedsca: This plugin isn’t even out of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. yet; why are we talking about merging this into core?
    • @jb510: This is the point of the plugin
    • @eatingrules: 6.0 is coming up soon and there hasn’t been any time to test
    • @flixos90: The plugin’s version is solely for infrastructure testing, not the feature itself
  • @spacedmonkey: Maybe we should not put this in 6.0 and give the community and hosting companies time to test the performance plugin for awhile. It could be a headline feature in 6.1.
    • @eatingrules: Yes, my personal issue is partly because of the speed at which this is moving

Feedback requested

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary