5 ms·

In terms of compression, AV1 is a clear win. Note that artifacts that bother you are at about half the file size. You can increase the quality and still have an

by pornel 8y ago

In terms of compression, AV1 is a clear win. Note that artifacts that bother you are at about half the file size. You can increase the quality and still have an image that is both nicer and smaller than JPEG and WebP. However, as TFA mentions, better compression is currently a double-edged sword, because the CPU has become a bottleneck again: even top-of-the-line Android phones have weak Qualcomm CPUs, and sites use so much JavaScript that even high-end machines can struggle. So we may end up living with JPEG for a few more years. This format has been designed when CPUs had 25Mhz, and we've had over 25 years to optimize the implementations, so we get a lot of bang for the buck from it.

m-p-3 8y ago
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.
- vanderZwan 8y ago
  > 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.
  - jrockway 8y ago
    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.
    - vanderZwan 8y ago
      Are you seriously suggesting that image resizing to match expected output size is an unsolved problem?
      - robin_reala 8y ago
        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.
    - mbell 8y ago
      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/metalabdesign/sharp-loader https://github.com/herrstucki/responsive-loader https://github.com/herrstucki/responsive-loader https://github.com/tcoopman/image-webpack-loader https://github.com/tcoopman/image-webpack-loader (and many more, just grabbing a few examples)
      - JimDabell 8y ago
        Webpack also warns you about large assets by default, although the limit is 250KB, which isn't great.
    - idle_zealot 8y ago
      https://github.com/tcoopman/image-webpack-loader 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>
  - lucb1e 8y ago
    > 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.
    - dempseye 8y ago
      You still have to download it all, though. Right?
      - ben_w 8y ago
        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
      - lucb1e 8y ago
        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.
- 75dvtwin 8y ago
  do you have by any chance, some numbers of the website size (js + images) that make it slow on Kobo?

by pornel 8y ago

m-p-3 8y ago

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.

vanderZwan 8y ago
> 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.
- jrockway 8y ago
  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.
  - vanderZwan 8y ago
    Are you seriously suggesting that image resizing to match expected output size is an unsolved problem?
    - robin_reala 8y ago
      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.
  - mbell 8y ago
    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/metalabdesign/sharp-loader https://github.com/herrstucki/responsive-loader https://github.com/herrstucki/responsive-loader https://github.com/tcoopman/image-webpack-loader https://github.com/tcoopman/image-webpack-loader (and many more, just grabbing a few examples)
    - JimDabell 8y ago
      Webpack also warns you about large assets by default, although the limit is 250KB, which isn't great.
  - idle_zealot 8y ago
    https://github.com/tcoopman/image-webpack-loader 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>
- lucb1e 8y ago
  > 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.
  - dempseye 8y ago
    You still have to download it all, though. Right?
    - ben_w 8y ago
      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
    - lucb1e 8y ago
      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.
75dvtwin 8y ago
do you have by any chance, some numbers of the website size (js + images) that make it slow on Kobo?