En avril je vous parlais du packer de Dean Edwards qui permet de miniser le code javascript avant envoi. J’émettais un doute sur l’option base62. Avec cette option le code javascript est codé avant envoi. Une fois ce javascript reçu, le navigateur va le décoder, puis utiliser eval() pour l’exécuter. C’est tout sauf transparent pour le client, surtout que pendant ce temps de traitement supplémentaire, c’est tout le rendu et les téléchargements de la page qui sont bloqués.
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.
Excellente mise au point ! Il faudra que j’applique un jour ces bons principes 😉
A propos, connais-tu LZO ? C’est un algorithme de compression de données sans perte qui privilégie la vitesse d’exécution et obtient des temps quasi-identiques au niveau des opérations de compression et décompression — un fait appréciable pour la réplication ou l’archivage de données de serveur à serveur. Dommage que les serveurs et navigateurs Web n’aient retenu que le couple zlib/gzip pour réduire le temps de transfert des données…
http://en.wikipedia.org/wiki/Lempel-Ziv-Oberhumer
Non, mais en même temps on est limité parce qui est prévu initialement dans HTTP, ou au moins par ce qui est supporté par les navigateurs. Dans l’ensemble deflate est très bien pour ce qu’on en fait, surtout que le cout de décompression est rarement le problème majeur.
J’ai écrit un billet assez complet là dessus je pense, il y a un certain temps. Je t’engage à y jeter un œil 🙂
L’encodage et le décodage du fichier n’est pas obligatoire. De toute façon le terme de « compression » est abusif. j’ai moi même développé un utilitaire en Python (ligne de commande), et avec :
1) la suppression de tous les caractères blancs
2) le remplacement des noms de variables et de variables d’instance
On atteint vite 60% de gain. Bien sûr, avec un taux de commentaire normalement élevé.
En particulier, je prend soin dans mon processus de remplacement des noms de variables d’attribuer aux variables les plus redondantes les noms de remplacement les plus courts (une lettre en gros).
Jetez donc un coup d’oeil ! http://www.bonjour-monde.com/wordpress/
Ceux qui ont des noms de variables à conserver peuvent le faire très facilement.