Compresser du javascript : JSMin ou packers ?

Publié le 6 août 2008 - Developpement Web. Tags :

Alors que l’AJAX se propage à vitesse grand V sur la toile, surfant sur la vague 2.0 dont il est plus ou moins à l’origine, les frameworks javascripts ne cessent de se multiplier (Mootools, JQuery & co.) en parallèle devenant de plus en plus complets. Même si le rendu est du plus bel effet, le revers de la médaille n’est pas sans conséquence : le code javascript des pages s’allourdit par la même occasion considérablement et le temps de chargement devient de plus en plus problématique.

Pour y remédier des compresseurs tels que l’excellent JSMin sont donc apparus; leur rôle : enlever le code supeflu. Un tel système a l’avantage d’être totalement transparent pour l’utilisateur (le développeur devra quand à lui garder une copie non optimisée), et permet de gagnee 50% de temps de chargement. Seulement avec la course à la complexité des frameworks, une autre ‘race’ de compresseur a vu le jour, permettant d’aller encore plus loin dans la compression de ces fichiers (+25%). Bien que le concept soit similaire la mise en pratique est assez différente puisqu’il s’agit d’un ré-encodage de code javascript sous un format différent. Le problème est que ces données doivent être décryptées par les navigateurs, et que ces derniers ne sont pas tous… Alors même si le gain en terme de poids de fichier est conséquent, qu’en est t-il du temps de chargement? Comme cela était prévisible, et d’après les analyses très intéressantes effectuées par le site BSOhq un tel système est au final contre productif.

Pour plus de détails, consultez l’excellent article performance des packers javascripts.


Articles sur ce thème :