Cache central des bibliothèques javascript

On m’a posé quelques fois la question alors voici la réponse : Oui.

Oui il faut, quand vous le pouvez, utiliser les liens centralisés de Google ou de Yahoo pour vos bibliothèques javascript. Je parle de ne pas recopier jquery ou yui directement sur vos serveurs, mais d’utiliser les liens centralisés proposés par les deux moteurs de recherche.

Voilà pour la réponse générique, ensuite on peut détailler un peu.

Content delivery network

Le premier gain c’est l’utilisation des CDN de Yahoo! et de Google. Le principe du CDN c’est plus ou moins placer des serveurs dans plusieurs pays, voire directement chez les FAI, pour que le trajet fait sur le réseau soit le plus court possible. On vise une latence réduite. La latence ça peut tuer un site web.

Seuls les plus gros sites web peuvent s’offrir des CDN. Profiter de Yahoo! ou Google c’est toujours appréciable.

Maintenant vous n’utiliserez qu’une seule grosse bibliothèque javascript. En échange vous allez utiliser un nom de domaine supplémentaire, donc une requête DNS supplémentaire et une connexion de plus. Le deal est intéressant si ce qu’on gagne en latence dépasse ce que coûte la requête DNS.

Soyons clairs, si vos contenus ne sont pas sur le même continent qu’une partie sensible de vos clients, alors c’est un bon deal, n’hésitez pas. Aux États-Unis, éviter de traverser de l’Alaska vers New-York, c’est du temps gagné, non négligeable. Mais en même temps les sociétés vraiment internationales ont déjà souvent un hébergement par pays ou continent, ou utilisent déjà un CDN.

Si vous restez en Europe occidentale ça devient déjà moins clair. Si vous êtes hébergés en France dans un gros datacenter et que vos clients sont en France … là pas sur que le bénéfice du CDN soit réel. Les FAI ont des liens de peering entre eux et avec les hébergeurs français, la latence est globalement faible dès le départ. (Note: ceci n’a pas été vérifié par des tests, je suis preneur d’avis et de retours d’expérience sur la pertinence de CDN pour un trafic français avec un hébergement en France)

Nombre de domaines

Le second aspect de ces caches centralisés c’est le fait qu’ils sont justement sur un domaine séparé. Il y a du pour et du contre.

Dans le pour, votre Javascript peut être téléchargé immédiatement même si les files de téléchargement sont déjà occupées avec d’autres éléments de votre site. Maintenant comme on définit souvent ce genre de bibliothèques javascript tout en haut de page, les files de téléchargement sont généralement vides à ce moment là de toutes façons. Bref, je ne suis pas convaincu.

Toujours dans le pour, si votre navigateur est très récent (comprendre : IE 8, Safari 4, Firefox 3.1) le javascript ne bloque pas les autres téléchargements. Là aussi, avoir un domaine différent évite d’utiliser un slot dans vos autres téléchargements. En pratique, avec six slots simultanés minimum sur ces navigateurs, je ne suis pas convaincu que cela fasse une différence fondamentale.

Bref, pas convaincu, sachant qu’il y a du contre qui s’ajoute : avec un nom de domaine en plus, comme on l’a vu, il y a une requête DNS supplémentaire. Est-ce que ça vaut le coup pour un unique fichier ? pas sûr du tout.

Cache centralisé

Troisième aspect, en utilisant les liens de Google et Yahoo! on finit par tous utiliser les mêmes URL pour nos bibliothèques javascript.

Le résultat c’est que pour les bibliothèques les plus populaires, cela augmente la probabilité que vous l’ayez déjà en cache à cause d’un site précédent. Là le gain est important, surtout pour vos pages d’accueil (celles qui ont le plus gros trafic « cache vide »). Reste qu’en réalité l’URL contient la version de la bibliothèque et tous les sites n’utilisent pas les mêmes versions, ou même les mêmes bibliothèques. La mutualisation est assez limitée et le gain reste à prouver.

L’avantage concret est par contre visible pour les entreprises et pour les universités. Ces dernières ont des proxys cache qui auront toutes les chance d’avoir déjà votre bibliothèque en cache, dans la bonne version. Sur la cinquantaine (ou le millier) de collègues, il y en aura bien un qui aura téléchargé la bibliothèque avant vous.

La question est donc, vos visiteurs sont-ils sur des lignes professionnelles ou des lignes de particuliers ? dans ce second cas le gain n’est pas évident.

Mais alors, pourquoi répondre « oui » ?

Parce que je parlais jusqu’à maintenant du cas idéal. Si vous avez déjà un CDN, que vos ressources statiques sont déjà sur domaine séparé, et que vos entêtes de cache sont bien réglées, alors gardez vos bibliothèques chez vous. Mais … ce n’était le cas pour aucun de ceux qui m’ont posé la question.

En fait je doute que ce soit le cas pour quiconque se pose la question. Ceux qui ont déjà fait tout le chemin de performance avec CDN, domaine tiers et entêtes de cache, ils ont souvent les moyens de tester eux même quelle est la meilleure solution. Ou mieux, ils ont déjà réalisé que pour éliminer une requête HTTP il faut déjà fusionner leur bibliothèque javascript avec leur code javascript spécifique. Bref, la question est sans objet pour eux.

Pour les autres, qui n’ont pas les moyens d’utiliser un CDN quand bien même ils en auraient besoin, ou qui n’ont pas déjà un domaine séparé pour les ressources statiques, ou qui ne gèrent pas correctement leurs entêtes de cache, pour eux c’est intéressant. Ce n’est pas parfait, mais c’est un mieux, une démarche d’amélioration progressive. Pour vous, qui vous posez la question, la réponse est probablement « oui, utilisez les liens de Yahoo et Google pour vos bibliothèques javascript ». Et puis … ça fait autant de bande passante en moins à payer.

En cas de doute, le « oui » a plus de chance d’être positif ou sans effet que de réellement être négatif.

Publié par edaspet

Plus d'informations sur mon profil en ligne

12 réponses sur « Cache central des bibliothèques javascript »

  1. 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.

  2. 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

  3. 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!

  4. 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 🙂

  5. 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…

  6. 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é 🙂

  7. 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.

  8. 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.

  9. 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)

  10. 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…

  11. 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.

Les commentaires sont fermés.