Generated srcsets cannot be controlled

[tremby]

This is discussed in the closed PR #528. I think it deserves an open issue, since I see the consequences of this missing feature as a major bug.

I'll quote the comment I left on that a little earlier:

At the moment react-imgix is putting entries in the srcset way up to 8192 pixels wide. If my image is only 1000 pixels wide, a browser on a display with a lot of pixels is going to be requesting images way bigger than the source, and Imgix is going to pointlessly upscale the image, wasting the user's time and data.

I can mitigate this by adding fit=max so at least it's never upscaling, but the browser will still download what it thinks are going to be larger versions of the image if the viewport size is increased, say, from 1400px wide to 2000px wide. But for all I know browser implementations may then have unexpected behaviour when the received image isn't actually the width the srcset value said it was going to be.

I should definitely be able to tell Imgix what I know to the the largest available width of the image so it doesn't falsely promise the user that larger versions are available.

To me the lack of this option seems like a very important bug. It's potentially a lot of wasted CPU cycles on both the Imgix side and the client side, wasted cache space on both sides, wasted network traffic, and wasted transfer time.

The lack of ability to make the gap larger between available sizes is another issue -- the smaller the gap is, the less likely it is that the size the browser decides to download has already been generated and cached, meaning a more sluggish experience on average.

From other comments on that PR it looks like the idea was to rewrite parts of this component to delegate to imgix-core-js.

[sherwinski]

Hey @tremby,

From other comments on that PR it looks like the idea was to rewrite parts of this component to delegate to imgix-core-js.

This is still our intention and is slated to be worked on in the near future! Our team has had to focus our efforts elsewhere this year but I'm happy to say we are finally getting around to adding these features. We don't have a timeline currently for when this will be done, but our team can give updates on this issue as they come along.

The lack of ability to make the gap larger between available sizes is another issue -- the smaller the gap is, the less likely it is that the size the browser decides to download has already been generated and cached, meaning a more sluggish experience on average.

The eventual integration of imgix-core-js will allow users to customize this aspect of their srcset as well.

I can mitigate this by adding fit=max so at least it's never upscaling, but the browser will still download what it thinks are going to be larger versions of the image if the viewport size is increased, say, from 1400px wide to 2000px wide.

So to your point yes, with fit=max your browser will still make requests for the larger image, but receive the max-sized image instead. I agree that this can have mixed results depending on the browser and be potentially wasteful. In this situation, we would recommend properly configuring the sizes attribute on the component, which better guarantees that the browser will request a correctly-sized image every time. This way, you can still use the component-generated srcset attribute without worrying as much about wasted memory or CPU cycles.

Obviously there are other reasons for why users may want to fine-tune their srcset, so both strategies will be available for use in the future.

[tremby]

I think you missed my point in that last part a little.

No matter what, the component is making candidate images that it advertises as being up to 8192 pixels wide.

If fit=max is set, those largest ones aren't really that large, but they still advertise being so. (This is already breaking the srcset contract and so is already bad, but that's not the point here.)

Let's assuming for this example that we have a full-bleed image which, correctly, has the sizes attribute unset (or set to 100vw), and where the largest truly available size (i.e. the original image) is 1000 pixels wide.

Whether or not fit=max is set, if the browser width increases from say 1000px wide to 1500px wide such that the browser now decides a different candidate is more suitable, the browser will make a new request, say for myimage?w=1500.

In the case where fit=max was not set, the image coming back is the 1000px-wide original upscaled to 1500px wide, which is a waste. In the case where fit=max was set, the image coming back is the same 1000px-wide image but not cached since it was at a different URL, which is also a waste. The browser just made a request, hid the image while it loaded, waited for the new image to be generated and to come back from Imgix, displayed it again, and it's the same size as the one it just unloaded anyway!

[tremby]

This is still our intention and is slated to be worked on in the near future! Our team has had to focus our efforts elsewhere this year but I'm happy to say we are finally getting around to adding these features. We don't have a timeline currently for when this will be done, but our team can give updates on this issue as they come along.

That's good to hear. I wrote my own in in the mean time. I'm not sure if I'm allowed to licence it as open source, but maybe I'll ask my client in due course.

[luqven]

Looks like #807 addressed this issue. Going to go ahead and close this.

If you're still having an issue/questions, please comment and I'll be sure to re-open it.