Compresser son Javascript au maximum : quel outil choisir ?

La compression de fichiers Javascript, même si elle semble simple au premier abord, s’avère un problème complexe. En effet, il existe une foule d’outils, et chacun se prétend le meilleur.

Illustration deux méthodes de compression

La guerre des compresseurs

Pour cette étude comparative, j’ai réuni 8 outils de compressions : YUI Compressor, Dojo ShrinkSafe, Packer, JS Utility v2, LZ77 JS Compressor, MemTronic JS Cruncher, JS Min, et Crunchy.

En prenant comme base de travail le fichier Javascript principal de NoPhysic, j’ai essayé les uns après les autres chacun de ces compresseurs, en jouant sur les paramètres lorsque l’on m’en proposait.

Ce travail fastidieux a été fait «à la main», car si certains d’entre vous ont pensé à Compressor Rater, je le déconseille car en échange du confort d’utilisation qu’il apporte, vous perdez en précision. En effet, l’utilisation du YUI Compressor en local par exemple a donné de meilleurs résultats que le code fournit par Compressor Rater, qui utilise une version plus ancienne.

Update : CompressorRater a été mis à jour et fonctionne à présent bien mieux. Je conseille toutefois de toujours vérifier les versions des compresseurs utilisés sur CR, puisqu’elles peuvent avoir du retard sur les distributions officielles.

Plusieurs types de compressions

La première chose à remarquer avec les compresseurs de Javascript, c’est qu’ils utilisent globalement deux méthodes (algorithmes) pour générer un code plus court.

  • La méthode soft, qui consiste à enlever tous les espaces, retours à la ligne, et caractères inutiles. Elle procède aussi à un raccourcissement des variables et des arguments qui remplace tous les noms par de simple lettres (ex: function(questionnement,existentiel) devient function(a,b)).
  • La méthode lourde, utilisé par Packer par exemple, permet un code beaucoup plus court, grâce à une réécriture du code, par changement de base.

Le graphisme suivant illustre bien l’efficacité de chaque technique. Les trois premiers compresseurs se valent à peu près (méthode soft), alors que Packer et JS Utility (méthode lourde) sont largement en tête — avec une avance encore plus marquée de JS Utility qui utilise une base arithmétique plus grande (caractères iso-8859).

Diagramme comparatif des différents compresseurs

De prime abord, il semble évident que la compression la plus lourde est la meilleure. Ce n’est pourtant pas le cas lorsque l’on prend en compte le fait que nos fichiers compressés seront envoyés gzippés au visiteur.

Le paradoxe post-gzip

La compression gzip est parfaitement reconnue par les navigateurs modernes, alors à moins que votre cahier des charges vous oblige à assurer 100% de compatibilité avec les versions antérieures d’IE, vous allez gzipper vos scripts. C’est justement à ce moment que l’on se rend compte d’un fait nouveau : le fichier le mieux gzippé n’est pas celui que l’on pensait, comme en témoignent les résultats suivants.

Deux algorithmes de compression différents

Remarque sur les délais de décompression

Un autre facteur important à prendre en compte est le temps que mettra le script à se décompresser. Si le délai de décompression est supérieur au temps de téléchargement gagné, la compression est contre-productive. Heureusement, à l’échelle d’un blog, la taille du javascript est relativement faible, et mes tests ont rapporté des délais compris entre 60 et 120 ms.

À noter également que la compression par raccourcissement des variables n’altère pas le temps d’exécution du script, puisque sa structure reste la même. La technologie du YUI permet même de gagner en temps de traitement par rapport au script original (dixit Julien Lecompte).

L’heure des conclusions

Dean Edwards l’avait bien compris dans son article «Notes on JavaScript Compression» :

The most efficient way to serve compressed JavaScript is to first run your code through a JavaScript compressor that shrinks variable and argument names, and then serve the resulting code using gzip compression.

Si vous avez la possibilité d’utiliser gzip, le mieux est donc de passer par un outil de compression comme Packer (en prenant soin de ne pas cocher la case «Base 62 encode», mais en cochant «Shrink variables»), YUI Compressor, ou encore Crunchy (ce dernier est mystérieux mais ses résultats sont excellents).

Update: méfiez-vous de Crunchy, il génère un code qui est parfois mal interprété par IE. Préférez lui YUI Compressor.

Si vous devez envoyer vos fichiers sans gzip, passez par JS Utility v2, voire packer (base 62). Méfiez-vous cependant des temps de décompression.

Cet article vous a plu ? Abonnez-vous à NoPhysic par RSS ou mail.

Message express à l’auteur