L’expérience

Batiste Bieler a visiblement eu le même doute l’année dernière que moi et publie des tests réalisés sur Jquery. Après passage par mod_deflate le packer permet tout de même d’économiser presque 45% des 20ko de javascript. Ce n’est pas négligeable et on a naturellement tendance à foncer tête baissée. Le hic c’est que sur sa configuration ça multiplie par deux le temps total de gestion (téléchargement plus exécution) pour javascript. Julien Lecomte relève lui près de 200ms de délai à cause du travail supplémentaire côté client. 

Bref, tout ça n’est pas négligeable. Ce sera toujours un compromis entre le gain en bande passante et la perte en temps processeur, donc une machine très puissante avec une très mauvaise connectivité réseau aura potentiellement intérêt à utiliser le packer, mais Batiste a tout de même utilisé un code duo à 1.66Ghz par coeur et je doute que le portable ayant servi à Julien Lecomte soit obsolète au niveau des performances. Bref, sauf dans des conditions spécifiques, n’utilisez pas le packer/base62 pour des fichiers javascript compressés par mod_deflate ou mod_gzip.                         

John Resig en parlait aussi en février avec un mot d’ordre explicite :

La prochaine que vous choisisser une méthode de compression, rappelez-vous de cette formule : Performance_Total = Temps_de_Téléchargement + Temps_d_Exécution 

L’influence de gzip

En fait quand on regarde actuellement le site de Jquery c’est un peu plus clair. On vous propose une version décompressée pour les tests, une version minifiée et gzipée pour la production, et une version qui utilise le packer de Dean Edwards « pour ceux qui ne peuvent pas gziper leur javascript ». Au moins c’est clair.

Si on garde en tête les chiffres de Batiste on confirme cette idée : sans gzip 60ko de javascript sont transformés en 20ko compressés. Les différences sont alors plus importantes, l’impact sur le réseau est plus fort et le packer reprend de son intérêt. La question sera alors de savoir si vos visiteurs ont des machines puissantes ou pas. On choisira le packer de Dean dans le premier cas, et un procédé de minification plus classique dans le second cas. C’est d’ailleurs la recommandation de Dean Edwards lui-même : il ne destine pas son outil à tous les usages.

Trop gros

Une part importantes des téléchargements sont réalisés sur de simples fichiers textes : HTML, javascript, CSS, XML et JSON. Mis côte à côte ils peuvent représenter un poids non négligeable. C’est particulièrement vrai avec les bibliothèques javascript récentes. On dépasse alors les 50 ko pour la base, et plus si on ajoute les composants optionnels.

Un site classique avec Jquery c’est 25 ko pour le HTML, 10 ko pour les feuilles de style, 100 ko pour la bibliothèque javascript et encore bien 10 ko pour les fichiers javascript qui utilisent cette bibliothèque. La minification nous fait tomber respectivement à 15, 7, 50 et 6 ko, mais le total reste encore proche des 80 ko.

Compresser avant envoi

Tout est prévu, et il est possible de compresser nos fichiers avant de les envoyer, puis de les faire décompresser avant affichage par le navigateur. Cette fonctionnalité est gérée par une écrasante majorité des serveurs web et quasiment tous les navigateurs depuis Microsoft Internet Explorer 4.

Lors de la transmission, c’est un fichier texte compressé qui est échangé. On peut compter que le poids est facilement divisé par deux sur un fichier qui a été minimisé au préalable mais ça peut aller jusqu’à un dixième du poids d’origine. 40 ko d’épargné, ce n’est pas la réussite de l’année mais ça reste appréciable.

Auto-négociation

Tout ça se base sur l’auto-négociation HTTP. Votre navigateur déclare qu’il sait gérer la compression avec une entête Accept-encoding: gzip. Le serveur la détecte, compresse son fichier HTML, et le renvoie avec une entête Content-Encoding: gzip. Tout est transparent pour l’utilisateur ou le navigateur. Si votre navigateur ne supporte pas la fonctionnalité, il n’enverra pas l’entête et recevra le contenu sans compression.

Pour les proxy les plus simples, ceux qui ne (dé)compressent pas les contenus en temps réel, le serveur ajoute une entête Vary: Accept-encoding. Le cache de ce contenu ne sera partagé que entre les navigateurs qui envoient la même entête Accept-encoding (c’est à dire quasiment tous).

L’auto-négociation fait très bien son travail. Il ne vous reste plus qu’à exclure les rares vieux navigateurs qui déclarent supporter la compression mais ont quelques bugs gênants. Si vous détectez ces navigateurs avec un support cassé vous pouvez ajouter Vary: Accept-encoding, User-Agent. 

