Optimiser ses javascripts : le cas de mootools

Web & bonnes pratiques

Avec le nouveau thème du blog, Nodoka, c’est posé la question de l’optimisation des javascripts. En effet, mootools c’est bien, mais c’est lourd : 87Ko pour la version complète !

J’ai donc essayé les différents moyens de compresser du javascript et j’en ai fait un tableau comparatif.

Comparatif des différentes méthodes de compression du code javascript

Les tests suivants sont effectués à partir de la version complète de mootools 1.11.

Full Sans les commentaires JSMin YUI Compressor packer
180Ko 87Ko 73Ko 65Ko 41Ko

Comme le démontre le tableau, la meilleure méthode de compression semble être packer. Mais après une discussion sur le chan #mootools (serveur freenode.net), il semblerait que packer souffre de 2 problèmes :

  • problème avec les regex (pas tout compris à la démonstration : barrière de la langue 😉 )
  • moins compressible que YUI

C’est pour ça que mootools utilise YUI Compressor et j’ai donc suivi cette préconisation sur mon blog.

Pourquoi compresser du javascript pour gagner quelques malheureux kilo octets ?

Aller plus loin

Mais les 65Ko obtenus avec YUI Compressor ne sont pas une fin en soit. Il est ensuite possible de compresser le JS pour en faire un gzip. Attention : je ne parle pas de faire consommer du CPU pour compresser à la volée, mais de compresser une fois pour toute :

cp moootols.js mootools.jgz
gzip -9 mootools.jgz
mv mootools.jgz.gz mootools.jgz

Ensuite on modifie l’inclusion de la librairie :

<script src="/themes/nodoka/js/mootools.jgz" type="text/javascript">

Et on effectue un petit réglage sur son serveur pour penser à ceux qui ne supportent pas la compression Gzip :

# JGZ (compression JS)
RewriteCond %{HTTP_USER_AGENT} ".*Safari.*" [OR]
RewriteCond %{HTTP:Accept-Encoding} !gzip
RewriteRule (.*)\.jgz$ $1\.js [L]
AddType "text/javascript;charset=UTF-8" .jgz
AddEncoding gzip .jgz

Voila au final mootools complet ramené de 87Ko à 19Ko.

Commentaires

Rik

Suite à mes commentaires, je me sens obligé de réagir :)

Le packer de Dean Edwards a un autre problème. Pour gagner encore plus de place, il demande un traitement côté client (un petit coup de eval() ). Le temps d'exécution de cet eval est supérieur au gain de téléchargement en règle générale.

Le problème des gros Javascript est de bloquer l'affichage et le téléchargement dans un navigateur. Pendant qu'il télécharge puis interprète le JS, le navigateur ne peut rien faire d'autre. C'est d'ailleurs pour cela que Yahoo! recommande aussi de placer ces JS en fin de page. L'utilisateur aura un affichage le plus tôt possible.

Concernant Gzip à la volée, c'est très peu consommateur en CPU. Ton lien concernant des chutes de performance ne sont dûes qu'à la compression Gzip effectuée par PHP. Ce n'est pas son métier. Par contre, Apache sait très bien le faire. En plus, il respectera mieux la négociation de contenus.

La règle est aussi très bizarre. Pourquoi exclure Safari ??? Il sait très bien gérer Gzip...

Bon, je pourrais m'éterniser, mais j'en laisse pour une autre fois ;)

llaumgui

Effectivement, j'ai hésité à rajouter ce point car ceux qui ont des dual-core auront du mal à comprendre ;-).
Mais le packer de Dan est effectivement plus lourd à décompresser. Pour la compression en une seul fois, quand on peu la faire c'est quand même mieux ;-).

Pour safari, je me suis inspiré du commentaire sur le blog que j'ai retrouvé à plusieurs endroit sur la toile.

virtualgadjo

Salut,
juste un petit mot à propos de Packer. Le problème avec les regex ne concerne que la version disponible en php. La version javascript n'a pas ce problème.
Perso, j'utilise mootools1.2 au grand complet, core et more dans une seule feuille de js packerisée, le tout ne pèse "que" 56.5ko et je n'ai absolument aucun problème.
Have swing

Les commentaires pour ce poste sont fermés.

Réseaux sociaux