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.
Je fais suite au précédent billet sur la présentation de Steve Souders aux conférences Velocity 2008. Tout à la fin il nous donne une seconde information sur le javascript inline, et ceci est une nouveauté pour moi.
Charger le javascript le plus tard possible, ou au moins de manière asynchrone, implique que le visiteur risque de voir la page avant l'exécution du dit javascript. Si le javascript enrichit ou modifie la page, le visiteur aura la désagréable surprise de voir la page se modifier sous ses yeux.
Dans la plupart des langages, les chaînes de caractères ne sont pas modifiables. Ajouter un caractère à une chaîne existante c'est créer un nouvel objet avec la chaîne résultante. Parfois comme dans ruby ce n'est pas visible pour l'utilisateur mais c'est bien ce qui est fait en interne. pour éviter que de multiples concaténations ne posent des problèmes de performance, on a souvent à disposition un objet spécifique StringBuffer dédié à cet usage. Ce n'est malheureusement pas le cas en javascript et on voit passer de nombreuses recommandations de micro-optimisation pour compenser.
Les bons développeurs javascript utilisent les événements, à toutes les sauces. En fait quasiment tout ce qui est fait en javascript est en réaction à un événement. On arrive à deux problématiques qui ont un un impact plus ou moins important sur les performances :
