Google publie en open source Zopfli

Google publie en open source Zopfli
un algorithme de compression pour le Web plus performant

Google vient de publier en open source le code d’un nouvel algorithme de compression.

Baptisé Zopfli, le nouveau programme de compression de Google offre un taux de compression jamais atteint, en réduisant la taille des fichiers de l’ordre de 3 à 8 % par rapport à ce que permet d'obtenir la compression maximale de zlib, la référence actuelle pour la compression des fichiers sur le Web.

Zopfli a été mis au point par Lode Vandevenne, ingénieur chez Google, pendant les 20 % de temps libre que Google accorde à chaque employé pour travailler sur des projets secondaires.

Le programme est écrit en C pour la portabilité et repose en grande partie sur l’algorithme de compression deflate. Ce qui suppose qu’il est compatible avec zlib et gzip.

La faiblesse de Zopfli réside au niveau du temps nécessaire pour compresser, qui serait de 81 fois supérieur à celui nécessaire pour effectuer une compression avec gzip. Il est donc recommandé de l’utiliser surtout pour la compression des contenus statiques. Le temps de décompression, par contre, reste similaire ou meilleur que celui des autres programmes.

Lode Vandevenne espère que ce nouvel algorithme open source rendra internet un peu plus rapide. Une taille de compression plus petite permet une meilleure utilisation de l'espace, une transmission des données plus rapide et des temps de chargement des pages Web plus rapides.


:fleche: Télécharger le code source de Zopfli

:fleche: Télécharger le PDF décrivant l'algorithme

Source : Blogs Google


Et vous ?

:fleche: Que pensez-vous de ce nouvel algorithme de compression ? Allez-vous l'adopter ?

L'application de ce nouveau programme ne procure qu'une compression à peine améliorée (fichier résultant à peine moins grand qu'avec les outils "classiques"), ceci au prix d'une performance en compression hyper dégradée.

Donc, pas d'avenir pour mon utilisation propre.

Toutefois, quand on raisonne au niveau du réseau internet, l'amélioration de 5% de la bande passante en utilisant un nouvel algo de compression, ça a un sens à condition que :
- les navigateurs acceptent ce nouveau format de compression
- les serveurs mettent en place des techniques de pre-compression pour les pages HTML fixes (pour les pages variables, je crains que les temps de compression soient rhédibitoires).

Les pages html fixe, il n'y en a pas beaucoup mais pour les images et librairies javascript il y a un potentiel... surtout pour les relativement gros site qui prennent le temps de l'optimisé. Si cela se généralise à des outils plus standar comme "tar" sous Linux ou Winzip sous Windows alors je pense qu'il sera utilisé notamment pour joindre plus dans les email sachant que le temps de compression n'est pas trop gênant.

De 3 à 8% sur l'ensemble du traffic mondial, ce serait énorme et que le début :ccool:

Ok....

Et côté CPU et RAM, quel est le niveau d'utilisation comparé à un gzip ?

En première approche, je ne pense pas que la notion de ressource cpu se pose, car au décodage cela apparait presque équivalent au gzip. C'est effectivement à l'encodage que se situe le goulot d'étranglement, donc réservé aux pages statiques.

Après, cela fait partie de ces petits gestes "écologiques". Faire le geste initial coûte finalement peu, mais les répercussions démultipliées par le nombre de ceux qui le font peut être bénéfique sur la saturation des réseaux (<mode à-peine-troll on> et si on se préoccupait d'abord des spammeurs institutionnels ?" <mode à-peine-troll off>).

Perso, je pense un peu écolo, donc autant faire l'effort s'il s'agit d'échanges (et non pas seulement de stockage perso). Mais effectivement, quid des navigateurs ? Ce sont eux qui, à mon avis, vont pour une large part pour de faciliter l'adoption.

Citation:

---

hotcryx : De 3 à 8% sur l'ensemble du traffic mondial,

---

Pourcentages à corriger en 1 à 2% :
Plus de 75% du traffic actuel est constitué d'images, de sons ou de Vidéo (déjà compressés en JPEG, MP3/4, MPEG, ...) auxquels les algorithmes de type Gzip ou Zopfli ne s'appliquent pas.

Le jpeg 2000 permettrai de faire beaucoup mieux pour les images, enfin quand ne sera plus sous un brevet. http://fr.wikibooks.org/wiki/Le_format_JPEG_2000

Citation:

---

Une taille de compression plus petite permet une meilleure utilisation de l'espace, une transmission des données plus rapide et des temps de chargement des pages Web plus rapides.

---

S'il s'agit de réduire les volumes de données, la première étape consiste a retirer tout ce qui n'est pas utile dans les pages webs (images, scripts, flash). Avec HTML5, j'espère qu'on ne sera plus obligé de télécharger des images pour avoir des jolis boutons/décorations.

Ensuite, faire en sorte que toutes les données soient téléchargées en une fois. Aujourd'hui il faut ouvrir des dizaines de connexions pour récupérer tout le contenu d'une page (et souvent sur différents domaines, notamment pour les scripts).

Enfin, faire en sorte que les données soient systématiquement compressées.

Alors seulement, il sera intéressant de gagner 4% sur le taux de compression.

Oui enfin on parle de Google, la. Leur problème principal n'est pas au niveau du client mais bien de leurs serveur. S'ils peuvent réduire un tout petit peu l'espace de stockage nécessaire pour leurs bases de données, ça peut leur faire des belles économies.