De Zopfli à Brotli : Google compresse un peu plus le Web

Pour nommer leurs algorithmes de compression, les équipes de Google font dans la viennoiserie suisse.

En 2013, elles avaient lancé Zopfli, ainsi baptisé en référence au « Hefezopf », un pain tressé au beurre traditionnellement consommé le dimanche matin.

Elles travaillent aujourd’hui sur Brotli, qui trouve son origine dans le « Spanisch Brötli », une pâtisserie feuilletée de forme carrée.

Basée sur une version modifiée de LZ77 associée au codage de Huffman et à un modelage du contexte de second ordre (plus d’informations techniques ici), cette bibliothèque libre à source ouverte a fait l’objet d’un brouillon de normalisation déposé à l’Internet Engineering Task Force.

Sa prise en charge pourrait être assurée dans la prochaine version stable de Chrome. Il est déjà possible de l’expérimenter sur le canal alpha (Canary), via la commande chrome://flags#enable-brotli. Notamment en se rendant sur le blog du fournisseur de CDN CloudFlare, hébergé sur un serveur HTTP2 expérimental.

Non compatible avec l’algorithme deflate exploité par Zopfli, le format de données que gère Brotli est également testé depuis plusieurs mois au sein de la norme Web Open Font Format 2 (WOFF 2.0). Il a permis, en moyenne, de diminuer de 25 % la bande passante utilisée pour le chargement des polices de caractères.

Car c’est bien là le principal objectif : faire en sorte que l’affichage des pages Web consomment moins de ressources. Côté utilisateur, cela veut dire une navigation plus rapide… et une aubaine pour les mobinautes dont l’enveloppe data est limitée.

Google avait fourni un premier aperçu de Brotli en septembre dernier.

Au moyen d’une étude comparative (document PDF, 6 pages), le groupe Internet avait annoncé un gain en performance de compression de l’ordre de 20 à 26 % par rapport à Zopfli (17 % sur des contenus JavaScript ; 20 % sur du CSS ; 25 % sur du HTML).

Il est question d’une vitesse de décompression comparable à celle de l’algorithme deflate, pour un taux de compression proche de celui offert par LZMA (1:11, contre 1:9 pour gzip).

Côté serveur, en revanche, le temps nécessaire pour compresser un fichier explose. On appliquera préférentiellement Brotli aux pages statiques, l’utilisation sur des contenus dynamiques risquant de se révéler contreproductive, à moins d’introduire un compresseur multicœur.

Crédit photo : arka38 – Shutterstock.com