Optimiser ses javascripts : le cas de mootools

Optimiser ses javascripts : le cas de mootools

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.

FullSans les commentairesJSMinYUI Compressorpacker
180Ko87Ko73Ko65Ko41Ko

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.

Avatar de Guillaume Kulakowski

À propos de l’auteur

Commentaires

3 réponses à « Optimiser ses javascripts : le cas de mootools »

  1. Avatar de 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 😉

  2. Avatar de 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.

  3. Avatar de 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

Derniers articles sur le journal

  • SeedboxSync v4.1 : Authentification OIDC, Gravatar et refonte de l’administration
    Découvrez les nouveautés de SeedboxSync v4.1 : intégration d’un système d’authentification natif et OIDC (SSO), support de Gravatar, gestion des utilisateurs en CLI, formulaires Flask-WTForm et transition vers Peewee-Migrate.
  • De Jellystat à Jellydash : moderniser le suivi de mon serveur Jellyfin
    Pourquoi et comment j’ai remplacé Jellystat par Jellydash pour le suivi des statistiques de mon serveur Jellyfin. Retour d’expérience sur la découverte de cet outil moderne, léger et prometteur repéré dans la newsletter selfh.st.
  • SeedboxSync 4.0 : Fusion de l’IHM et du CLI
    La v4.0.0 de SeedboxSync marque un tournant majeur : fusion du CLI et du frontend en une seule application, migration de la configuration en base de données, planificateur Python natif et passage à SQLite WAL. Tour d’horizon des nouveautés et des changements d’architecture.
  • Modernisation du tooling dev sur SeedboxSync : Just, pnpm, uv & Ruff
    SeedboxSync fait peau neuve côté tooling ! Retour sur la modernisation de mon environnement de dev : abandon du bon vieux Makefile au profit de Just, transition vers pnpm pour un gain de temps spectaculaire côté frontend, et adoption de uv et Ruff pour booster l’écosystème Python. Moins de friction, plus de vitesse : découvrez le détail de cette mise à jour.

Articles à la une