Cet article présente quelques astuces en Javascript pour optimiser vos algorithmes et la performance de vos scripts.
Au niveau du code
Précalculer le plus possible
Mise en “cache” dans des variables : par exemple l’accès à la propriété d’un objet enfouie sous plusieurs niveaux, ou un valeur utilisée dans la déclaration d’une boucle for.
// Pas bien
for (var n = 0; n < monObjet.maPropriete1.maPropriete2.valeur; n++) {
// ...
}
// Bien
var len = monObjet.maPropriete1.maPropriete2.valeur;
for (var n = 0; n < len; n++) {
// ...
}Interdiction d’utiliser eval !
A l’instar de n’importe quel langage, la fonction eval est un gouffre à performances. L’éviter autant que possible. Il y a bien entendu des alternatives :
// Pas bien
eval("obj."+prop)
// Bien
obj[prop]Concaténation de chaines
Utilisation d’un Array pour concaténer les chaines et liaison à l’aide de la méthode join(). Les développeurs de Microsoft le recommandent dans le doc en bas, à la manière d’un StringBuilder en .Net ou en Java :
var sb = new Array();
sb.push("
");
sb.push(monTexte);
sb.push(monTexte2);
sb.push("
");
var s = sb.join("");Au niveau des fichiers
Minifier les Javascripts en production
But : optimiser le chargement du script pour l’interprétation (bande passante utilisée, temps d’interprétation par le moteur JS du navigateur). Il existe d’excellents outils pour effectuer cette tâche : YUICompressor, JSMinifier… Dans l’idéal, s’assurer que tout le JS est envoyé avec un seul appel HTTP.
Mettre les déclarations en bas de page
Le plus près possible de la fermeture de l’élément body (</body>). Cela permet d’exécuter le code à l’issue du chargement complet du HTML, évitant du coup un blocage en plein milieu du rendu de la page.
Bibliographie rapide
mars 26th, 2009 at 14:25
Je ne suis pas d’accord concernant le dernier point : je pense qu’il vaut mieux extraire tout le javascript en fichier JavaScript externe (ce qui fera d’ailleurs l’objet de téléchargement en parallèle) et de câbler les événements depuis un événement “onload”.
J’ai tâché de mettre cela en pratique sur ce très petit projet Open Source : http://timeboxes.sourceforge.net/
Voici la page HTML totalement exempte de script “inline” :
http://timeboxes.svn.sourceforge.net/viewvc/timeboxes/trunk/index.html?view=markup
Voici le script qui ajoute lui-même les événements sur les éléments HTML :
http://timeboxes.svn.sourceforge.net/viewvc/timeboxes/trunk/js/timeboxes-behavior.js?view=markup
Je pense que c’est une bonne façon de faire : on sépare la structure (XHTML/HTML), du design/graphisme (CSS) et des comportements (JavaScript), à la manière du paradigme MVC.
mars 26th, 2009 at 15:04
Merci de ton retour Greg. J’avoue que j’aurais du préciser un peu plus ma pensée sur ce point.
En réalité je ne fais que remettre une des pratiques recommandées par Yahoo! ici : http://developer.yahoo.com/performance/rules.html#js_bottom
Nous sommes d’accord sur les pratiques de code et les séparation contenant / contenu / traitements : j’évite autant que possible le code JS “inline” au profit de fichier JS séparés de la page. On parle ici de déclarer ces fichiers dans des éléments [script] avant [/body] au lieu de les mettre dans [head].
Le problème est que dans le cas contraire, tu risques d’avoir des ralentissements d’affichage de ta page. Cela vient des limitations par défaut - dans HTTP/1.1 - à 2 requêtes simultanées pour un même domaine.
Et si tu as la page HTML + les CSS + les JS + les images à envoyer… autant servir le JS en dernier pour ne pas bloquer le graphisme.
Il y a deux entorses à cette pratique :
1) ton JS est sur un nom de domaine séparé. Exemple : tu utilises les frameworks AJAX disponibles sur googleapis.com depuis ton site http://www.exemple.com.
2) tu utilises des document.write dans ton code.
mars 27th, 2009 at 14:58
D’accord, je comprends mieux.
Cependant, je ne suis pas très “friand” de cette optimisation car je préfère déclarer mes scripts dans le (mais je suis peut-être “old school”).
Par rapport à ta remarque, je préfèrerais en effet utiliser Google API, je pense que c’est une bien meilleure optimisation (mais il faut accepter d’être dépendant de google et cela ne concerne que les libraries “main-stream” et encore moins son code).
Au sujet du “document.write”, je suppose que je ne suis pas le seul à le déconseiller fortement !
Merci pour ton très bon retour Christophe !
Grégory