Il y a des gains de performances à faire là où on ne s'y attend pas.
Je voulais me débarrasser d'une impression de lenteur lorsque je passais sur une galerie dynamique d'images. Bizarrement cette lenteur était encore plus forte sous FF Mac que sous IE6 Windows ! Cette galerie étant faite en JavaScript, pour moi la résolution de ce problème de perf ne pouvait venir que de là. Mais ni le profiler de Firebug, ni l'excellent profiler d'IE8 ne m'indiquait de zone de code JS posant problème. Speed Tracer lui m'indiquait des évènement paint très réguliers, dont je ne trouvais pas l'origine JS.
J'ai donc du laisser de côté JS et me suis dit que c'était Canvas qui me posait problème (je l'utilise pour faire un effet miroir)
Après désactivation de beaucoup d'élément sans résultat notoire, j'ai fini par chercher du côté du DOM et des styles en me demandant ce qui pouvait déclencher tout ces repaints ... pour me souvenir que derrière chaque image (il y en a une vingtaine) j'avais posé un indicateur de progression, dit spinner !
C'est une veille ruse indienne consistant à définir un gif animé en background-image d'images, définir une width et une height pour qu'il apparaisse. Le browser le fait disparaître lorsque l'image est chargée.
La charge processeur de FF3.6.3, sous Mac, avec 20 images animées invisibles : la moitié du proc !
On désactive le style, FF revient à une activité normale :
Voici le graphe du CPU d'un FF windows :
FF restait scotché à 20% de CPU. Après modification du CSS, rechargement de la page et navigation, FF revient à une charge normale.
Pour résoudre mon problème de CPU tout en gardant un indicateur de chargement, j'ai donc du supprimer ce spinner une fois l'image arrivée. Pour d'autres raisons, je surveillais déjà l'évènement onload de chacune de mes images, j'ai donc pu y rajouter une classe "loaded" lorsque l'image est arrivée chez le client, ce qui avec la syntaxe YUI donne cela :
YAHOO.util.Event.on(
'load',
oDOMImage,
function() {
YAHOO.util.Dom.addClass(oDOMImage, 'loaded');
});
et écrire ce bout de CSS :
img{
background-image:url(loading.gif);
}
img.loaded {
background-image:none;
}
Ainsi j'ai pu gagner en fluidité sur tous les navigateurs de toutes les plateformes lors de l'affichage de cette galerie. Pour aller plus loin et comprendre, il faudrait vérifier les performances avec un gif non-animé, ou en background-image d'éléments autres que les images.
Le fait que le problème soit particulièrement visible sur FF et Chrome Mac, invisible sous Safari, et juste génant sous les navigateurs Windows montre tout de même à quel point il doit être difficile pour les navigateurs d'utiliser l'accélération matérielle de MacOS auquel Safari a accès.
En tout cas merci à Google Speed Tracer qui a pointé du doigt ces repaints réguliers. Moi qui ait toujours pensé que les CSS n'avaient que peu d'influence sur les perfs, on voit que dans certains cas précis ça n'est pas le cas.
Veille technologique quotidienne via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .
Il y a quelques années de ça, Yahoo! a découvert une règle de performance frontend qui a fait date, et qui fait toujours partie des must-have :
Plus tard Google PageSpeed a inclus la même règle. De fait, une inclusion de JavaScript bloque tout rendu ET téléchargement durant le temps de téléchargement du fichier. Dans le cas d'une mauvaise connexion, vous pouvez même rester sur une page blanche alors que la majorité de la page est téléchargée.
Ici les images attendent le JS. Temps body.onload : 3.7s. (voir toute la timeline)
Cette règle est donc réellement à considérer dans le top 10 des modifications à apporter pour qu'un site semble plus réactif. Les développeurs qui ont vu ça ont fait le test de déplacer les balises <script> du <head> pour les mettre tout en bas de page ... pour se rendre compte que la page "cassait" et que des modifications de leurs scripts seraient trop pénibles à exécuter.
Mon but était d'accélérer le rendu de la homepage de mon projet actuel pour les visiteurs sans cache. La page mettait plus de 3s avant que le DOM ne s'affiche, alors que le HTML était reçu en moins d'une demie seconde. Ayant la chance d'avoir la même problématique que Facebook (1 page de garde qui n'a que 3 fonctions : se loguer, s'enregistrer et parler du service), j'ai pu reporter le téléchargement de l'intro flash, réduire de moitié le poids total des JS et CSS et accélérer l'envoi des scripts avec du cache côté serveur. 60ko de JS ça reste lourd pour une seule page, et je pourrais faire encore plus spécifique, mais cela demande plus de temps et dans nos contrées ADSLisées le poids n'est plus le nerf de la guerre.
Ces modifs étaient plutôt lourdes et je leur ai consacré presque 2 journées, sans gain sensible, alors que déplacer une inclusion de JS prend une minute. Il me fallait donc tenter quelque chose pour ce fichier JS inclus dans le <head>. Mon seul problème était les <script> inline qui se lançaient et qui dépendaient de ce fichier.
Avant que vous ne criez au scandale, il faut savoir que ce site a été développé de manière modulaire : écrire des parties indépendantes de site qui peuvent être inclues n'importe où, y compris via XHR (dit AJAX). On est donc bien forcé à un moment de lancer le Javascript associé à un module et si vous regardez le code source, le JS inline ne fait qu'instancier les classes correspondantes aux modules inclus (login, animation, feedback ...). Pour les modules communs, cette partie de JS est dans le fichier principal (dans l'illustration plus haut, c'est celui de 67ko), pour d'autres plus exceptionnels répartis ailleurs sur le site dans des fichiers séparés qui ne sont appelés que lorsque le module est récupéré en AJAX (technique dite du lazy-loading) .
La concaténation (pour moins de requetes HTTP) et le lazy-loading (pour moins de poids initial) s'opposent mais lorsque l'on fait une quasi application web, il faut essayer de les doser pour obtenir le meilleur des 2 mondes. Dans l'un ou l'autre cas, le cache du navigateur rendra l'expérience fluide.
Voilà donc pourquoi on se retrouve à vouloir exécuter le code que l'on voulait justement inclure après.
La technique se déroule en 5 temps :
Concrètement, dans le <head>, à la place du <script src=""> original :
<script> window.defaultOnError = window.onerror;
window.onerror = function() {return true;};
</script>
On a sauvegardé le gestionnaire d'erreur par défaut (window.onerror) pour plus tard et on définit à la place une fonction qui ne fait rien. Les erreurs n'arrivent plus jusqu'à l'utilisateur.
En bas de page, après </html> :
<script> window.onerror = window.defaultOnError; </script> <script src="http://example.com/my.js"></script>
On a remis le gestionnaire par défaut et on a inclus notre fichier JS qui ne gène plus personne. Ensuite on va retrouver les script inline pour les exécuter :
<script> var aInlineJS =document.getElementById('container').getElementByTagName('SCRIPT'),
iTotal = aInlineJS.length;
for(var i=0; i < iTotal;i++) {
eval( oJscripts[i].innerHTML );
} </script>
où container serait l'id de ma div principale. Ici on a :
Le vrai code est à peine plus long car il prévoit plus de cas, mais vous avez l'idée. Vous pouvez regarder le code dans la source de cette homepage. Voici notre nouvelle timeline :
Les images sont récupérées en même temps que le JS. Temps body.onload : 1.7s (voir la timeline complète)
Au bout de quelques semaines, Google aussi a la sensation que la page est plus rapide :
On a gagné :
Il y a des inconvénients et certaines choses à prendre en compte :
Si vous voyez d'autres limites, j'attend vos commentaires
Facebook et Google Analytics ont développé des techniques particulières pour exécuter du code alors qu'il n'est pas forcément encore téléchargé.
Google analytics utilise dans sa version asynchrone une astuce tirant parti de la versatilité de JS. Un Array est déclaré et le webmaster utilise .push() en lui passant le nom et les paramètres des méthodes à appeler. Lorsque le fichier ga.js arrive, celui ci remplace le tableau par une classe, exécute toutes les commandes demandées auparavant et .push() sert maintenant à exécuter directement les méthodes.
Facebook pour sa part a expliqué que pour passer de 5s à 2.5s avant le 1er clic, ils ont du faire du très spécifique : ils déclarent en haut de page un petit listener JS, le reste du JS étant en bas de page (145Ko en 16 requêtes). Si l'utilisateur clique vite, ce petit code ouvre une popup JS qui va chercher sur le serveur le HTML et le JS a exécuter.
Dans ces 2 cas, décaler JS en bas de page demandait à changer sa manière de programmer, ce qui fait partie des choses que je voulais éviter. La technique du mute+eval est exactement adaptée à la problématique que j'avais, aussi je serais curieux de voir ses limites sur d'autres types de pages, ou au contraire si elle peut s'adapter chez vous aussi
Qu'en pensez vous ?
Veille techno et articles similaires via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .
Les commentaires récents