You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I’ve been working with several partner applications on adoption of the image component, I’ve been surprised to find that in quite a few cases, the inclusion of an automated srcset actually hurts performance when using the fill layout mode.
This is because unlike the other modes, which cap srcset resolution at 2x multiplier, the fill mode provides a fixed set of possible resolutions all the way up to 3840w by default. Then on large mobile devices the browser is able to request the 3x image, which is usually about twice the size (in KB) of the 2x image.
There currently isn’t a good way to address this, even if the developer recognizes that the image component is now serving images that are larger than they want. They can change the default srcset breakpoints to remove the highest ones, but this doesn’t work well because often the fill layout is used for images in a grid-style layout, and if you have potential 2-column image layouts as well as 3-column layouts in the same app, there’s no single set of breakpoints that provides the right 2x image for both.
Describe the solution you'd like
I propose that we add the ability to add a manual cap to the image component for use in the fill layout. This still isn’t an ideal solution as it relies on manual intervention, and doesn’t provide a perfect solution for the case of responsive, variable-column grids, but should at least unblock developers trying to control resolution in the (fairly common) case of a fixed grid layout.
+1 to this, I want the image to fill, but I know the maximum dimensions it can have. Since the generated tag forces position: relative inline, I can't override this to set absolute, too.
This would be amazing if it is gonna be supported in the future. For now, I had to wrap it in a div that would contain the max dimension having layout: fill, which is not ideal, to be honest.
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Describe the feature you'd like to request
As I’ve been working with several partner applications on adoption of the image component, I’ve been surprised to find that in quite a few cases, the inclusion of an automated
srcset
actually hurts performance when using the fill layout mode.This is because unlike the other modes, which cap srcset resolution at 2x multiplier, the fill mode provides a fixed set of possible resolutions all the way up to 3840w by default. Then on large mobile devices the browser is able to request the 3x image, which is usually about twice the size (in KB) of the 2x image.
There currently isn’t a good way to address this, even if the developer recognizes that the image component is now serving images that are larger than they want. They can change the default
srcset
breakpoints to remove the highest ones, but this doesn’t work well because often the fill layout is used for images in a grid-style layout, and if you have potential 2-column image layouts as well as 3-column layouts in the same app, there’s no single set of breakpoints that provides the right 2x image for both.Describe the solution you'd like
I propose that we add the ability to add a manual cap to the image component for use in the
fill
layout. This still isn’t an ideal solution as it relies on manual intervention, and doesn’t provide a perfect solution for the case of responsive, variable-column grids, but should at least unblock developers trying to control resolution in the (fairly common) case of a fixed grid layout.It could look like this:
<Image src=”/foo.jpg” layout=”fill” maxWidth={640} />
We could also throw an error if
maxWidth
is used with a non-fill
image, as those should be controlled using theheight
andwidth
attributes.The text was updated successfully, but these errors were encountered: