WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 14 hours ago

#37840 new enhancement

Optimize full size images

Reported by: joemcgill Owned by:
Milestone: 4.8 Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch
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?

Change History (19)

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


7 months ago

#4 @lukecavanagh
7 months ago

@joemcgill

That makes sense.

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


7 months ago

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


7 months ago

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


7 months ago

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


6 months ago

#9 @joemcgill
5 months ago

  • Milestone changed from Awaiting Review to Future Release

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

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


4 months ago

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


2 months ago

#13 @joemcgill
4 weeks ago

  • Milestone changed from Future Release to 4.8

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


4 weeks ago

#15 follow-up: @bahia0019
4 weeks 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 weeks 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
13 days 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.


13 days ago

#19 @enshrined
14 hours 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?

Note: See TracTickets for help on using tickets.