Commentaires sur : Cache central des bibliothèques javascript

Par : Revue de presse | Simple Entrepreneur

Revue de presse | Simple Entrepreneur — Fri, 08 May 2009 12:25:35 +0000

[…] Cache central des bibliothèques javascript Un article pour mieux comprendre les avantages procurés par les services de Google et de Yahoo qui permettent de ne pas héberger soi-même certaines librairies Javascript (Mootools, JQuery, …) […]

Par : Éric

Éric — Wed, 18 Feb 2009 20:40:33 +0000

Il est vrai Julien.

Notes bien toutefois que le cache DNS du navigateur expire très vite. Quelques minutes je crois (il faudrait que je teste ceci dit, ne me croyez pas sur parole). Résultat on va très souvent sur le DNS du FAI ou de l’entreprise quand même (pas plus loin, il est vrai), et ça fait un aller-retour (aller-retour proche, mais aller-retour).

Reste aussi que dans trop de grosses entreprises en France, les services informatiques internes sont assez mal foutus : lents, surchargés, et pas toujours localisés correctement (j’ai vu des grosses sociétés avec un proxy à l’autre bout de la France, d’autres avec un serveur dns interne placé chez un hébergeur et tous les paquets sortent sur Internet pour faire les résolutions)

Mais tu as raison, quand c’est bien foutu la résolution dns ne devrait pas prendre plus de 30 à 40 ms.

Par : julien-pauli

julien-pauli — Wed, 18 Feb 2009 17:59:51 +0000

Concernant les requêtes DNS, il faut préciser qu’elles sont elles aussi cachées à plusieurs niveaux.

Si un très grand nombre de site web utilisent les CDN, alors il y a fort à parier que le client a déja envoyé une requête DNS vers le CDN et l’aura en cache localement.

Localement ou pas : en entreprise il existe des caches HTTP (proxy) certes, mais aussi des caches DNS au niveau du réseau, au pire, le FAI propose son cache (particuliers ou entreprise).

A voir…

Par : Éric

Éric — Wed, 18 Feb 2009 17:38:21 +0000

Ce que je propose c’est bien d’utiliser directement les liens. Les loaders, qu’ils soient à Yahoo! ou à Google, je ne suis pas convaincu de l’intérêt. Tu sais ce dont tu as besoin, tu n’as pas besoin d’un loader pour te construire l’url. Tu cherches l’URL et tu la met en dur.

Les callback que tu désignes sont là pour faire les requêtes Ajax de chargement, je doute qu’il faille y voir autre chose.

Sinon le problème auquel je fais référence n’est pas lié à leur capacité de calcul, mais au simple fait que, que ce soit pour le loader ou le fichier final, si la copie est déjà en cache, rien ne circule sur le réseau. Leurs serveurs ne reçoivent aucune requête. C’est d’ailleurs un des buts de ces caches. Du coup difficile de faire des stats (sauf à extrapoler gravement à partir de ceux qui arrivent avec un cache vide, mais c’est vraiment de l’extrapolation peu pertinente)

Par : François

François — Wed, 18 Feb 2009 17:26:06 +0000

Si il n’y avait que le lien direct vers le fichier, je serai d’accord sur la mise en cache.
Mais il y a toujours des codes du type: google.setOnLoadCallback() et google.load(), je suis pas rentré dans les fonctions mais bon, ça me parait louche 🙂

Google utiliserai les services d’un CDN externe type Akamai, il ne pourrait faire aucune stats on est d’accord. Mais si Gooogle est connu pour quelques choses c’est ces datacenter et sa capacité de calcule…
Et surtout il n’e sagit pas d’invidualiser les appels des fichiers JS au niveau users mais de classer les domaines dans les referer du fichier, ca doit être carrément plus facile.

Par : Éric

Éric — Wed, 18 Feb 2009 10:57:02 +0000

En fait non François. C’est d’ailleurs le concept même.

