http://trac.rezo.net/trac/spip/ticket/620#comment:11
Voir Éric Daspet, « Cache central des bibliothèques javascript »,
Performance web, 17 février 2009,
http://performance.survol.fr/2009/02/cache-central-des-bibliotheques-javascript/ ,
discutant l'utilisation de http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.js
(indiqué dans http://code.google.com/intl/fr/apis/ajaxlibs/documentation/#jquery )
et de ne pas copier le code de jquery dans SPIP.
La question est : Est-il intéressant de mutualiser les quelques dizaines de ko de
ce fichier pour tous les sites web utilisant SPIP ?
La réponse est dans l’article, quoique …
En synthèse la concatenation+minification mise en place dans SPIP 2 est plus efficace et préférable car elle permet de remplacer 2 ou 3 hits par un seul, et la réponse ‹ oui › est principalement valable à l’intention de ceux qui ne s’étaient encore jamais posé la question des performances.
Dans le contexte de SPIP la question prend toutefois une autre dimension. Mutualiser la référence vers jquery peut effectivement avoir un intérêt théorique car cela revient à mutualiser le cache client jquery entre tous les sites sous SPIP.
Malheureusement, les changements de version régulier de jQuery amoindrissent nettement ce gain théorique, qui plus est car cela suppose de conserver au moins un hit vers le site lui même pour les autres fichiers propres à SPIP.
La vrai solution optimisée serait donc d’avoir un cache central spip.net qui permette de mutualiser les fichiers concaténés généralement présent dans le head (jquery+jquery.forms+ajaxcallback) par exemple.
Je pense que l’orientation à prendre est de développer le compresseur vers un vrai module d’optimisation des performances, avec des niveaux de réglage plus fins qu’actuellement.
En particulier, il faudrait séparer et affiner le réglage de concatenation pour permettre à minima de toujours concatener les 3 js utilisés par SPIP (jquery+jquery.forms+ajaxcallback) et dont on sait qu’ils sont toujours concaténables sans risque.
Actuellement la concaténation est en tout ou rien (elle concatene tous les fichiers trouvés dans le head en une seule référence), ce qui peut engendrer des bugs dans certains cas et oblige à la désactiver par défaut.
Il faudrait donc un niveau minimal d’optimisation dont on est certain qu’il n’entraine aucun bug, et qui puisse être activé par défaut.
Cédric
Il ne faut surtout pas oublier qu’il y a sans doute pas mal de sites SPIP qui sont utilisés en Intranet ou en poste local de dev, potentiellement sans accès Internet. Une copie locale est donc nécessaire.