Add additional default image sizes for srcset to accommodate wider viewports

[mor10]

Related Gutenberg issues:

• 6177 ​https://github.com/WordPress/gutenberg/issues/6177
• 6131 ​https://github.com/WordPress/gutenberg/issues/6131
• 11973 (PR) ​https://github.com/WordPress/gutenberg/pull/11973

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.

[kevinwhoffman]

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.

[kirasong]

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

Related: #43524

[bahia0019]

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.

[kirasong]

@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.

[kirasong]

Do you think this is handled by the additional sizes that were added in #43524, or should additional ones be added as well?

cc: @azaozz

[joemcgill]

Let's leave this open as I believe #43524 partially address the issue, but @mor10's proposal here—including the points from @kevinwhoffman about the need for more sub-sizes at higher resolutions still hold true. We can evaluate the impact of adding sizes in 5.3 and implement further improvements for 5.4.

[paaljoachim]

Is there any movement on this ticket in relation to WordPress 5.4?
Associated Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/11822
Thanks!

[davidbaumwald]

With 5.4 Beta 3 landing tomorrow, this is being moved to Future Release. If any maintainer or committer feels this can be resolved in time or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.