On parle de temps, de performance, mais finalement que mesure t-on ? La question n'est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?
Je vous en parlais il y a presque deux mois, JSON c'est lent à interpréter si on le fait bien. C'est même globalement plus lent que XML parce que le code est en javascript, côté utilisateur, alors que XML est géré nativement par les navigateurs.
Et vous, où en êtes-vous ?
Rob Larsen a récupéré une liste de 200 sites américains et a fait fonctionner yslow sur chacun d'eux en janvier dernier. Les résultats c'est 5 A, 6 B, 14 C and 31 D et le reste en F.
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.
Je viens de croiser une liste de recommandations Microsoft pour la performance des sites web. On y retrouve plusieurs choses connues et une recommandation sur la cohérence des liens. La page MSDN donne l'exemple d'un même lien avec deux casses différentes. Certains serveurs ignoreront la casse ou corrigeront le lien mais cela restera deux ressources différentes sur le client, avec des entrées séparées sur le cache, donc au moins une requête HTTP inutile.
Je vous en avais parlé il y a une semaine, voici donc le contenu de notre présentation sur les performances avec Mathieu Pillard et Anthony Ricaud au dernier W3Café.
La taille des pages a plus que triplé en 5 ans, passant de 90Ko à 310Ko. Dans le même temps on a aussi doublé le nombre de composants externes par page (de 25 à 50). Cette progression ne faiblit pas, bien au contraire. Attention, je bourre le reste de l'article de chiffres, et certains font peur.
Qui aime attendre pour charger une vidéo ? probablement personne. Du coup quand vous arrivez sur une page avec une vidéo, le lecteur précharge le début au cas où vous voudriez la jouer. Même une fois en lecture, votre logiciel tente d'avoir toujours une avance confortable sur le chargement de la vidéo afin de vous éviter d'avoir à attendre. Sur le principe c'est bien.
J'ai beaucoup parlé de CSS, de réseau, de javascript, et j'entend parfois dire que le HTML lui n'a aucune importance. Ce n'est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM.
Je vous détaille le premier ici, les deux autres bénéficieront d'un billet dédié afin de mieux organiser les commentaires.
Je parle de détails et de ce que je rencontre dans mes lectures, et j'en oublie le principal. alors voilà, si vous ne devez retenir qu'une chose c'est d'utiliser des dates d'expiration explicites sur vos contenus.
Il s'agit d'informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n'a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d'autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément.
On reparle des performances CSS. Souvenez-vous, je vous avais parlé d'un document de Mozilla faisant état des sélecteurs plus ou moins performants. S'était ensuivi une discussion à propos de la pertinence de tels sujets vu la différence de performance mise en oeuvre.
ar contre je me retrouve pile dans l'usage où la performance est nécessaire, indispensable. Au milieu du CEBIT, une borne wifi est ouverte. J'en profite pour tenter d'accéder aux sites d'information français pour me tenir au courant de l'actualité (non, je ne parle pas le turque). Sauf que cette borne il y a trop de monde dessus, je la reçois mal, et pour ne rien gacher la latence entre la Turquie et la France plombe tous les échanges.
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 :
