Optimize full size images

[joemcgill]

Many users upload unoptimized full size images to the media library, which can result in unnecessarily large downloads for users when the full size image is inserted in post content or when the full size image is added to srcset attributes.

We could potentially improve things by adding a new image size to WordPress that is an optimized version of the original image and use that on the front end instead of the original uploaded image.

Some considerations:

• We should not modify the original uploaded file.
• Consider potential server implications of adding an additional size.
• Can we determine if a file is already optimized so we don't end up increasing the file size in those cases?

[lukecavanagh]

@joemcgill

So if the image was optimized, would that be stored in the post meta of the image?

[joemcgill]

Replying to lukecavanagh:

@joemcgill

So if the image was optimized, would that be stored in the post meta of the image?

The way I was thinking we might handle this is to compare the original file size against the optimized size and only create the new size if the file size would be better than the original.

[lukecavanagh]

@joemcgill

That makes sense.

[Stagger Lee]

This plugin solved all those problems. How it works have no clue, but works in all modern browsers. No matter how huge images or if they are directly from digital camera, plugin takes care of them.

​https://wordpress.org/plugins/canvas-image-resize/

It has option for resolution of original uoploaded image (1600 x 1600 default), and option for quality.

For instance 1600px x 1600px, and 85% quality, reduced 22 MB image to 1.2 MB. Of course no more huge original. It is just few lines of code. People can use it as plugin but something like this in core would be killer. I dont have any problems on shared servers and I dont care anymore to teach people not to upload images directly from digital camera or smartphone.

I know it is not 100% what @joemcgill asked. He wants to keep original but just not use it in templates.
Somehow I find it better this way plugin works. You decide what max resolution you need and it displays fine on all devices and screen sizes. Rarely people go over 2000 px, if they can choose. Anyway it would cover at least 60-80% websites where people dont know and cannot influence original image, and use very huge files.

[bahia0019]

I just saw this pop up in the summary email. I love the idea, as even I'm confused what to use now that SrcSet is out. Large doesn't cover a 27" screen (let alone a 27" Retina iMac), and Full seems too overkill (even though I use JPEGMini before upload).

I don't know what compression methods are currently being used on upload. Last I knew it was a straight 90% JPEG compression.
But what if we looked at replacing it with something like EWWW that utilizes multiple lossless compression utilities. I think they actually use JPEGMini and TinyPNG.

APIs may be an issue for some of these utilities but (and I can't believe I'm going to say this, as I hate Jetpack), but maybe that becomes an option for Jetpack users.

[kirasong]

Replying to bahia0019:

I don't know what compression methods are currently being used on upload. Last I knew it was a straight 90% JPEG compression.

I believe this ticket has more to do with how WP handles the "full" size than compression changes in the general sense, although there's always room for improvement there as well.

WP does more for image compression than it used to -- especially if the user has Imagick available. It changed significantly in WP 4.5, and you can see some of the details here (and of course in WP_Image_Editor_Imagick):
​https://make.wordpress.org/core/2016/03/12/performance-improvements-for-images-in-wordpress-4-5/

[bahia0019]

Replying to mikeschroder:
Thanks for the info.

So, I've been giving this a bit of thought as I work on another photographer's website and ensuring it works on everything from mobile to 27" monitors.
I do think we need to go to 2000px wide. I haven't looked at a 27"iMac Retina display yet, but I think it can get pretty bad with a 'large' image stretched all the way. My non-retina 27" is 1920 pixel resolution, and it gets pretty fuzzy.

So, what if:
Full becomes Original. (but keep 'Full' for backwards compatibility).
Large stays Large.

But we add two new default, optimized sizes:
Oversized = 1500px wide
and
Fullscreen = 2000px wide

It'll be nice to have the 1500 as an extra size for Src Set. And at 2000px wide, at least images won't look super blurry on a full width iMac.

[enshrined]

I agree with @joemcgill here, I think it makes sense to have an extra image size for an optimised 'full' image but only store it if the difference in filesize actually makes it worth it. Perhaps set the difference as a sensible default but make it filterable?

The new image size would then need to act as an alias for 'full' if it hasn't been generated either due to it not existing yet or because the difference in file size is negligible.

I'm not so sure about adding extra image sizes though, these can be added by themes/plugins and the filters in wp_calculate_image_srcset() should allow you to add these sizes to the srcset without too much trouble. I don't see the need to bloat WordPress's uploads dir too much more when a lot of themes will define these sizes themselves if they need them.

