Safari 18 et l’abandon du JPEG2000

Il y a quelques années maintenant (ça date de Safari 12), je parlais de Safari et du fait que certains sites envoyaient du JPEG2000 plutôt que du JPEG pour économiser la bande passante. Avec l’abandon annoncé du codec de compression dans Safari 18, je me suis posé une question : est-ce un problème ?

Petite résumé : en 2019, donc, les CDN – des services de mise en cache pour les gros sites, en résumé – détectaient Safari et envoyaient dans certains cas du JPEG2000 plutôt que du JPEG. A l’époque, ça posait un souci : Epiphany (basé sur WebKit) recevait aussi du JPEG2000 mais le navigateur ne pouvait pas l’afficher sous GNU/Linux. Pour rappel, le JPEG2000 est un codec de compression pour les images qui offre une meilleure qualité que le JPEG tout en réduisant la taille (en octets). Mais le JPEG2000 reste rare parce qu’il demande de gros calculs.

Safari 18, donc, abandonne le JPEG2000. Mais dans les faits, les CDN aussi, visiblement. Je suis parti sur des sites que j’avais testé à l’époque (Ikea, Dell, la Deutsche Bahn) pour vérifier le comportement. En 2019, ils servaient du JPEG2000 à Safari, donc j’ai sorti un Mac sous macOS Mojave… et j’ai reçu du JPEG classique, sans optimisations particulières. Avec mon Mac récent et Safari 17, je reçois de l’AVIF, le format d’image dérivé de l’AV1.

C’est probablement plus simple, même sans accélération vidéo, et c’est efficace. Chez Ikea, on passe de 50 et 36 ko à 27 et 23 ko sur mes essais, avec en plus des images plus grandes (probablement parce que je suis en Retina). Idem à la Deutsche Bahn, de 75 à 35 ko. Il n’y a que chez Dell ou l’ancien système reçoit une image plus lourde (91 ko contre 102 ko) mais pour une raison simple : la version Retina est plus grande.

Deux versions

Je peux donc supposer que l’abandon du JPEG2000 ne devrait pas trop se voir, étant donné qu’en dehors du cas particulier des serveurs de cache, le codec est très rarement employé.