Progressive JPEG has ~10 scans by default in libjpeg/mozjpeg. Lossy JPEG XL always allows minimal progression (2 scans, 1:8 followed by 1:1), and uses maybe 3-5

Progressive JPEG has ~10 scans by default in libjpeg/mozjpeg. Lossy JPEG XL always allows minimal progression (2 scans, 1:8 followed by 1:1), and uses maybe 3-5 scans when encoding with more progression. In any case, I think the "costs too much cpu" argument is not really fair, since there is nothing forcing an implementation to do explicit flush/repaint at every scan. In fact, browsers will only do a refresh when cpu is _not_ the bottleneck, but network is. When cpu _is_ the bottleneck (e.g. the file is loaded from local cache), you can just decode the whole file non-progressively and have only a single refresh (just like with inherently non-progressive formats). If network is the bottleneck, then the choice is between cpu time (avoiding progressive previews to save some cpu effort) and human time (show previews so something can be shown earlier). I think human time is more valuable, by a few orders of magnitude.