Attention qu'on risque de casser le rendu pour certains quand même.
Je préfère l'optique de http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/ et http://velocityconf.com/velocity2010/public/schedule/detail/14334
Il s'agit de faire passer un petit js gzipé. S'il s'exécute correctement c'est que le navigateur sait lire gzip. On met alors un cookie et c'est la présence de ce cookie qui permet de forcer gzip côté serveur.
La conséquence c'est que ces 15% n'auront pas gzip lors de leur premier accès, mais en retour on sait qu'on n'activera pas gzip s'ils ne le supportent vraiment pas
- fait par Steve Souders
- le but avoué est d'en faire un standard
- calculs basés sur l'API WebTiming, la google toolbar, un plugin firefox, ou simplement JS + un cookie
- bien sur utiliser la version asynchrone
- déplacer l'appel en bas de page (attention aux pertes de données pour les visiteurs qui cliquent vite)
- mettre ga.js sur un serveur local
Je n'ai pas vérifié comment traire ça jQuery spécifiquement, mais le procédé est habituel. Au lieu d'enregistrer un événement pour 10 éléments dans zone géographique réduite un à un, on l'enregistrer sur le parent et c'est le javascript qui fait l'éventuelle répartition ensuite. Ça peut effectivement avoir un impact sur les performances.
Après si jQuery fait effectivement une simple boucle en interne pour enregistrer 10 fois l'évenement, ça n'amène à rien. Ce serait étrange tout de même
Au temps pour moi, en allant plus loin dans l'analyse, il semble que jQuery ne place qu'un listener sur l'élément parent, ce qui parait logique !
J'étais d'accord avec le principe, mais c'est la doc de jQuery qui m'a mis le doute.
En tout cas ça n'empêche pas que j'aimerais avoir le résultat d'un benchmark :).