Performance Calendar

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.

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.

Performance is also a problem, particularly when people add "yet another polyfill" to get an image to work without native support.

Once I get into eyeballing images closely I also end up questioning if the compression gains are real. For instance, one I read a comment on the article here

https://calendar.perfplanet.com/2018/is-avif-the-future-of-images-on-the-web/

and looked closely I couldn't unsee that the AV1 had very different artifacts than the other compressed images. Not necessarily worse, but definitely different. Unlike the poster I liked the way the suit rendered but definitely there was a lot of blocking around edges that the poster interprets as "pixelation on the flag".

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

> 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.

1. The boundaries are currently at event loop. Whenever an event comes in, we dispatch it to React and every time the user calls setState on the component, we mark it as dirty. At the end of that dispatch, we go from top to bottom and re-render elements.

It's possible to change the batching boundaries via "Batching Strategies" but we haven't exposed/documented it properly yet. If you are interested, you can look at requestAnimationFrame batching strategy. https://github.com/petehunt/react-raf-batching

2. We cannot really use normal diff algorithms for list because elements are stateful and there is no good way for React to properly guess identity between old and new. We're pushing this to the developer via the `key` attribute.

See this article I wrote for a high level overview of how the diff algorithm is working: http://calendar.perfplanet.com/2013/diff/

Attempting to lazy load an LCP could delay the loading the image as much as 15% [1].

Lazy-loading is an effective technique we can use to delay non-critical resources at the beginning of the page load. However, a considerable problem occurs when we apply this technique to an LCP image. Lazy-loading prevents the browser from loading the image immediately because it takes time for it to realize that the image is in the viewport and needs to be loaded. According to some lab tests, this could cause a 15% regression in LCP performance. This might sound obvious for someone working on web performance, but the fact that nearly one in five web pages are doing it is a sign that it’s not very well understood by most other web developers.

[1]: https://calendar.perfplanet.com/2022/lazy-loading-lcp-images-why-does-this-anti-pattern-happen/

It's not quite what you described but static asset fingerprinting or asset digest fingerprinting is a good place to start.

In theory, if you're using this behind a cache or CDN, then you've already heavily optimized your server load for serving static assets.

I haven't seen any sort of a diff-based approach to caching in the browser. I don't think there is a notion of cache "layers" for an arbitrary binary file in a browser to easily support this, but that doesn't mean you couldn't build it. Maybe you could use localStorage / sessionStorage here?

Another research term that might be useful is incremental caching.

This seems relatively new but cache digests could also be useful here.

https://calendar.perfplanet.com/2016/cache-digests-http2-server-push/

Criticism of cherry-picking cuts against WebP because the marketing campaign for that codec relied on cherry-picking both the least optimized JPEG codec and the most favorable metrics for comparison. If you had humans comparing images or enabled JPEG optimization you saw far less exciting numbers for WebP - usually under 10% savings, not uncommonly negative – and there were other formats which consistently outperformed it. You can see the mood around that time here:

https://calendar.perfplanet.com/2014/mozjpeg-3-0/

Even a decade later, however, Google repeats the 25-34% claim and their performance tools tell developers they should use a modern format, which by sheer coincidence means the one they invented rather than the best ones on the market.