WordPress.org

Make WordPress Core

Opened 16 months ago

Last modified 3 months ago

#43524 assigned enhancement

Add another default image size

Reported by: azaozz Owned by: joemcgill
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch
Focuses: Cc:

Description

We've had the srcset and sizes attributes for quite some time and they seem to work quite well.

One problem is that we don't have a 2x images for the built-in large size. Currently when displaying images larger than 512 px on the front-end on devices with high pixel density screens, the browser has only one choice: to output the full size/original image. These images are often as large as 6000px x 4000px and 4MB or even larger.

To fix this and not output needlessly large images we need a new size that should be 2x the current "large" size, max 2048px width or height.

Change History (23)

#1 @azaozz
16 months ago

Once we add that, we can consider changing the logic when outputting the srcset attribute and use the new "xlarge" size as the largest available.

Last edited 16 months ago by azaozz (previous) (diff)

#2 follow-up: @joyously
16 months ago

Would you call it "2xlarge" and have it be a computed size?

#3 in reply to: ↑ 2 @azaozz
16 months ago

Replying to joyously:
Hehe, yep, can be any name that makes sense. If we follow t-shirt sizes, 2xlarge should come after xlarge, right? :)

The size should be 2 x large, so 2048px should be the max width (for landscape) or height (for portrait).

Last edited 16 months ago by azaozz (previous) (diff)

#4 follow-up: @birgire
15 months ago

Sounds like xlarge could be a good addition, but then there's the default 1600 maximum image width for the srcset:

/**
 * Filters the maximum image width to be included in a 'srcset' attribute.
 *
 * @since 4.4.0
 *
 * @param int   $max_width  The maximum image width to be included in the 'srcset'. Default '1600'.
 * @param array $size_array Array of width and height values in pixels (in that order).
 */
$max_srcset_image_width = apply_filters( 'max_srcset_image_width', 1600, $size_array );

#5 in reply to: ↑ 4 @azaozz
12 months ago

Replying to birgire:

We can increase that :)

Also been thinking if we would need 2x medium_large size. That'd be 1536px (can round it up to 1600px?). This will be used for the 2x (retina) images in post_content, as the main column in pretty much all themes is not wider than 768px (800px).

Adding these two new sizes will significantly improve the selection of image sizes, so the browsers will be able to pick a better match from the srcset attribute when displaying images on the front-end. However it will also bump up the processing time/resource usage on the server when creating the image sub-sizes after uploading an image.

This may cause more timeout errors on some shared hosting accounts. Ideally we should have a way of regenerating missing image sizes after an image is uploaded. That depends on #40439 and #43525 being done.

#6 follow-up: @joyously
12 months ago

Could the 2x stuff be made optional?
Most of the sites I work with do not need this, and it seems like such a waste of disk space (out of the client's quota), along with not needing to worry about that extra processing causing timeouts, etc.

#7 in reply to: ↑ 6 @azaozz
12 months ago

Replying to joyously:

Could the 2x stuff be made optional?
Most of the sites I work with do not need this

You mean you never use "large" image size on a retina screen? What about your site's visitors, do any of them have larger high-density screens? :)

#8 follow-up: @joyously
12 months ago

I'm saying that most of my client sites have small images and/or themes that don't display wider than about 1200px.

#9 in reply to: ↑ 8 ; follow-up: @azaozz
12 months ago

Replying to joyously:

Right. What happens when you have to display an image at lets say 800px? You choose the "large" size (1024px by default) and all is good. However it displays "fuzzy" on most Macs, laptops and desktops, as they have "retina" screens, right? :)

#10 follow-up: @joyously
12 months ago

So are you suggesting that on an upload of a 800px image, that a 1024px one is made for large and a 2048px one is made for xlarge? That the user has no choice in what images are used?

Those users with retina screens have to deal with their choice of hardware.

#11 in reply to: ↑ 10 ; follow-up: @azaozz
12 months ago

Replying to joyously:

I'm not sure I follow... :) Image sub-sizes depend on the original image. If it is not large enough to create all sub-sizes, we stop at the largest sub-size we can make. That's all.

