Notes de l'équipe sur l'artisanat, les formats et les petites décisions derrière un bon recadrage rond.
L'architecture à deux voies expliquée
L'aperçu du curseur et l'encodage du téléchargement sont deux chemins de code distincts. L'aperçu utilise l'API canvas.toBlob native du navigateur, qui s'exécute de manière synchrone sur le thread du compositeur GPU. Chaque déplacement du curseur déclenche un nouvel appel canvas.toBlob avec la nouvelle valeur de qualité, et le résultat est dessiné dans un canvas en vue partagée. C'est entièrement local, vous pouvez le vérifier en ouvrant DevTools, l'onglet Réseau, en filtrant sur compress, et en observant que zéro requête n'apparaît pendant l'interaction avec le curseur. Le bouton Télécharger déclenche un chemin de code entièrement différent. Il envoie le fichier original non modifié à notre Cloudflare Worker sur /api/compress, qui fait suivre vers un serveur Fastify exécutant Node 24 et le paquet sharp (licence Apache 2.0) appuyé sur libvips 8.x (LGPL-3.0). Le résultat encodé revient dans le corps de la réponse et est enregistré dans le dossier de téléchargement du navigateur. Deux chemins, un seul outil.
Pourquoi l'encodage serveur bat l'encodage navigateur
L'encodeur JPEG du navigateur utilise libjpeg ou une implémentation spécifique au navigateur qui manque le réglage des tables de sous-échantillonnage chroma de MozJPEG. MozJPEG, le codec invoqué par libvips pour le JPEG, a été développé chez Mozilla en 2014 comme remplaçant direct de libjpeg-turbo, avec un objectif de fichiers plus légers à qualité perceptuelle équivalente. Sur des benchmarks menés sur 50 photos variées (faune, portraits, photos produit, captures d'écran), l'encodage libvips et MozJPEG à qualité 78 a produit des fichiers 10 à 20 pour cent plus légers que canvas.toBlob de Chrome à la même valeur de qualité. Pour PNG, l'écart est plus grand, le navigateur utilise zlib avec une compression par défaut, tandis que pnpngquant réduit la palette de couleurs au minimum nécessaire, ce qui diminue typiquement les fichiers PNG non optimisés de 30 à 70 pour cent.
AVIF, ce que c'est et quand l'utiliser
AVIF s'appuie sur la prédiction intra-image du codec vidéo AV1, développé par l'Alliance for Open Media. Il atteint une meilleure efficacité de compression que JPEG en prédisant les valeurs de pixels sur de plus grandes régions et en représentant le résidu de manière plus compacte. Le résultat concret est que des fichiers AVIF à qualité 60 sont souvent visuellement indiscernables de fichiers JPEG à qualité 80, tout en étant 40 à 60 pour cent plus légers. Le compromis se trouve dans le temps d'encodage, sur notre serveur, une photo de 8 Mpx à qualité 60 prend 3 à 8 secondes avec libaom-av1. La prise en charge navigateur est solide en 2026 (Chrome, Firefox, Safari, Edge décodent tous l'AVIF). L'outil affiche le compteur d'octets AVIF en temps réel aux côtés de JPG et WebP, vous pouvez donc décider si l'économie de taille justifie la légère attente d'encodage pour votre flux de travail.
Les réglages de qualité en pratique
Le curseur correspond directement au paramètre q de l'encodeur pour les formats avec pertes. À qualité 80, le réglage correspond à ce qu'Adobe Photoshop appelle Élevé lors de l'export JPEG, c'est la valeur utilisée par défaut dans la plupart des flux professionnels. À qualité 60, une photo moyenne de 4 Mpx est compressée à environ 200 à 400 Ko, assez léger pour la majorité des usages e-mail et web, et la perte de détail n'est visible que dans les zones à texture fine en zoom 1:1. En dessous de qualité 50, des artefacts de compression en blocs apparaissent sur les dégradés lisses et les teints de peau, perceptibles même à distance de lecture normale sur un écran retina. En dessous de qualité 30, le résultat reste reconnaissable mais clairement compressé, approprié uniquement pour des miniatures. Le compteur d'octets au-dessus du curseur affiche la taille exacte en Ko pendant que vous faites glisser, ce n'est pas une estimation.
Suppression des métadonnées et pourquoi cela compte
Les deux voies suppriment par défaut les données EXIF, GPS et appareil photo de la sortie. C'est le comportement correct de libvips et sharp dans leur configuration par défaut, et cela a deux effets concrets. Premièrement, cela retire les données de localisation potentiellement sensibles intégrées par les smartphones, ce qui constitue un bénéfice pour la confidentialité des images partagées publiquement. Deuxièmement, cela réduit légèrement la taille du fichier (un bloc EXIF typique pèse 10 à 40 Ko). Le tag d'orientation visuelle est traité séparément, l'outil lit le champ d'orientation EXIF avant la suppression et fait pivoter l'image en amont pour que la sortie soit correctement orientée. Si vous avez besoin de conserver les métadonnées pour des flux d'expertise, d'archivage ou d'impression, vous devriez utiliser un éditeur de métadonnées dédié avant de compresser.
Formats pris en charge, ce qui entre et ce qui sort
L'entrée accepte JPG, PNG, WebP et AVIF sur tout navigateur moderne, validés par signature d'octets magiques plutôt que par l'extension de fichier seule. GIF est accepté sur Chrome et Firefox mais seule la première image est traitée (l'animation n'est pas préservée), les GIF animés ne devraient donc pas être compressés avec cet outil. HEIC depuis l'iPhone fonctionne dans Safari, qui dispose d'un décodeur HEIC natif intégré, mais Chrome et Firefox ne décodent pas HEIC nativement. La sortie peut être JPG, PNG, WebP ou AVIF quel que soit le format d'entrée, vous pouvez donc aussi utiliser cet outil comme un chemin combiné de conversion et de compression. La voie serveur accepte les fichiers jusqu'à 25 Mo. Les fichiers au-delà de cette limite sont traités par l'encodeur de repli du navigateur.
