Make WordPress Core

Opened 2 weeks ago

Closed 8 days ago

#61597 closed defect (bug) (invalid)

Resized images larger in filesize than original, when setting jpeg_quality to 100

Reported by: johnny538's profile johnny538 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.5.5
Component: Media Keywords:
Focuses: Cc:

Description

I prefer to optimize my images before I upload them. One of the reasons is so I can avoid image optimization plugins.

I set the jpeg compression quality to 100 using the jpeg_quality filter. This works like intended. My original image remains the same file size.

But when WordPress resizes images according to all the registered sizes, they're often much larger than the original, even though the image dimensions are now smaller.

For example, when uploading a 640x427 jpeg at 11kb, the resized 300x200 version is now 30kb. Almost triple the size of the original file, which is larger in dimensions. Even the thumbnail version of 150x150 is 14kb.

Just imagine how this would go on a large site with gigabytes worth of images...

Steps to reproduce:

  1. Add the snippet to disable compression:
    <?php
    add_filter('jpeg_quality', 'reset_jpeg_quality');
    function reset_jpeg_quality($args) {
        return 100;
    };
    
  1. Upload a jpeg image
  2. View the generated sizes in your media directory (using ftp or a file manager)

What I expect to see instead?

The resized versions, if smaller in dimensions, should also be smaller in file size. Or generation should be skipped entirely if the file size is larger.

Change History (4)

#1 @adamsilverstein
2 weeks ago

Hi @johnny538 thanks for the bug report.

I prefer to optimize my images before I upload them. One of the reasons is so I can avoid image optimization plugins.

This will work for the original or main image you upload which WordPress leaves untouched. However, for the "generated" image sizes that core creates and then uses for image srcset entries, this relies on Imagick or GD to create the images- you can't override these images directly as a user (at least, not without a plugin). As you mentioned, you can control the quality setting used when generating these images.

This works like intended. My original image remains the same file size.

Note WordPress never alters the original image, regardless of the quality setting.

But when WordPress resizes images according to all the registered sizes, they're often much larger than the original,

I think that is to be expected with a quality setting of 100, this could easily create larger that the original sized images especially if the original had a lower quality setting.

The resized versions, if smaller in dimensions, should also be smaller in file size. Or generation should be skipped entirely if the file size is larger.

that should generally be true with the default 82 quality setting. Also, some users might still want the images generated even if larger, so they don't experience broken or missing image sizes for responsive layouts.

#2 @roytanck
12 days ago

There's often confusion about this, so I'd like to add that saving an image in the jpeg format will always reduce it's quality. Even at 100, the compression is still lossy. Re-saving a jpeg will also further reduce the quality. Jpeg compression is never lossless.

Also, setting the quality to 100 is generally not a good idea. From around 80 to 100 the file size increases significantly, while image quality is does not.

#3 @nosilver4u
8 days ago

Indeed, as Adam and Roy have both said, 100 quality isn't doing what you think it is, and is a really bad idea. For perspective, the file size can increase over 4x when going from the default quality 82 to quality 100. If you really want to push the quality, go with 90-92. Anything beyond that is just wasting space. Here's some further reading if you like: https://docs.ewww.io/article/12-jpg-quality-and-wordpress

#4 @johnny538
8 days ago

  • Resolution set to invalid
  • Status changed from new to closed

Thanks for the explanations, all.

I'll close, since there's really no fix for this.

Note: See TracTickets for help on using tickets.