WordPress.org

Make WordPress Core

Opened 9 months ago

Last modified 3 weeks ago

#37840 assigned enhancement

Optimize full size images

Reported by: joemcgill Owned by: enshrined
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch needs-testing early
Focuses: Cc:

Description

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?

Attachments (1)

37840_1.diff (8.2 KB) - added by enshrined 2 months ago.
Patch 1

Download all attachments as: .zip

Change History (29)

#1 follow-up: @lukecavanagh
9 months ago

@joemcgill

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

#2 in reply to: ↑ 1 @joemcgill
9 months ago

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.

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


9 months ago

#4 @lukecavanagh
9 months ago

@joemcgill

That makes sense.

This ticket was mentioned in Slack in #core by joemcgill. View the logs.


9 months ago

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


9 months ago

This ticket was mentioned in Slack in #core by joemcgill. View the logs.


9 months ago

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


9 months ago

#9 @joemcgill
7 months ago

  • Milestone changed from Awaiting Review to Future Release

#10 @Stagger Lee
7 months ago

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.

Last edited 7 months ago by Stagger Lee (previous) (diff)

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


6 months ago

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


5 months ago

#13 @joemcgill
3 months ago

  • Milestone changed from Future Release to 4.8

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


3 months ago

#15 follow-up: @bahia0019
3 months ago

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.

#16 in reply to: ↑ 15 ; follow-up: @mikeschroder
3 months ago

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/

#17 in reply to: ↑ 16 @bahia0019
2 months ago

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.

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


2 months ago

#19 @enshrined
2 months ago

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?

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


2 months ago

#21 @joemcgill
2 months ago

  • Owner set to enshrined
  • Status changed from new to assigned

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

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


2 months ago

@enshrined
2 months ago

Patch 1

#23 @enshrined
2 months ago

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.

#24 @enshrined
7 weeks ago

  • Keywords has-patch needs-testing added; needs-patch removed

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.

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


7 weeks ago

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


4 weeks ago

#27 @joemcgill
3 weeks ago

  • Keywords early added
  • Milestone changed from 4.8 to Future Release

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.

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


3 weeks ago

Note: See TracTickets for help on using tickets.