Commentaires sur : Attention aux compresseurs javascript

Par : Nelson H

Nelson H — Tue, 23 Feb 2010 10:56:56 +0000

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.

Par : Louis

Louis — Mon, 11 Aug 2008 14:07:44 +0000

J'ai écrit un billet assez complet là dessus je pense, il y a un certain temps. Je t'engage à y jeter un œil :)

Par : Éric

Éric — Thu, 03 Jul 2008 10:05:49 +0000

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.

Par : Michaël Guitton

Michaël Guitton — Thu, 03 Jul 2008 09:59:46 +0000

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