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.

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?

> From time to time I've run an analysis on the use of alternative image formats on the web and it never comes out to be worth it.

I just checked the Google homepage, and even the New Year's Eve Google Doodle currently being shown is a good ol' GIF, rather than a modern format such as WebP. And this is with me using a desktop Chrome browser that definitively supports WebP.

> Like many things, the costs of switching image formats are definite, but the benefits are questionable.

One easy way to get some of the benefits without incurring the switching costs is to leverage Cloudflare Polish[1]. I've used it at a few places, and have had good experiences. Although the majority of gains came from optimizing images that were poorly optimized to begin with, rather than the incremental improvements that occurred from enabling WebP support.

[1] https://support.cloudflare.com/hc/en-us/articles/36000060737...

> I just checked the Google homepage, and even the New Year's Eve Google Doodle currently being shown is a good ol' GIF, rather than a modern format such as WebP. And this is with me using a desktop Chrome browser that definitively supports WebP.

new-years-eve-2018-4995722058399744.2-law.gif

299 972 bytes

new-years-eve-2018-4995722058399744.2-law.webp

293 636 bytes

new-years-eve-2018-4995722058399744.2-law.apng

251 516 bytes

Interesting...

Meanwhile using ffmpeg's default settings it's 63k as h.264 and 45k as h.265.

Starting a video in most browsers is pretty expensive (it usually loads up various GPU features for hardware video decoding).

On some old and buggy machines, that might cause the browser to crash too.

Not something Google wants to risk for a doodle - that's why all non-trivial doodles require a click to load.

> Starting a video in most browsers is pretty expensive (it usually loads up various GPU features for hardware video decoding).

OTOH it might be cheaper (relatively) on phones as they can offload the work to hardware components and ramp CPU down (or avoid ramping it up).

But that is lossy compression.

It doesn't matter. It will look the same.

chroma subsampling, shallow gradients, ringing, the lack of transparency are all quite visible issues when trying to encode cartoons, pixel graphics or screen captures with the standard profiles of lossy video codecs.

I used gif2webp -q 100 -m 6 -mt "new-years-eve-2018-4995722058399744.2-law.gif" -o out.webp

with the resulting out.webp being 285 932 bytes, so it seems apng does a very good job here, unless I'm using suboptimal options for webp.

I don't like WebP because it's either it or HW accelerated browsing - latter I like a tad more because it saves me a bit of battery juice on my laptop.

HEIF (based on HEVC and support on MacOS/iOS + Android + Windows) is already way better than JPEG. It also provides HW acceleration.

HEIF is made by MPEG. HEIG is extensible (see AVIF fusing the AV1 royalty-free codec). Also an application format (MIAF) will ensure interoperability.

While waiting for native browser support, some js implementation would do the job.

What else?

Isn't it a patented algorithm? So it is practically useless.

