327 private links
It can be useful someday
PNG renders top to bottom but the interlaced mode increase significantly the file size. WebP too at 28%.
AVIF has a progressive flag for it. It creates two layers. One at 1/8th resolution and minimum quality and one at full resolution and good quality. The first layer has 5.8kB as example, and the full image is 151kB. It's still experimental with avifenc.
JPEG XL (abbreviated JXL) renders on Chrome at 39% of the file.
The AVIF image provided as example is 56.4kB, which is incredible for a more than HD image.
For many images, there's little benefit to progressive rendering (the fox with many details is an exception). So progressive rendering is often a mix of good and bad luck.
The author claims JXL progressive rendering promises won't work, because there is a significant lag between each of the progressive rendering steps. It can work efficiently with srcset for example.
JXL still looks promising, but the AVIF progressive rendering of the fox is somewhat better than the 17-27kB alternative of JXL.
Note: a post-processed blur on a scaled down image results in 2kB. 10kB makes the image "acceptable" for the human eyes. The image is still pretty good for previews. The post-process blur would need to be part of the format, rather than left to something like CSS to make JXL.
and because it's an entirely separate image, the decoding overhead is zero if the browser doesn't see a benefit to displaying the preview. As in, in cases where the browser has the whole file, it can just skip the preview.
I will have to look after the AVIF format, because it seems to be the best of Webp (20-30% better compression), GIF (with animation) and better image quality than JPEG.
See the german wikipedia page or the english one
An argumentation against Xz. For later in case I will come up to the topic.
tl;dr: the issue isn’t the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.
The experience shows that atomic css files is not optimal.
If the files I was importing were larger, it might make sense. As tiny, modular files? Not so much!
The complete library concatenated and gzipped is less than a single HTTP request. It’s just over 25-percent of the transfer size of sending modular gzipped files instead.
La compression optimale avec 7-zip: 7zz a -snl -t7z -m0=lzma2 -mx=9 -myx=9 -mfb=257 -md=1024m -ms=on -mmt=off archive.7z répertoire
Source code: https://github.com/mmmmaharshi/image-compressor
O_O it performs better than xz
En résumé: 7-zip avec le format d'archive 7z :)
Dernière modif à la lecture de la page: mars 2023.
Pour vos photos:
- limitez les dimensions, un maximum de 2 000 x 2 000 pixels est largement suffisant;
- utilisez le format JPEG (ou AVIF si vous voulez promouvoir le format du futur);
- réglez la qualité à 75 ou moins (35 dans le cas du format AVIF).
Pour des images non-photoréalistes:
- en général vous pouvez réduire encore plus les dimensions que pour les photos;
- utilisez le format PNG.
Je vais jeter un coup d'oeil au format AVIF :)
Le post décrit ensuite certaines définitions, et comment compresser manuellemenet
The files can be put in a directory (automatically created) with the -e option. So we don't need specific commands (tar, zip, 7z, ...) anymore?
An image compression library in javascript based on the Squoosh tool