Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The image was acceptable for me. What do you want for 15kb? I'd expect a higher quality for click to expand, but this is acceptable to me alongside text content.


>What do you want for 15kb?

I dont want 15KB, because difference between 15 and 70 is 5 milliseconds.


> I dont want 15KB, because difference between 15 and 70 is 5 milliseconds.

And I want it, as on travelling or mobile I'm golden if I get 1 MBit/s (= 128 KiB/s) download bandwidth, more often it's around 300-400 KBit/s (37-50 KiB/s), so:

  1 MBit/s and one image -> 546 ms vs. 117 ms
  300 KBit/s and 1 image -> 1892 ms vs. 405 ms
Most sites have more than one image, say five for some realistic example:

  1 MBit/s BW:
  AVIF 15 KiB: 0.6s
  JPEG 70 KiB: 2.7s

  300 KBit/s BW:
  AVIF 15 KiB: 2.0s
  JPEG 70 KiB: 9.5s
That's both quite the noticeable difference.

In my residence I'm lucky and get 100+ Mbit/s and even 1 GBit/s at work, but there are lots of countries in the world that don't and once one is affected by that, like I on my train travels, it gets really noticeable which sites have low-bandwidth ignorant engineers, causing not only frustration but often actually impacting life in more meaningful ways negatively.


That's a good point. There probably will never be a one size fits all solution. Luckily the img srcset provides an option for this scenario.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...


How would that help me when developers will choose to "optimize" the best version to 15KB? Surely 70KB jpeg will be listed as a fallback. There is no option of defining quality/PSNR/PEVQ/SSIM, only pixel density.


For now that is down to the browser to determine which file to load. From a design perspective, it makes sense to have the HQ image load full screen on click.


Yes, I get that. The problem is there isnt much for the browser to base its heuristics on. Would you send HEAD request for all the listed assets to at least get file sizes? This will be slower and might be even more traffic than just grabbing first one.

Requiring listed size/quality for all the sources might not even be feasible without further automation on the server side, not to mention potential content mangling/"optimizing" proxies/appliances.


HEAD requests seem like the only option aside from inferring size from suggested resolution and format. Imagine trusting the author to include the resource size.

If I could add to the spec, I would put something for lofi/hifi. Then of course that is all subjective and developers will eventually use it in problematic ways.

There's already enough gaming around pagespeed scores. If such an incentive is added, the spec needs to be formulated in an ergonomic way to avoid mal-optimizations.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: