Make WordPress Core

Opened 2 years ago

Last modified 21 months ago

#57003 new enhancement

Compress original image upload to avoid uncompressed images

Reported by: flixos90's profile flixos90 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch needs-unit-tests
Focuses: performance Cc:

Description

When an image is uploaded to WordPress today, WordPress will generate the sub-sized versions using compression with the default quality (e.g. 82 for JPEG). The point of this is to offer smaller versions to achieve better performance with different viewport sizes. The compression here is a significant part of it, as we would not want those smaller sized images to be badly compressed and thus overly large in file size.

A problem (and I would argue oversight) in that approach is that the originally uploaded image is still used as is in many cases, even in the frontend. #47873 introduced the feature to compress "big" images in a smaller version, which makes sense, however that is only part of the potential problem here: It can also happen that the original image upload is simply an overly large file, even if the dimensions of the image are smaller than what makes it qualify for a "big" image.

This ticket proposes the following:

  • Always generate a new image from the originally uploaded image, even when it is not a "big" image (potential exception could be PNGs as currently the case, see #48736).
  • Once the image has been generated, compare the file size of the new image with the original image:
    • If the new image is smaller, use that one going forward, backing up the original image in the same way it already happens as part of the "big" image feature.
    • If the new image is larger (i.e. the original was already well compressed), delete the new image again and simply keep the original as is.

Given that we already generate an additional image file for "big" image uploads, this enhancement would not introduce any concerning overhead. It also does not make any assumptions on the original image quality, it simply compares the results to make a decision which image to keep. In any case, the original image will be kept so it would not be a destructive action either.

Change History (8)

#1 follow-up: @flixos90
2 years ago

@azaozz Would love to get your input on this idea.

Related question about #48736: Reading through that ticket, it appears we simply do not generate a scaled-down PNG because the image could be larger. Shouldn't we introduce a file comparison check like I'm proposing here in any case? This way we could potentially remove that condition to not attempt PNG downscaling and instead make a decision afterwards which image is "better".

#2 @azaozz
2 years ago

the originally uploaded image is still used as is in many cases (when it is smaller than the "big image" threshold).

Yes, it is. This covers the cases where the originally uploaded image is already prepared for use on the internet, either has been edited by the user or was downloaded from somewhere.

  • Always generate a new image from the originally uploaded image, even when it is not a "big" image.
  • Once the image has been generated, compare the file size...

I agree, this will potentially reduce the size of many images. However it will also degrade the quality, perhaps quite a bit in some cases.

The general assumption is that smaller images are ready for use on the internet (are not photos coming straight from a camera). This seems to be the most common case. If WP re-compresses them, the file size will likely be smaller. However the loss of quality of an image going through second lossy compression is usually significant.

Nevertheless I think introducing some functionality to re-compress images and compare file sizes would be a nice addition. If an image is not ready-for-internet, the compressed copy would be quite smaller.

Perhaps can try to set a threshold of how smaller the new file must be in order to "archive" the original and use the newly created image instead. Of course it should still err on the side of quality, i.e. the image created by WP should be significantly smaller in file size, perhaps > 30%.

Having said all that, adding one more "processing" of uploaded images would slow down the overall process. Perhaps it won't introduce more uploads failures as only smaller images will be processed, but still thinking something like this will be best to implement after WP can make image sub-sizes "on the fly". Ideally this functionality will be dependent on removing the image post-processing bottleneck.

Last edited 2 years ago by azaozz (previous) (diff)

#3 in reply to: ↑ 1 @azaozz
2 years ago

Replying to flixos90:

it appears we simply do not generate a scaled-down PNG because the image could be larger.

Correct. WP doesn't try to scale large PNGs because the resulting images usually have larger file size, sometimes significantly (1.5 - 2 times) larger. Scaling of PNGs with (some versions of) GD and ImageMagick seems to be somewhat problematic.

Shouldn't we introduce a file comparison check like I'm proposing here in any case? This way we could potentially remove that condition to not attempt PNG downscaling and instead make a decision afterwards which image is "better".

Yes, that would be nice. However thinking the post-processing of PNGs would need to be improved as much as possible first. Then this functionality should depend on removing the image post-processing bottleneck, same as above.

Just FYI: the PNGs that exceed the big_image_size_threshold are quite rare. Such large PNGs (over 2560px) are simply not useful. Even had trouble finding "real life" images to test with.

Last edited 2 years ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


21 months ago

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


21 months ago

#8 @antpb
21 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to Future Release
Note: See TracTickets for help on using tickets.