Hacker News Reader

Comment by xuki | Hacker News Reader

Warning: this site use ~250MB of your data for all the photos. Mobile users, beware!

On my phone it opens the page almost instantly and then lazy loads each image as it comes into view.

Strange, on desktop it pulls down all the images on page load.

The problem is not really about if the images are lazy-loaded or not though, the author is using the wrong format for the images. There are just 16 images, but each one is over 10MB big because the author is using PNG for photographs, when they really should be using JPG instead.

Maybe they don't prefer loss and compression? We all have our (often disagreeing) preferences...

If you set the quality parameter to > 95% when creating a JPG from original picture, you won't be able to tell any differences between the PNG and the JPG, especially when the full width of the image is limited to max 720 pixels as it is on this website.

There is literally no reasons to prefer PNG over JPG in this specific scenario.

Sure there is. Storing, and sharing lossless images.

I find it amusing that you (and others) presume why some did a thing. Their motivations.

If you want something stored for historical reasons, shared by media, news, archive.org, png presents unvarnished stuff.

5, 10 years from now, people will scratch their head, and wonder why people cared about such tiny filesizes.

FLAC used to be only for extremists too.

I have nothing against storing and sharing lossless images. But do it efficiently if you're gonna do it. Showing 10+ images that each weight a lot is not efficient. Instead, show the compressed image on the website (as it's limited to 720 width anyways), and add a link to the original. Now everyone is pleased.

I downloaded the 1.png file and converted it to a JPG and also diffed the origianl PNG with the JPGs I generated (90% in quality and 80%).

- Original PNG: 51M

- 95% JPG: 13M

- 90% JPG: 9.4M

- 80% JPG + interlace + strip Plane: 4.7M

Comparing the new versions with the original via the PSNR metric (closer to 1 is better [more similar]):

- Original PNG vs Original PNG: 1 (obviously)

- Original PNG vs 95% JPG: 0.999465

- Original PNG vs 80% JPG: 0.998611

With other (shorter) words: There is no difference for the consumer (a website visitor) between the two, except one uses more resources (RAM + network) and takes longer to download and the other one doesn't.

For the archiver (which you seem to consider more than the website user) there is clearly a difference between lossless and lossy files. But those can be linked instead of rendered directly inline.

Are you using an iPhone by chance? I think that Safari on iOS does this automatically without any additional involvement on the part of the site itself.

Firefox for Android seems to do this.

Not sure why he decided to use all ~20MB PNG images... Guess not a webdev

Interestingly, everything was fast for me. Say thanks to gigabit internet!

It's almost like they are trying to overflow some buffer somewhere :)

I mean that's what you get for using PNGs for pictures.

It's not the format but the image size. For example:

https://l3ouu4n9.github.io/2021/note/BHUSA/1.png - 37 megapixel - 50MB.

The irony of it is that the image isn't all that sharp either. There are many pixels, but not enough detail in the actual image to warrant that many pixels IMO.

This image could have been scaled down from it's current dimensions of 9894x3786 down to say 1920x210, and it would still probably contain basically the same amount of information really.

Since the website sets the images to have a max width of 720 pixels, it should really just be that instead too :)

...even as a jpg :)

Are we sure it’s just PNGs? I mean, it’s BH..

Reply on news.ycombinator.com