I'd be quite happy to have a crack at a first draft of a patch if the above sounds like the right sort of approach?

[joemcgill]

I think you're right on here @enshrined. Going to go ahead and assign to you for now.

[enshrined]

Patch 1

[enshrined]

Ok, so hopefully this is a good start.

Changes:

Added ‘full’ to the list of default sizes in get_intermediate_image_sizes() this allows us to use it as an actual image size later on.

In wp_generate_attachment_metadata() I’ve updated the default for the get_option() calls to get the default image sizes from the DB. Instead of false, these will now return the original height and width of the image as determined earlier in the function.

Three new methods have been added into class-wp-image-editor.php. There’s a getter and setter for the minimum file size change as a percentage (default is 15%) as well as a main can_save_optimised_full_size() method that does the checking for whether we have compressed over the minimum file size change or not.

There’s also a new wp_image_set_minimum_filesize_difference filter that allows filtering of the difference as a percentage.

Other than that, the checks have been added to the ImageMagick and GD editor classes to skip the duplicate check if we’re on the full size and the can_save_optimised_full_size() method returns true.

From what I’ve seen so far with basic uploading and outputting on pages/posts this seems to work seamlessly and just replace the original image with the optimised version.

It was mentioned on Slack that re-using full may lead to issues with themes/plugins using this size and expecting to get the original image so that’s open to discussion.

I’ve seen full size images drop from 22.3MB to 3.6MB and 17.5MB to 2.8MB respectively so this is definitely a good thing if using full doesn’t break anything.

[enshrined]

Updating keywords as the above patch could do with some more testing. I've been using it with no issues for a while now but some more eyes would be beneficial.

[joemcgill]

Not ready for 4.8 and is currently blocked by #40439 (or a similar solution). Adding early so we can pick this back up for the next major release.

[desrosj]

#37408 was marked as a duplicate.

[mor10]

See ​https://github.com/WordPress/gutenberg/issues/11822

I propose updating the milestone to 5.0. With wide images in Gutenberg, this has become a pressing issue which needs to be fast-tracked for 5.0 release to avoid Gutenberg causing significant performance hits on visitors due to unreasonably large image files being downloaded by browsers.

Practical example of why this is a significant issue: ​https://github.com/WordPress/twentynineteen/issues/50#issuecomment-436829300

[enshrined]

I'm more than happy to refresh the patch for this tomorrow in order to get it ready to merge if it's needed.

We do need to consider how it will affect the upload timeouts that occur though, especially with #40439 being pushed back to 5.1 now. Fixing this issue without fixing the other issue will surely only lead to more people experiencing timeouts. Would be great to get them merged together if possible!

[mor10]

I believe the correct term for this is "mission critical". From my perspective, marking them both for 5.0 and getting this shipped now is essential to avoid increasing the average weight of WordPress sites significantly.

[bahia0019]

I think the issue is because:

1. The WP Responsive Image function doesn't support anything over 1600 pixels wide.
2. There are no larger options to pull from.

What I've found is that any Retina screen invariably pulls the Full size.

I've suggested this before, but we need larger Thumbnail options. Camera megapixels are going to increase, and people are still not going to understand what that means.

I've also suggested that the Original image should be marked as Original. If we can remove that from the Src Set, and only have optimized images display, that'd be better.
I'd still like access to EXIF and IPTC, but I imagine I could still query from the Original and pull into the Post/Page.

[mor10]

See ​https://github.com/WordPress/gutenberg/issues/11821

[bahia0019]

Replying to mor10:

See ​https://github.com/WordPress/gutenberg/issues/11821

Excellent! I'm glad you agree with me Morten. :D

[enshrined]

Refreshed patch for trunk

[enshrined]

As a note, the first patch applies cleanly to 5.0 but trunk needed a refresh, hence the second patch!

[jb510]

I was about to post this on #45406 before finding this trac ticket.

I followed this on GH and also think this is critically important. I think that the path being pursued is the right one (correct srcset support within GB/Themes).

However, I too have always wished that the 'full' image size was a compressed version of the original, not the original itself. Too often the 'original' is poorly optimized and should never be loaded on the front end. This would at minimum prevent the Gutenberg image problem of loading massive uncompressed images. At least until a proper srcset solutions comes in.

[SergeyBiryukov]

#52752 was marked as a duplicate.