WordPress.org

Make WordPress Core

Opened 3 years 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 (2)

37840_1.diff (8.2 KB) - added by enshrined 2 years ago.
Patch 1
37840.2.diff (8.2 KB) - added by enshrined 9 months ago.
Refreshed patch for trunk

Download all attachments as: .zip

Change History (42)

#1 follow-up: @lukecavanagh
3 years 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
3 years 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.


3 years ago

#4 @lukecavanagh
3 years ago

@joemcgill

That makes sense.

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


3 years ago

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


3 years ago

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


3 years ago

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


3 years ago

#9 @joemcgill
3 years ago

  • Milestone changed from Awaiting Review to Future Release

#10 @Stagger Lee
3 years 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 3 years ago by Stagger Lee (previous) (diff)

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


3 years ago

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


3 years ago

#13 @joemcgill
2 years ago

  • Milestone changed from Future Release to 4.8

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


2 years ago

#15 follow-up: @bahia0019
2 years 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
2 years 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 years 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 years ago

#19 @enshrined
2 years 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 years ago

#21 @joemcgill
2 years 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 years ago

@enshrined
2 years ago

Patch 1

#23 @enshrined
2 years 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
2 years 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.


2 years ago

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


2 years ago

#27 @joemcgill
2 years 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.


2 years ago

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


2 years ago

#30 @desrosj
20 months ago

#37408 was marked as a duplicate.

#31 @mor10
9 months ago

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

#32 @enshrined
9 months ago

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!

#33 @mor10
9 months ago

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.

#34 @bahia0019
9 months ago

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.

#36 in reply to: ↑ 35 @bahia0019
9 months ago

Replying to mor10:

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

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

@enshrined
9 months ago

Refreshed patch for trunk

#37 @enshrined
9 months ago

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

#38 @jb510
9 months ago

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.

Last edited 9 months ago by jb510 (previous) (diff)

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


4 weeks ago

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.