Jetpack: lossless image optimization of PNGs in projects/plugins/jetpack

[danluu]

Proposed changes:

This is part of a project to optimize images in wpcom. Since this used lossless optimizations, this have a user-observable impact other than improved performance.

Although Automattic doesn't tend to A/B test a lot of performance improvements, this in progress A/B test seems to show that we get significant gains in conversion rate / engagement and probably also revenue from optimizations like Automattic/wp-calypso#88786.

For jetpack, it seems like we need to push the change here and then have it get automatically copied back into wpcom. This is being split into multiple PRs in an attempt to avoid running into the 20 MB max commit size limit in wpcom. Although Automattic/themes#7671 was "only" 17MB, when that was automatically copied to wpcom, it exceeded the 20 MB limit. This PR is only 4.1 MB, which will hopefully avoid running into the 20 MB limit.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

Without attempting to do any kind of automatic image content comparison, the simplest way to test this is probably to just look at the image diffs in github and eyeball them to make sure there aren't any drastic changes. That won't catch any issues that come up due to PNG metadata stripping, but unlike JPEG exif info, it's quite rare for users to rely on that metadata.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the try/lossless-image-optmization-plugins-jetpack-png branch.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack try/lossless-image-optmization-plugins-jetpack-png
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team Review" label and ask someone from your team review the code. Once reviewed, it can then be merged.
If you need an extra review from someone familiar with the codebase, you can update the labels from "[Status] Needs Team Review" to "[Status] Needs Review", and in that case Jetpack Approvers will do a final review of your PR.

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen daily.
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly. The next release is scheduled for August 6, 2024 (scheduled code freeze on August 5, 2024).

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[anomiex]

I ran ImageMagick's compare utility on all the images, and it didn't show any having any visual differences.

To reduce the risk of hitting the 20MB limit, we may want to do the following to merge and deploy this:

1. Deploy everything pending to wpcom (see PCYsg-Jjm-p2). Or wait for the daily to happen.
2. Merge this. Wait for CI to build and mirror to Automattic/jetpack-production.
3. Deploy again right away.
4. Also, probably would be good to run tools/deploy-assets-to-svn.sh after merging this to get the .w.org-assets file changes onto wporg, so it doesn't surprise whoever does that next time for something unrelated.

[anomiex]

Actually, now that I think about it more, that complex process wouldn't limit it to just this PR, because the deploy is from "previous sun to new sun" rather than "moon to sun".

[danluu]

I looked into the previous diff that had to be split up and I'm wondering if the size of binary diffs is computed differently on github than at wpcom push.

For Automattic/themes#7671, GitHub a 17 MB diff, but for some reason D144170-code ended up being 97 MB. On doing git show --name-only on that diff and them piping to du -ch, I see that we get about 100 MB, so I'm suspicious that, at least for binary diffs, the 20 MB limit applies to the total size of the files changed and not the relative size of the change.

If I do the same thing for this diff, I get 16 MB for this diff, which is under the 20 MB limit, so if the issue was counting the entire file size and not the diff as the changed size, then this diff seems like it should still be safe as long as it's not bundled with too much other stuff. 4 MB would be quite a large diff for code changes, but if anyone happens to push asset changes at the same time, we could easily end up at over 20 MB. I could split this diff up more (this is about 1/3 of the total changes, so if we divide it in half, we'd end up with 6 PRs instead of 3).

[anomiex]

You're probably right that it counts the full size of the new files. OTOH, as far as this PR goes, note that none of the stuff in .w.org-assets goes to wpcom, but some of the images do get copied around during the build process. Building and comparing to the corresponding base commit in the jetpack-production repo, it looks like those factors balance out for this PR: I get 16M for that too.

We may as well try it and see what happens.

[anomiex]

First of the two deploys (to sun) didn't hit the limit. We'll see what happens when it goes to moon tomorrow along with whatever other commits are merged by then.

[danluu]

Great! And thanks for being so on top of this! I'll wait to see what happens before doing the next part of this. I can always break it up into arbitrarily tiny pieces if it turns out there was still a size issue.

[anomiex]

Moon deploy didn't run into a size issue either.