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
There are definitely diminishing returns, and accelerating costs, with DPRs > 2... are you seeing bad effects on real pages? Small 3x viewports downloading resources meant for 5K displays or something?
I love the “browser knows best” attitude of srcset, but if this is a case where browsers are making bad decisions, I suppose that’s why we have <picture>. Maybe file bugs with browsers, too, though?
Chrome goes some way towards mitigating these diminishing returns by picking the closest resource, rather than the smallest-resource-that's-bigger, when DPR ≥ 2. But there are definitely cases on hi-DPR screens when you might want to aim even lower.
(Back in the day I had a too-clever-by-half idea about this. A hard limit like 2x is probably better.)
I've seen browsers download really heavy images on mobiles, and I think it is not necessary most of the time. We now have 4x screens on some phablets.
Unfortunately, we can't really expect Jekyll users to implement client hints like save-data, so I thought it would be nice to add a way to reduce the bandwidth waste for all visitors.
I don't think browsers should decide this themselves.
I like you square root formula, but I think sticking to a simple limit of 2x should be enough… ;-)
For example, 2x images should be enough on most websites, even on devices with 3x screens.
Use a
<picture>
with a dpr-based media query to limit the maximum screen resolution served.The text was updated successfully, but these errors were encountered: