How do you determine a good set of breakpoints for srcset image sizes

Question

My website right now is marginal for page loading speed on mobile. Originally written for desktop, I use a lot of images that are relatively high resolution, and only lightly compressed.

I'd like provide srcset images at various resolutions, but before I start, what are the optimum sizes, and how are they determined?

First approximation that occurs to me is (image as % of screen) * (viewport in pixels) and then calculate this for typical (and what is that, this week?) screen resolutions of desktop, tablet and phone.

On reflection, this approximation is naive.

• Reducing the resolution of an image that's too big will give better results than increasing one that is too small.

• There aren't really three situations to consider, but five, as both mobile and tablet can be use in either orientation. I don't want the mobile user to have to slurp up new images when they rotate their phone. This isn't as big a concern for tablets most of the time, as the bulk of tablet usage is on wifi.

• Desktop usage has another factor: While screens have gotten wider, many users will have a browser up at less than full width. This one may not matter that much, as desktops have both the bandwidth and the processing speed to resize images.

• Phones now come in a bewildering range of sizes and resolutions.

At present I'm looking at producing images at widths of 1300, 800, 500, 300 and setting cutoffs at 900 600 and 350, but this is little more than a WAG.

Answer 1

The size of an image is proportional to square of the width. You get far more saving by reducing from the largest size to the second largest size than by reducing anywhere further.

• 1300² = 1,690,000 (100%)
• 800² = 640,000 (37%)
• 500² = 250,000 (14%)
• 350² = 122,500 (7%)
• 300² = 90,000 (5%)

Users on mobile devices may want to be able to turn their device without having to reload images. It would make sense to provide only the size for landscape orientation to improve usability.

I pulled screen width stats from my largest website. It gets millions of visitors per month on a wide variety of devices. The site is a finance website. This data is collected by Google Analytics. My takeaways:

• It doesn't make any sense to serve images wider than 2048 pixels.
• A width of 424 pixels would serve almost all mobile users
• If I were going to serve two image widths, I would choose 2048px and 424px
• The third width would be 1680px
• The fourth width would be 1366px
• The fifth width would be 375px

Also keep in mind that your images will probably be somewhat less than full screen width:

• Most browsers take some pixels on the edges for the browser window border and scrollbar.
• Users on larger monitors may not maximize their browser window.
• Your web page layout may add some white space around images.
• Your web page layout may (and probably should) limit the width of your content. You may not need images more than 1300px in width.

Zoomed in on the steep mobile section

Methodology used to create charts:

• Selected a date range from the last 3 months in Google Analytics
• Created a report of the top 5,000 screen resolutions (width by height) in that time period
• Downloaded the data to CSV and opened it in LibreOffice
• Removed the height from the resolution column (regex x.* replace with nothing)
• Sorted the data by screen width (ascending)
• Deleted extraneous columns, just left with "widths" (column A) and "users" (column B)
• Created a new column (C) for running total of users with screens smaller than the given size. Adds the users at that width to the previous row (formula C3=C2+B3)
• Created a new column (D) to display the previous column as a percent (formula D3=C3/!C5000)
• Created an XY Scatter chart of columns A and D

Here are the top 30 device widths from that data in a table. Any other width represents less than 0.1% of users.

Width (px)  % Users
320        3.82%
360        26.49%
375        13.41%
377        0.08%
384        0.20%
390        0.11%
393        3.35%
400        0.07%
412        11.24%
414        14.84%
424        0.88%
600        0.11%
601        0.11%
768        0.84%
800        0.29%
810        0.13%
834        0.20%
1024       1.09%
1093       0.08%
1280       2.84%
1360       0.28%
1366       5.09%
1440       1.40%
1536       2.49%
1600       1.09%
1680       0.46%
1920       6.15%
2048       0.10%
2560       0.38%

Google Analytics also provides "browser size" as a dimension. Unfortunately, they appear to round the browser widths to the nearest 10 which makes the data less useful. For example the common 424 screen size appears to be lumped in with the 420 browser width. The same goes for 1024 which appears to be rounded down to 1020. In any case, the data does show a much wider variety for larger screen size due to not-maximized windows.

Answer 2

This is a design decision, not a mathematical one. It is impossible to determine how a user will view the image. There is no mathematical equation for what a human likes in design. Using device width works until tomorrow when a new device introduces new sizes. And there are, now, too many devices to keep track of.

Therefore, the best advice is to make your web page wider and taller until the image doesn't look good anymore. That will be your break point.

Answer 3

This article on Medium: Choosing the right sizes for responsive images

points out that 3 images is probably not enough, and makes a case for having a half dozen.

He mentions having servers that resize on the fly to provide any size requested by the client. As someone sharing a server with umpteen other websites, I don't have access to this server modification.

This article on CloudFour.com makes a similar case. Responsive Images Part 9: Image Breakpoints/

Unlike the Medium article, size series shouldn't be a linear scale, but an exponential one. Cases can be made for using the following ratios:

1.414 (square root of 2) This allows the resize to be made by making 1 math intensive interpolation, then the remaining ones are straight forward scale by 2, and resharpen.

1.21 (4th root of 2) Similar logic with smaller steps.

1.618 (Golden ratio (1+sqrt(5))/2)

Fixed percentage each time. This has simpler logic in your script setup, but you may get artifacts from the repeated sampling. Test first before resizing your entire library.

The exponential set is based on the idea that downsampling an image by 20% or upsampling by 5% will still result in a pretty good image, AND will mean you have a fairly small set to deal with.

Cloud Four says that from a performance bandwidth case, you want closer spaced resolutions as they get larger because the size goes up quadratically. This minimizes the memory foot print, and wasted bytes. I don't buy this, as machines that request larger files will usually have more memory and better network connections. It may make a small difference in server provisioning. However if you use a content distribution network, you have to pay for a lot more caching. If really pinching pennies you will need to optimize between bandwidth costs and storage costs.

Note on sharpening: In photo circles, the recommendation is to sharpen as the last step in image processing. Some work by Dave Riecks on the ControlledVocabulary website claims that resizing in multiple small steps with minor amounts of sharpening between each step results in better image quality.