I've figured out a way to test this with the latest ffmpeg and libaom, and holy crap the hype is real. When I hit the same DSSIM fidelity for the AV1 "thumbnail" as the JPG and WEBP ones from production, I get the following. Note that the embedded images in this comment are lossless PNG conversions of the actual thumbnails, provided here to eyeball visual differences.

JPG

850 + 538 = 1388 bytes of metadata (JPEG APP1 + JPEG APP2, includes ICC profile)

Total file size: 50702

WEBP

844 + 524 = 1368 bytes of metadata (RIFF ICCP + RIFF EXIF)

Actual bytes of image data: 36426

Total file size: 37848

AV1.MKV

No metadata. The absence of the color profile should be without incidence for the pixels compared via DSSIM, as we're talking about the default TinyRGB profile.

A proper AV1 image container would include both EXIF and color profile. In fact WebP is extensible and could contain AV1-encoded data. Knowing that, I'm going to assume that the real AV1 image would contain the same size of metadata as the webp thumbnail.

Actual bytes of image data: 23796

Approximate total file size of AV1 image if it was stored inside a WebP: 37848 - 36426 + 23796 = 25218

Results

WebP is 25% smaller than JPG (this is the typical kind of ratio we've seen for lossy WebP). AV1 is 33% smaller than WebP and 50% smaller than JPG! This is exactly the figure Kornel Lesiński claimed in his talk at performance.now().

Now time to turn this into a blog post...

Emailed the 2 Google engineers who wrote most of the WebP container spec about the idea of extending WebP to allow AV1 as a codec to encode frames. One of them seems to be working on AV1 anyway. Based on the spec, it seems like a very straightforward thing to do, and Chrome already has AV1 decoding for video.

I might wait for their response before sending the blog post I'm going to write to the perf calendar.

JPEG XL supports mathematically lossless from JPEG convertion and back and also better than AVIF. Soon to be added in Chrome.