ils pourront avoir un très mauvais ordre d’idée, et encore …

Le principe c’est que celui qui a la lib en cache risque de la garder plusieurs semaines. Il est justement impossible de savoir s’il fait un bounce (l’information la plus importante pour Google), s’il visite une ou plusieurs pages …. ou même de détecter s’il visite 150 autres sites qui contiennent la même bibliothèque javascript.

Je doute très fortement qu’ils tentent d’individualiser les référants pour ce genre d’usage, pas sur un CDN en tout cas.

Par : François

François — Wed, 18 Feb 2009 09:38:10 +0000

Petite précision légèrement hors sujet: Utilisez ces librairies permet à Google ou Yahoo de connaitre le trafic de votre site (si vous n’utilisez pas déjà Adsense ou Analytics ou Maps).
Si vous constatez des comportements étrange en SEO après la mise en place, ca peut être lié 🙂

Par : Nicolas F.

Nicolas F. — Wed, 18 Feb 2009 08:37:05 +0000

A propos des libs js, j’avais pensé un moment créer une extension FF qui contenait la majeure partie des bibiliothèques JS et un système de maj afin de limiter les téléchargements de fichiers AJAX qui, chez moi avec un 512K, sont assez longues.

Pas le temps, mais je continue de penser que ça peut-être une bonne idée car ces fichiers sont largement utilisés sur de très nombreux sites. Après, y’a p-ê également moyen de mutualiser leurs instances dans les onglet du navigateur…

Par : Rik

Rik — Tue, 17 Feb 2009 23:29:41 +0000

Je suis hors sujet, je suis un grand méchant mais je me dois de le dire pour la postérité : ne pas utiliser de bibli JS permet de ne pas se poser la question et de gagner sur tous les plans.

Voilà, vous pouvez reprendre une activité normale, merci 🙂

Par : Éric

Éric — Tue, 17 Feb 2009 21:12:02 +0000

Pour YUI, c’est aussi du au fait que la bibliothèque est écrite dès le départ comme une agrégation de plein de petits morceaux. La possibilité de concaténer et d’obtenir un résultat adapté aux besoin fait partie des contraintes spécifiques de YUI, qu’on ne retrouve pas dans prototype.js par exemple.

Ce système de YUI réduit d’ailleurs d’autant l’utilité d’un cache centralisé (parce que les composants chargés seront différents sur chaque site) : pour que le cache mutualisé soit efficace il faut deux sites qui utilisent la même version, avec les mêmes composants.

@Samuel: regrouper en un seul fichier fait une différence, une grande. La question de ce billet est plus de savoir où on stocke le fichier résultat : chez vous ou chez Yahoo!

Par : samuel

samuel — Tue, 17 Feb 2009 21:02:18 +0000

Je travaille depuis peu avec YUI ( la librairie yahoo ) et j’ai choisi d’utiliser les liens centralisés d’abord par simplicité mais pour ce qui est de l’optimisation elle donne la possibilité de groupe tous les téléchargements en un seul fichier…. coté performance je ne saurais dire ce que ça apporte effectivement mais ça ne peut être qu’une bonne chose… il me semble

Par : Lionel Martin

Lionel Martin — Tue, 17 Feb 2009 20:45:14 +0000

Il y a quand même un cas qui n’a pas été cité ici et à propos duquel j’aimerais avoir un avis:

Ces librairies js ne sont pas infaillibles et peuvent contenir des erreurs.
J’ai eu le problème d’un bug dans scriptaculous qui m’a forcé à patcher la librairie moi-même en attendant la correction officielle survenue qques semaines/mois plus tard.

Dans ces conditions, je recommenderais quand même de se garder la possibilité à tout moment de revenir à un hébergement local en attendant l’arrivée de la nouvelle version.

Pour être complet, on peut noter également que Yahoo en plus d’héberger son YUI permet de les concaténer pour éviter de multiplier les requêtes. Je ne crois pas avoir vu ça chez google.