I agree with you but hey JPEG also had its own patent issues (https://en.wikipedia.org/wiki/JPEG#Patent_issues).

> HEIF (based on HEVC and support on MacOS/iOS + Android + Windows) is already way better than JPEG. It also provides HW acceleration.

Formats do not provide HW acceleration, implementations do. And so far there is zero HW accelerated HEIF implementations for the web.

> And so far there is zero HW accelerated HEIF implementations for the web.

You sure of that? Apple[1] and Qualcomm[2] might argue otherwise.

[1] https://developer.apple.com/videos/play/wwdc2017/513/

[2] https://techreport.com/news/34306/qualcomm-snapdragon-855-sp...

I don't know who downvoted you but you're correct. The point is that most devices embed an HEVC hardware decoder.

There's the same problem with Google insisting on VP8/9 for YouTube in Chrome. If your Mac only supports h.264 in hardware you'll get better battery life in Safari.

They also try it in Firefox but fortunately you can disable webm/webp in about:config and get better battery life and image quality.

There's a Chrome extension that forces YouTube to stream h.264

https://chrome.google.com/webstore/detail/h264ify/aleakchihd...

Obviously it is a problem with Apple, not Google. People should just push it more to do the job.

I don't think Google are free of responsibility. They are prioritising their lower bandwidth over the user's better power usage.

Apple has a bigger share of the blame. They purposely ignore any codec that is outside of their favorites, even if the hardware they ship does support it (i.e. Intel) or doesn't need any hardware support (Vorbis, Flac). On the other hand, they are quick to support any codec, that is problematic to implement elsewhere.

I work with video codecs a lot; to me the blocking on the AV1 picture looks like chroma subsampling rather than a compression artifact. It's much more noticeable on red than in other colors. Unfortunately, at least as of last time I checked, the AV1 still image converters were mostly only 4:2:0 and it's quite noticeable on some images. But this should go away entirely once they're used without subsampling. In other words: don't use that part of the picture to judge the quality of AV1.

It's definitely chroma upsampling artifacts. This is a problem with the decoder, not the encoder. The chroma channels are upscaled with nearest-neighbor filtering. I resampled them in ImageMagick with a Mitchell-Netravali cubic filter, which is reasonably cheap to calculate, and it looks much better:

  $ convert 400px-President_Barack_Obama.jpg.av1.mkv.png -colorspace YUV -channel 0 -separate Y.png
  $ convert 400px-President_Barack_Obama.jpg.av1.mkv.png -colorspace YUV -channel 1 -separate U.png
  $ convert 400px-President_Barack_Obama.jpg.av1.mkv.png -colorspace YUV -channel 2 -separate V.png
  $ convert U.png -filter point -resize 50% -filter Mitchell -resize 200% smoothed_U.png
  $ convert V.png -filter point -resize 50% -filter Mitchell -resize 200% smoothed_V.png
  $ convert Y.png smoothed_U.png smoothed_V.png -combine -set colorspace YUV -colorspace sRGB combined.png

Result: https://imgur.com/a/AwoVmh1

> New formats are not supported on all browsers so you wind up having to support the mainstream formats as well as one or more new formats. Rather than benefiting from reduced storage costs, your storage costs get multiplied.

There's a big thing that bugs me about that when it comes to the web: Software patents and licenses basically ruined wavelet-based image compression schemes on the web.

Wavelets would have been ideal. Basically, the lossy compression would work about the same as the cosine transform in JPEG, but by using the discrete wavelet transform, you basically get thumbnailing built in: Imagine transmitting a tiny little thumbnail of your image. Then, you transmit the information used to derive a version 4x that size (2x width, 2x height) from that. Then, you transmit the data used to derive the next 4x layer. Rinse, repeat -- that's exactly how image data is organized after a wavelet transform.

With some clever adaptions, this could have done away with so much cruft and complexity we have today (like image sets and @media queries for background images): Imagine just putting a 4K version of your background on the server and telling the browser how to render it (an <img> tag with a specified size, or background-size in css). The browser could then start loading the image until it realizes it has all the data for your resolution (say on your phone), and just terminate the transmission before the whole image is downloaded.

JPEG 2000 uses wavelet, and a few other I can't remember their names, none of them has better image / pref than the best ones on the market or soon to be released image format based on X Codec. So in reality much like Wavelet in video, it hasn't worked out well at all in real world implementation.

For a site with limited assets, people care more about bandwidth costs than storage costs and ideally your webserver can automatically transcode and serve the best format based on content negotiation.

Except for JPEG2000, which Safari supports but does not include in its Accepts: header. So Akamai just sniffs the user-agent and serves JPEG2000 to anything that looks like Safari, whether they support it or not.

Uuh, i thought the whole point of a static server was to not need an application that needs to prepare the content? It's supposed to be a dumb web server that accesses a folder structure or similar storage backed...

Is that the point, though? I think the point is more that you tell the webserver "here is some content, I want you to serve it in the best way possible" and it figures out how to do it without any special configuration. In the same way I'd expect a "dumb" webserver to be able to negotiate gzip compression without having to point it at a directory of gzipped files.

Edit: I agree that something like the pagespeed module rewriting html probably goes too far and html rewriting is fraught with weird edge cases, but content negotiation is something only a webserver (or CDN) can do.

A directory of gzipped files is often incredibly useful, I've managed to reduce both latency and time it takes to load pages by just precompressing resources. It's more than incredibly useful on low-powered hardware like Raspberry Pis, some applications can be made to load in 3 seconds instead of 10.

That’s somewhat surprising that it makes that much of a difference, a Raspberry Pi 2 can gzip compress at around 20MB/s. Maybe there’s some inefficiencies in the webserver implementation, or just really big files?

If you only compress, then maybe, but if you have more than just nginx running on the Pi it really helps.

This is best done at the edge/CDN layer now. Many of them support real-time optimization (along with resizing, etc) to send the best version to the client that's requesting it. Also recommend Cloudinary and Filestack for a completely managed assets system.

> For instance, one I read a comment on the article here https://calendar.perfplanet.com/2018/is-avif-the-future-of-i....

Jpeg was released the MPEG-1 ( H.261 ) era. Since then we have had H.262 / MPEG2, H.263 / Divx, H.264 /AVC, H.265 / HEVC, and the coming H.266 / VVC. If we consider the amount of improvement we got from Video Encoding, images hasn't changed much at all, we happen to fine tune the heck out of Jpeg. And I hardly call a new image format with 50% reduction bitrate compared to a nearly 30 years old tech a major breakthrough, and that is without mentioning the huge decoding resources requirement.

There are many project that just improves on JPEG, Dropbox had a lossless compressor for JPEG, and Cant remember if Pik was originally based on jpeg as well.

Unless there is a real major breakthrough that gives the current best JPG encoder quality at 25% or less its size, focusing on 200KB, 100KB, 50KB images size, ( i.e the new image will have to be 50KB, 25KB, 12.5KB ) while using within 2x decoding power. I am convinced our roadmap for Network bandwidth improvement in the next 3 - 5 years are going to make JPEG to last forever.

This. The FLIF format still has a nice TODO list which containt: native browser support..