Performance web et JavaScript

Compte-rendu de la soirée Performance Web du mardi 24 avril

A propos de la/des soirée(s)

Anthony, où étais-tu ?! Ce n’était pas pareil sans toi ! (si ce n’est que tu t’es quand même fait vanner)

On est toujours en recherche d’orateurs pour des présentations de toutes formes. Il y a déjà eu des conférences, des ateliers, ça peut être des débats, des présentations courtes, longues, etc.
(Pour ceux à qui ça fait peur, j’ai profité d’un moment d’attente pour rappeler que Paris-Web organise une journée d’aide aux orateurs).

On recherche aussi des salles, sur Paris, d’une 50aine de personnes environ. En général, la boîte qui nous accueille nous offre un buffet, j’y ça j’dis rien. ;p

Ces soirées sont toujours aussi sympa et détendues malgré un renouvellement impressionnant des auditeurs (et ça aussi c’est chouette)

Julien Wajsberg@jwajsberg
Tester les performances JavaScript

Diaporama : http://www.slideshare.net/jwajsberg/benchmark-et-comparaison-de-performance-en-javascript

Julien nous a parlé de la façon de faire des tests comparatifs des performances de ses scripts JS, notamment avec jsperf.

Il a commencé par un point méthodologique qui m’intéressait tout particulièrement en tant que gestionnaire de la qualité.

Quand faire des tests comparatifs ? quand ne pas en faire ? Comment les faire ? Et qu’en conclure ?

Pour commencer, Julien rappelle ce qu’il faut considérer au moment de tester la performance web : la sécurité et l’expérience utilisateur notamment.

Comparer peut par exemple servir à choisir entre deux librairies (ou au moins connaître l’impact).

Attention à la sur-qualité aussi (un thème qui nous est cher, à nous, qualiticiens) : ne pas perdre du temps sur des micro-optimisations.

Notons tout de même que des micro-optimisations présentes de manière répétée peuvent alors devenir des optimisations intéressantes à traiter.

Voici un bon exemple de test comparatif entre deux algorithmes fait sur jsperf :

http://jsperf.com/map-vs-array

Avant de créer un nouveau test, chercher les tests déjà faits mais il faut se méfier : ils ne sont pas tous bien fait.

En en créant un, on peut demander d’utiliser ou non des bibliothèques.

Attention à ne pas faire de jsperf avec Firebug lancé car il désactive les optimisations nav (v. la FAQ)

La méthodo c’est de :

  • savoir ce qu’on teste
  • initialiser le test (“setUp”)
  • faire le test
  • nettoyer (“tearDown”)

Pour comparer :

  • les seuls tests comparables sont ceux d’un même “run” (pas de comparaison entre navigateurs)
  • 4 x plus lent, c’est déjà pas mal si c’est un code qu’on fait souvent (“hot spot”).
  • En général, en deçà d’un delta de 10, on considère que ce n’est pas intéressant.

Jean-Pierre Vincent@theystolemynick
Charger du JS

 

Pour profiter pleinement de la très bonne présentation de Jean-Pierre, une adresse :

http://braincracking.org/test-perf/

On y retrouve les 9 démos pédagogiques (même moi j’ai compris des trucs !) qu’il a tester pour trouver la meilleure façon de charger le JavaScript :

  1. Load in the head
  2. Load in the body
  3. Load in the bottom
  4. Load in the bottom, with callback
  5. Load in the bottom, long .onload
  6. Load with native defer attribute
  7. Asynchronous non blocking JS loader
  8. Asynchronous non blocking JS loader, with callback
  9. Asynchronous non blocking JS loader, with callback, long .onload

Comme je suis une “spoileuse” de première, je vous dévoile tout de suite la conclusion (mais allez quand même voir les tests un par un).

Le chargement asynchrone c’est vraiment bien quand le DOM est très long à charger (et ça peut même faire des miracles). Sur pages plus petites ou mieux maîtrisées, le script en bas de page reste le mieux. Par contre, dès qu’on fait du mobile, il faut passer par du “callback” pour s’affranchir des problèmes de dépendance.

Au moment de regarder les temps de chargement et notamment le “start render”, ne pas oublier que les outils automatiques ne prennent pas la pertinence de ce qui est affiché en compte.

Un aplat de couleur sert à déterminer le start render. Un humain saura que ça ne sert pas à grand chose au niveau de l’utilisabilité du site. Si une couleur de fond est affichée très rapidement, c’est moins intéressant que si un bouton d’action est affiché assez rapidement par exemple.

Jean-Pierre nous a aussi rappeler l’existence du tableau comparatif initié par Éric Daspet : « Javascript loaders » (attention à vérifier la mise à jour, contribution bienvenue).

Merci à OCTO de nous avoir (encore) (si bien) accueillis.

Merci à Julien et Jean-Pierre d’être venu partager de façon si pragmatique leurs réflexion.

Merci aux nouveaux venus d’être …venus voir ; ça vous a plu ?!

Set de photo : Prélude.

Les vidéos de la soirée : Première partieSeconde partie

Ce contenu a été publié dans Compte-rendu, avec comme mot(s)-clé(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.

4 Responses to Performance web et JavaScript

  1. Anthony dit :

    J’étais dans mon lit en train de mourir. 🙂

  2. Huc Arnaud dit :

    En effet c’était une soirée vraiment sympa, à refaire sans hésiter ! 😀

  3. SEBIRE Jonathan dit :

    En tant que nouveau j’ai vraiment passé une bonne soirée ! Merci a tous 🙂

  4. MathRobin dit :

    Première soirée WebPerf, je reviendrais, j’ai appris quelques trucs bons à savoir. Merci aux deux orateurs et à OCTO ainsi qu’aux organisateurs

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *