inclusion performante de javascript, la mini-conférence

Pas de revue de presse ces 2 derniers jours car j’ai du préparer une mini conférence de 20 minutes et les sujets performances demandent énormément de recherches et de validation :)

Voici donc mes slides en ligne (PDF ici) de la soirée performance de hier, organisé par Eric Daspet et hébergé (et alcoolisé) par Octo. L’idée était d’explorer un point particulier des performances Web, le sujet traité ici étant l’inclusion non-obstrusive de JS. Il y a beaucoup de techniques plus ou moins exotiques, au final je vous ai épargné un listing savant que j’ai troqué contre un début de guide pratique d’implémentation. Je n’ai pas pu estimer de coûts de développement car les sites sont beaucoup trop différents.

Après un rappel des contre-performances des <script> dans le <head> (Voyages-sncf a des serveurs ultra performants qui délivrent du HTML en 200ms, mais la page reste blanche 2s), rappel des 3 techniques non bloquantes officielles :

  • Inline : on n’y pense plus, et pourtant c’est celle qui demande le moins de modification de code. A utiliser pour les pages avec beaucoup de nouveaux visiteurs, sans trop de JS (jeux concours, les HP Google, facebook, Yahoo!, Netvibes …)
  • Bottom : déplacer le <script> du <head> à la fin de <body>. A partir de là les difficultés d’implémentation commencent car vous avez probablement du JS inline qui avait des dépendances dans le fichier que vous venez de déplacer. 2 hacks possibles alors, l’un mute+eval() que j’applique déjà, l’autre que je n’ai pas exploré qui consisterait à hijacker les fonctions qui seront appellées pour les exécuter plus tard. Si cela n’est pas possible, vous êtes bons pour modifier votre code inline, ce qui est en général le moment où le « projet performances » tombe à l’eau …
  • DOM : la meilleure mais la plus lourde à implémenter, qui consiste à créer dynamiquement des <script> et à y attacher un callback JS contenant le code dont il dépend. C’est la plus pérenne à mon sens car une fois passé le gros boulot consistant à fixer son JS inline (en général encapsuler le code dans une fonction de callback suffit), alors le code est extrêmement souple et résistera aux changements à venir : code JS qui grossit et se complexifie, découverte de nouvelles techniques

Les liens en raccourci dans les slides sont des références que je vous ai déjà partagé, mais vous trouverez aussi quelques références sur le comportement IE6-7 intéressantes si vous êtes plutôt côté R&D

On le voit, sur un site existant gagner plusieurs secondes (donc de l’argent) sur l’inclusion des JS est réalisable mais a un certain prix. Ceux qui sont avantagés sont ceux qui développaient déjà de manière non-obstrusive (HTML d’abord, puis CSS, puis JS) et qui organisent déjà bien leur code JS (une classe ou un ensemble de méthodes par fichiers par exemple).

Si vous n’arrivez pas à faire passer un projet d’un bloc malgré vos arguments financiers, passez au moins doucement votre code à la méthode DOM au fur et à mesure de la maintenance de votre site, tout évolution future sera moins pénible :)

Et avant cela, il vous faut implémenter des techniques tout aussi efficaces et moins chères, comme la compression gzip, la concaténation des CSS/JS et surtout la gestion du cache navigateur.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.caDelicious,
Mail.

3 commentaires vers "inclusion performante de javascript, la mini-conférence"

  1. 07/23/2010 - 10:29 | Lien permanent

    Salut, c’était vraiment une bonne présentation.
    Comme je suis pointilleux tu aurais pu aussi aborder rapidement labJS et defer/async simplement pour donner quelques pistes.
    Au début de la présentation je me suis dit « tout ça, je connais » oui mais … En créant des règles (poids du html, du js, ..) pour savoir quelle méthode d’inclusion utiliser, tu es allé plus loin que simplement énoncer les techniques. Bon bien sûr les règles il faudra les tester d’avantage peut-être.
    J’ai adoré le moment ou tu as énoncé la technique mute+eval(), avec l’audience qui pousse un cri mêlé de dégout et d’admiration (sisi).
    Bon sinon moi mon HTML il arrive en 60ms et tu n’en as pas parlé !
    Bravo.

  2. 07/26/2010 - 13:30 | Lien permanent

    defer/async ne passait pas un critère éliminatoire pour moi : la compatibilité tout navigateur.
    pour labJS, c’est peut être une erreur de ne pas l’avoir inclus car outre le chargement non bloquant qui est de toute façon émulable facilement, il permet de gérer les dépendances entre fichiers JS, ce qui demande un peu plus de code, il a donc un intérêt direct pour l’implémenteur.
    Au moment de faire mon étude, je ne me souvenais plus qu’il existait, l’ayant éliminé de ma liste parce que je ne m’en servirais jamais : si 2 fichiers dépendent l’un de l’autre, je les concatène ensemble, ce qui n’est pas forcément jouable pour tout le monde …
    mea culpa donc, j’aurais au moins pu le citer.
    Sinon je vous ai épargné pas mal de techniques exotiques ou d’autres librairies qui n’apportent rien à l’affaire, pour me concentrer au final sur les difficultés d’implémentation communes à toutes les techniques de lazy-load. En fait si j’avais eu une heure de présentation, ces 20 minutes auraient été ma conclusion :)
    60ms pour ton HTML ? voyages-sncf m’a mis 50ms pour un css, tu es largement battu ;)

  3. 07/26/2010 - 13:32 | Lien permanent

    et j’ai du passer également sur les techniques de pré-chargement des JS, que j’utilise pourtant

Laisser un commentaire