For the 800px image from the example above, the only sub-sizes that will be created will be "medium" and "thumbnail" (if the user didn't change the settings for these sizes to something over 800px).

Those users with retina screens have to deal with their choice of hardware.

Sorry but I don't think I understand. Should we make WordPress produce sub-standard websites that look bad on new/nicer screens..?

Last edited 12 months ago by azaozz (previous) (diff)

#12 @stephenwp001
12 months ago

Correct me if I'm wrong but srcset just displays different size images for different size displays/devices, its not a retina solution?

#13 in reply to: ↑ description ; follow-up: @ettoredn
10 months ago

Replying to azaozz:

One problem is that we don't have a 2x images for the built-in large size. Currently when displaying images larger than 512 px on the front-end on devices with high pixel density screens, the browser has only one choice: to output the full size/original image. These images are often as large as 6000px x 4000px and 4MB or even larger.

Sorry for being rude, but please support your claim with actual evidence. Out of every image on a website, it seems unlikely to me that most of them are over 4 MiB and display wider than 1024px.

To fix this and not output needlessly large images we need a new size that should be 2x the current "large" size, max 2048px width or height.

or you can just

add_image_size()

Besides, as pointed out by @joyously, it would increase disk space usage thus it becomes a tradeoff between disk space and user experience/bandwidth efficiency. If, as both my and @joyously experience suggest, there are a relative small number of cases where this is necessary, such situations can be dealt with the single line of code above added inside a theme or plugin.

Last edited 10 months ago by ettoredn (previous) (diff)

#14 in reply to: ↑ 9 @ettoredn
10 months ago

Replying to azaozz:

Replying to joyously:

Right. What happens when you have to display an image at lets say 800px? You choose the "large" size (1024px by default) and all is good. However it displays "fuzzy" on most Macs, laptops and desktops, as they have "retina" screens, right? :)

What should happen is that you upload the image at whatever high resolution you need and then use

wp_get_attachment_image(id, 'full')

or similar functions.

Depending on the value of the sizes attribute and the viewport, the browser will choose the best srcset image to display. I believe if left empty, the browser assumes '100vw', but this may depend on the browser.

Passing an argument different than 'full' would force the widest srcset image to be limited to the given image size.

How srcset and sizes work together, and how the browser chooses the image to render thus download, seems to be an often misunderstood topic.

Last edited 10 months ago by ettoredn (previous) (diff)

#15 in reply to: ↑ 11 @ettoredn
10 months ago

Replying to azaozz:

Replying to joyously:

Sorry but I don't think I understand. Should we make WordPress produce sub-standard websites that look bad on new/nicer screens..?

Presentation should be managed by the theme, not (necessarily) by Core (or model + business logic). We all know WordPress is a mess in the separation of concerns, however Core should just provide "sane" defaults and let theme developers deal with presentation issues such us this one!

#16 in reply to: ↑ 13 @azaozz
10 months ago

Replying to ettoredn:

Sorry for being rude, but please support your claim with actual evidence. Out of every image on a website, it seems unlikely to me that most of them are over 4 MiB and display wider than 1024px.

Right. This ticket comes as a result from looking at few websites I have access to :)

The facts:

  • Most modern cell phones create JPEG files of 2 - 2.5MB.
  • Most modern cameras create JPEG files of at least 3MB (up to about 24MB in raw formats).
  • Most users upload these photos without editing them beforehand.
  • Currently WordPress doesn't have a suitable file size for larger high density displays like MacBooks, newer Dells, Surface Pro, 4k or 5k monitors, etc. etc.

The only option now to display non-fuzzy larger images (width of 600-700px+) on the above screens is to load the "full" size images, i.e. at least 2MB per image. This ticket is about creating a suitable size for this case.

Besides, as pointed out by @joyously, it would increase disk space usage thus it becomes a tradeoff between disk space and user experience/bandwidth efficiency.

As far as I see the new size will be about 600-700KB, and will save a lot of bandwidth for most WordPress sites. As disk space is considerably "cheaper" than bandwidth, this would result in lower hosting costs and better user experience for 1/3 of the internet :)

#17 @pento
8 months ago

  • Milestone changed from 5.0 to 5.1

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


5 months ago

#19 @mikeschroder
5 months ago

  • Milestone changed from 5.1 to 5.2

Moving to 5.2 because this depends on #40439 to avoid increased HTTP errors.

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


5 months ago

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


5 months ago

#22 @joemcgill
5 months ago

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

#23 @desrosj
3 months ago

  • Keywords needs-patch added
  • Milestone changed from 5.2 to 5.3

5.2 beta is in a little over a day. Since this still needs a patch, I am going to punt it to 5.3. @joemcgill if you are confident in this for 5.2, feel free to move it back.

Note: See TracTickets for help on using tickets.