Compression sans perte : définition, algorithmes, web

Qu'est-ce que la compression sans perte ?

La compression sans perte (lossless) réduit la taille d'un fichier sans éliminer d'information : la décompression redonne exactement les octets d'origine. Elle code plus efficacement les motifs répétés, si bien que le texte, le code, le JSON et le HTML rétrécissent fortement, tandis que des données déjà compressées changent à peine.

L'alternative est la compression avec perte, qui supprime définitivement des détails que l'œil ou l'oreille remarquent peu (JPEG, MP3, la plupart des vidéos). Utilisez la compression sans perte partout où chaque bit compte : code source, exécutables, bases de données, archives, ainsi que le HTML, le CSS, le JavaScript et le JSON que votre serveur envoie.

Comment fonctionne la compression sans perte

Les algorithmes sans perte repèrent la redondance et la suppriment. Deux techniques font l'essentiel du travail :

• Le codage par dictionnaire (famille LZ77) : une chaîne répétée est remplacée par une courte référence à une copie antérieure. gzip, Zstandard et LZ4 en dérivent.
• Le codage entropique (Huffman, codage arithmétique) : les symboles fréquents reçoivent des codes plus courts que les rares. La plupart des compresseurs l'utilisent en dernière passe.

Brotli associe ces idées à une modélisation de contexte et à un dictionnaire intégré. D'après MDN, un texte peut contenir jusqu'à 60 % de redondance, ce qui explique qu'il se compresse si bien.

Les algorithmes sans perte courants

Sans perte ou avec perte

La compression sans perte restitue l'original exact. La compression avec perte restitue une approximation et atteint en général des tailles plus petites. Certains formats, comme WebP, gèrent les deux modes.

La compression sans perte sur le web

La compression HTTP est sans perte. Le navigateur indique dans Accept-Encoding ce qu'il gère, le serveur en choisit un, compresse le corps et l'étiquette dans Content-Encoding. L'en-tête Vary: Accept-Encoding permet aux caches et aux CDN de stocker chaque variante séparément.

GET / HTTP/1.1
Accept-Encoding: br, gzip

HTTP/1.1 200 OK
Content-Encoding: br
Vary: Accept-Encoding
Content-Type: text/html

Les encodages que vous rencontrerez en pratique (voir le guide MDN sur la compression) :

Servez du Brotli quand le client le gère et retombez sur gzip sinon. MDN indique que la compression peut réduire certains documents jusqu'à 70 %, ce qui raccourcit le transfert et peut améliorer des métriques de chargement comme le LCP (voir Core Web Vitals). Pour la configuration côté serveur, lisez activer gzip sur NGINX.

Quel compresseur choisir

• HTML, CSS, JavaScript, JSON via HTTP : Brotli, avec gzip en repli. Pour les fichiers statiques, compressez une fois au build avec un niveau élevé. Pour les réponses dynamiques, prenez un niveau plus bas et plus rapide afin que le temps CPU n'ajoute pas de latence.
• Flux temps réel et données en mémoire : LZ4 ou Snappy, qui sacrifient le taux pour la vitesse.
• Archives de long terme : xz ou Zstandard à un niveau élevé, quand le taux compte plus que la vitesse.
• Logs et nombreuses charges similaires : Zstandard, éventuellement avec un dictionnaire partagé.

Erreurs fréquentes

• Recompresser des fichiers déjà compressés. JPEG, MP4, ZIP et formats similaires ne rétrécissent pas, et la passe supplémentaire consomme du CPU et peut alourdir le fichier.
• Compresser des images avec un algorithme de texte. Servez les images dans un format d'image. Voir taille d'image.
• Oublier Vary: Accept-Encoding. Sans lui, un cache peut renvoyer une réponse compressée à un client qui ne sait pas la lire.
• Utiliser le niveau maximal sur chaque requête. Les derniers pourcents de taille coûtent beaucoup de CPU. Gardez-le pour les fichiers compressés une seule fois.
• Supposer que la compression est active. Un réglage du proxy, du CDN ou de l'origine peut la désactiver sans erreur visible. Vérifiez les en-têtes de réponse.

Vérifier la compression avec LoadFocus

Un serveur mal configuré peut envoyer du JSON non compressé pendant des mois sans que personne ne s'en aperçoive. La surveillance d'API de LoadFocus peut contrôler les en-têtes de réponse en plus du code de statut, du corps et du temps de réponse : un contrôle échoue si Content-Encoding manque, et le temps de réponse est décomposé en attente, DNS, connexion TCP, premier octet (TTFB) et téléchargement. Les contrôles gratuits s'exécutent toutes les 5 minutes. Un test de charge depuis 25 régions donne les percentiles de temps de réponse, la latence et le débit sous charge, et montre si le coût CPU de la compression vous pénalise aux heures de pointe.

Questions fréquentes : compression sans perte

Quel est le meilleur compresseur sans perte ?

Cela dépend de ce que l'on sacrifie. xz atteint un taux élevé mais reste lent, Zstandard équilibre vitesse et taux, LZ4 est le plus rapide et gzip le plus compatible. Pour les réponses web, Brotli avec gzip en repli.

Pourquoi mon fichier ne rétrécit-il pas ?

Il ne contient sans doute plus de redondance. JPEG, MP4, les données chiffrées et les archives déjà compressées ressemblent à du hasard pour un compresseur.

Faut-il compresser le JSON ?

Oui. Le JSON répète beaucoup les noms de clés et se compresse donc en général bien. Activez gzip ou Brotli sur les réponses de votre API et vérifiez dans les en-têtes.

PNG est-il sans perte ?

Oui. PNG et GIF sont sans perte, JPEG est avec perte et WebP peut être l'un ou l'autre. Prenez PNG pour les captures et les logos, JPEG ou WebP pour les photos.

Brotli est-il meilleur que gzip ?

Pour du texte via HTTP, en général oui : son README le décrit comme aussi rapide que deflate mais plus dense. La prise en charge est large, servez donc du Brotli et gardez gzip en repli.

Faut-il compresser avant de chiffrer ?

Si vous chiffrez vous-même des fichiers, oui, car une sortie chiffrée ressemble à du hasard et ne se compresse pas. La compression HTTP s'applique à la réponse avant que TLS la chiffre.