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

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 ;)

@nicolas : merci d'avoir fait un post sur ta migration, tes contraintes de base (passer les validateurs XHTML) sont bien plus fortes que les miennes et c'est donc une lecture assez intéressante. que je m'empresse de partager sur ma revue de presse d'ailleurs :)

ah non peut être pas Alsa : http://www.alsa.fr/

et moi qui hésitait avec "le Sieur Goetter" (attiré par une rime facile) :/ Raphounet ? le gars d'Alsa ? :)

tiens j'ai retrouvé ce qui m'avait mis le doute : http://www.softwareishard.com/blog/firebug/firebug-http-time-monitor/ l'équipe firebug s'était rendu compte que dans certains cas (UI bloqué), la précision était largement faussée dans le tab réseau, et ils avaient fait ce post en octobre dernier pour dire que c'était fixé, ce qui m'a laissé supposer que le problème pouvait très bien se reproduire dans d'autres mesures. Mais maintenant Firefox exécute les addons en dehors du thread principal, logiquement ça doit améliorer la précision Les addons IE eux (dont dynatrace) ne sont pas fait en JS et sont exécutés dans des process à part, ils partent donc mieux pour être plus précis, mais comme je n'ai aucune idée de la manière dont ils accèdent au coeur de IE, ça ne m'avance pas plus, et cette fois ci impossible de trouver l'info sur le Net

je ne voulais pas faire ce tuto plus long que nécessaire, mais je crois que tu as raison : je vais rajouter au moins le pattern Singleton