WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 3 months ago

#45406 assigned defect (bug)

Add additional default image sizes for srcset to accommodate wider viewports

Reported by: mor10 Owned by: mikeschroder
Milestone: 5.3 Priority: normal
Severity: major Version: 5.0
Component: Media Keywords:
Focuses: Cc:

Description

Related Gutenberg issues:

Duplicate of Gutenberg issue 11821 https://github.com/WordPress/gutenberg/issues/11821.

Problem

Images aligned to alignwide and alignfull need proper size options from the srcset attribute. Currently the sizes generated for a large image (eg 4000px wide) by core are:

  • original
  • 300px
  • 768px
  • 1024px

(Themes and plugins can generate additional sizes.)

This means for image displays wider than 1024px, the original size image file will be used which imposes a significant performance hit on the end-user.

These sizes should be closely tied to real-world data about viewport widths. Currently the only readily available data is screen sizes. One source is StatCounter's worldwide screen resolution stats http://gs.statcounter.com/screen-resolution-stats. They break down as follows (October 2018):

Screen size Usage percentage
360x640 20.04%
1366x768 11.84%
1920x1080 9.4%
375x667 5.07%
1440x900 3.26%
768x1024 2.61%

Proposal

Align automatically generated image sizes to browser stats taking into account 2x and 3x displays.

Proposed new sizing array:

  • 375px (covers <=375px widths)
  • 768px (covers 768px and 375x2 widths)
  • 1125px (covers <=1125px and 375x3 widths)
  • 1440px (covers <=1440 widths)
  • 1920px
  • 2304px (covers <=2304px and 768x3 widths)
  • 2880px (covers <=2880px and 1440x2 widths)
  • 3840px (covers 1920x2 widths)

This might seem like a lot, but for most images only the smaller sizes will be generated. For larger images, providing these additional sizes available for the srcset attribute will ensure the browser pulls down the smallest possible image for wide images displayed in wider viewports.

Note

This permanently disassociates the physical image sizes from the classic display widths defined by WordPress. Which makes sense because the old modality of pixel widths defining small/medium/large image sizes no longer applies anyway.

Change History (10)

This ticket was mentioned in Slack in #core-themes by mor10. View the logs.


7 months ago

#2 @kevinwhoffman
7 months ago

One issue I see with the proposed sizing array is that the image sizes get farther apart as they get larger, when they should instead get closer together. The reason for this is that small variations in image width at large resolutions result in drastic increases in resolution and therefore file size. This effect is outlined nicely in this article:

https://cloudfour.com/thinks/responsive-images-101-part-9-image-breakpoints/#memory-usage-influencing-the-distribution-of-image-breakpoints

As an example using the proposed array, consider the jump in resolution between the two consecutive image sizes at a 3:2 aspect ratio.


Example 1 Comparing Consecutive Medium Sizes

1125X750 = 843,750

1440x960 = 1,382,400

1,382,400 - 843,750 = 538,650 pixel difference between two consecutive sizes


Example 2 Comparing Consecutive Large Sizes

2880x1920 = 5,529,600

3840x2560 = 9,830,400

9,830,400 - 5,529,600 = 4,300,800 pixel difference between two consecutive sizes


Results

4,300,800/538,650 = 798% more pixels are added between the large jump compared to the medium jump, which emphasizes the importance of spacing larger image sizes closer together.


Correcting this issue would require many more image sizes to be added closer together for large viewports. This sheds light on an underlying problem of generating the same image sizes for all uploads in WordPress since there is no way to exclude those large image sizes for the majority of use cases that don't need them.

Striking the right balance between the number of image sizes generated and their effect on page weight is going to be extremely difficult, especially because this solution must be designed without the knowledge of a site's page layout. I'm not sure there is a one-size-fits-all solution, but I do think the jumps between sizes should be reconsidered if we are going to add more default image sizes.

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


7 months ago

#4 @matveb
6 months ago

  • Milestone changed from Awaiting Review to 5.1

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


5 months ago

#6 @mikeschroder
5 months ago

  • Milestone changed from 5.1 to 5.2
  • Owner set to mikeschroder
  • Status changed from new to assigned

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

Related: #43524

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


5 months ago

#8 @bahia0019
4 months ago

I just had a client tell me that he was seeing blurry images in his Galleries after switching to Gutenberg. I had set up his theme to generate larger Thumbs, and they were working fine before.

I've been saying we need larger Thumbs cut by default for a couple years now. So, I'm glad this is being done.

Unfortunately, I'm not as skilled as a programmer as you guys. But if you need any support, I'm happy to assist, help, test, coding gruntwork, whatever. All I do is work with Photographers and their sites, so I can provide feedback, or even other photographers to help test things at scale.

Very excited this is finally on the roadmap.

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


3 months ago

#10 @mikeschroder
3 months ago

  • Milestone changed from 5.2 to 5.3

@bahia0019 Thanks so much! Will keep that in mind -- Feedback and testing is super helpful! I wouldn't discount yourself too much -- we're all equals here trying to make WordPress better. :) Would love your eyes and opinion on what's happening in #40439 and its related patch.

I'm unfortunately going to need to push this ticket to 5.3 due to my lack of availability before beta for 5.2, and the ticket's dependence on #40439, which is an enhancement.

I'd still really like to see both land, but as we're into beta, it's too late in the cycle at this point.

Note: See TracTickets for help on using tickets.