Quels fichiers

On compresse ainsi tout ce qui est fichier texte. On évite les images non vectorielles, qui sont en général déjà compressées avec des algorithmes spécifiques, ainsi que les fichiers binaires,  certains comme les fichiers OpenOffice sont déjà le résultat d’une compression et les autres ont trop souvent un taux de compression assez faible.

Un tri très rapide peut être fait à partir des types mime des fichiers : on compresse tout ce qui est en text/* et on laisse le reste tel quel, en particulier les images. Si vous voulez faire de la gestion fine vous pouvez aussi compresser les fichiers Microsoft Office .doc, .ppt et .xls (qui se compressent très bien).

Quel format et quel module

Il y a deux formats de compressions pour HTTP, tous deux supportés correctement : gzip (RFC 1951 et 1952), deflate (RFC 1951 et 1950) et compress. Ce dernier est pour ainsi dire inutilisé dans les échanges Web. Les deux autres sont à peu près équivalents. Pour être précis gzip est simplement du deflate avec quelques meta-données.

Pour le serveur web Apache, cela se traduit dans deux modules : mod_gzip et mod_deflate. Le premier est habituel sous Apache 1.3, le second par défaut est fourni avec Apache 2.0. Les performances sont similaires, même si l’algorithme utilisée par mod_gzip donne des fichiers légèrement plus petits (mod_deflate utilise la bibliothèque système zlib alors que mod_gzip utilise son propre code). La différence entre les deux se joue plutôt sur les fonctionnalités des implémentations des deux modules. Mod_gzip propose en effet quelques possibilités en plus.

Pour IIS j’ai vu passer des liens vers zipenable et httpZip mais il semble qu’un support soit inclus par défaut. PHP a aussi la directive de configuration zlib.output_compression pour compresser son résultat avant l’envoi au navigateur, mais il est probablement plus cohérent de passer par le serveur web pour gérer de genre de questions.

Les performances

Pour le client c’est entre 50 et 90% du traffic réseau sur les fichiers textes et Microsoft Office qui est épargné. Tout cela n’est bien entendu pas neutre pour le serveur. On parle souvent de 5% d’occupation processeur pour compresser les contenus. Donner un chiffre est hasardeux car cela dépend trop du serveur, du matériel, des fichiers à compresser et de la charge cpu.

Il est pourtant possible de dire que la charge supplémentaire ne sera pas très importante en regard du gain réseau. C’est d’autant que le traffic réseau est cher, la puissance processeur ne l’est plus tant que ça. Si vous vous contentez des fichiers textes et fichiers Microsoft Office, que vous ne lancez pas de compression pour des fichiers trop petits (1ko) ou (pour mod_gzip) des fichiers trop gros, vous avez peu de chance de faire des contre-performances.

La configuration et les options

Pour vous aider sur mod_gzip et mod_deflate vous avez la possibilité de préciser un niveau de compression avec neuf valeurs prédéfinies de 1 une compression minimum à 9 pour une compression maximum. Il est souvent conseillé de se fixer entre 4 et 6. Monter à 9 occupe beaucoup le processeur pour une différence de taille minime. Aux valeurs les plus faibles votre serveur n’est quasiment pas occupé mais le gain de taille est déjà visible.

Pour ceux qui ont le plus gros traffic d’autres stratégies sont possibles. Les fichiers compressés peuvent être stockés sur le disque pour éviter d’être recalculés à chaque accès par exemple. Il est même possible de pré-compresser les fichiers et opérer à l’inverse : faire faire décompresser les fichiers au serveur pour les quelques rares navigateurs qui ne savent pas gérer la compression.

Et vous ?

Un doute sur votre serveur ? deux pages en ligne vous permet de tester votre site : le mod_gzip_test et le gzip_test. Faites bien attentions aux résultats de Firebug qui peuvent être modifiés par votre proxy, votre anti-virus, vos anti-spyware, vos pare-feux, vos extensions et les outils de protection de la vie privée que vous pourriez avoir : tout ça peut intervenir avant Firebug et décompresser le flux pour le filtrer avant de le renvoyer.

Vous avez aussi compression test et bandwith calc de port80. Le premier télécharge une page et calcule le gain que vous auriez si le contenu était compressé. Avec cette mesure, le second outil vous permet de calculer les économies sur la facture réseau. C’est là que vous verrez vite si échanger du réseau contre du processeur est intéressant ou pas.