I hate that most websites are so heavy. I enjoyed browsing on my Kobo eReader but loading times of several seconds to a minutes makes it cumbersome. I limit my browsing to "lite" websites and HN suits that well. I also use the Pocket service because it's builtin and reduce the computational need required to read an article.

> I hate that most websites are so heavy.

Most of which has nothing to do with compression format, to be honest. No image compression format is going to save us from websites that use 2000x2000 sized photos for 200x200 author thumbnails.

As far as I can tell, nobody has ever made it easy to fix this problem. I don't believe there is any webpack (etc.) plugin that will just recompress images for you. You have to do it manually. As a result, people don't do it, even those that have a proper "build process" for their website.

Maybe I should write one, I guess.

This has been a solved problem for years in some frameworks, e.g. all the major image upload handling libraries in Rails have this built in an it's very easy to use. There are also plenty of webpack plugins for static assets:

https://github.com/metalabdesign/sharp-loader

https://github.com/herrstucki/responsive-loader

https://github.com/tcoopman/image-webpack-loader

(and many more, just grabbing a few examples)

Webpack also warns you about large assets by default, although the limit is 250KB, which isn't great.

https://github.com/tcoopman/image-webpack-loader exists. The plugin will recompress png, jpeg, and svg images, as well as optionally converting the first two to webp. That said, it seems to have a persistent bug where jpegs are always converted to webp while retaining their original extention, and the maintainer doesn't seem to have the time to fix it or merge pull requests. If you wanted to help them out with that, they'd likely be amenable.

Something that I've not seen is a plugin/loader that will automatically use the <picture> tag to make available multiple auto-generated source images and a fallback <img>. It'd be great to be able to

import myImage from 'res/img/my_img.png'

and have myImage be a string like

<picture><source srcset="[generated-name-of-my-image.webp]"><img src="generated-name-of-my-image.png"]></picture>

Flif gives you a lower resolution image of you download only part of the file. Keep downloading and the image gets better resolution. If browsers supported it, they could have settings so you download partial images when roaming or the full file when on wifi.

Are you seriously suggesting that image resizing to match expected output size is an unsolved problem?

As per the guidelines:

Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

> No image compression format is going to save us from websites that use 2000x2000 sized photos for 200x200 author thumbnails.

This sounded like an obvious truth but I think you're wrong!

JPEG has progressive rendering, so a browser could easily decide to stop once it has rendered enough for the image size. Once you zoom or if it's used elsewhere, it can render a little more.

You still have to download it all, though. Right?

Technically no, but JPEG divides the image into 8x8 segments (does that vary by channel? Can’t remember) so using full resolution images as thumbnails will still suck everyone’s bandwidth like correctly resized .bmp files

That's the point of progressive rendering, it renders less and less blurry the more the image loads. On slow connections with big images, I've seen the effect in the wild.

do you have by any chance, some numbers of the website size (js + images) that make it slow on Kobo?