Google n’arrête pas de caresser les développeurs et les intégrateurs dans le sens du poil. Après des services d’hébergement de code avec Google Code qui permet aux développeurs de gérer leurs développements, Google va plus loin avec Ajax Librairies API qui permet d’échapper à la corvée de l’installation et de la mise à jour des bibliothèques Javascript les plus connues (jQuery, prototype, scrip.aculo.us, MooTools et dojo).
Grâce à Google, il suffit maintenant de placer quelques lignes de Javascript, d’indiquer le framework et sa version et hop, c’est tout ! Lors de la prochaine mise à jour, il suffira de changer le numéro de version. Cerise sur la banane, on peut choisir la version compressée google.load(« jquery », « 1.2.3 »); ou pas google.load(« jquery », « 1.2 », {uncompressed:true});
Il est également possible de se passer du script en faisant un hotlink sur le script hébergé sur les serveurs de Google : http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js ou http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.js pour la version non compressée.
Avec ce programme, l’objectif de Google est de proposer son API pour simplifier l’Ajax afin de promouvoir ces différents services comme son moteur de recherche ou son service de cartographie. Reste à évaluer les performances, mais je pense que l’on peut faire confiance à Google pour ça 😉
Oui ils ont souvent de bonnes idées chez google ^^
D’ailleurs ils m’ont donné envie de créer un projet similaire que l’on pourrait hébergé sur son propre serveur, mais avec plusieurs options supplémentaires auxquels j’ai pensé ! Bon maintenant faut que je trouve le temps de le faire (et mes 3 semaines de vacances dès la semaine prochaine ne vont pas aider ^^) 😉
Mouaip l’idée est bonne mais je pense que ce que nous fera Julien sera nettement mieux et surtout bien plus intelligent que ce que propose Google… Quand on voit la latence que peut provoquer le chargement d’une ou surtout plusieurs librairies distantes sur un site, je n’ose imaginer l’impact que pourra avoir à terme le chargement d’une librairie critique pour l’utilisation/utilisabilité d’un site web une fois le service largement répandu et utiliser par les intégrateurs.
Déjà que je trouvais relativement idiot de recharger une lib déjà présente dans le core d’une webapp, si en plus on va la charger de façon distante… :s
Bref, j’attends plutôt sur le portage local de Julien pour ma part :p (ça c’est pour bien te mettre la pression ;))
Pour moi c’est clairement FireFox et les nav alternatif qui devrait embarquer cela ainsi pas besoins de serveur et de perf car il y aura dès fois ou même si on s’appel google des indispos ou des latences (y a qu’a voir google analytics ou adscence qui rame par moment) et puis tout le monde n’a pas l’ADSL non plus.
@julien et @burningHat : ce genre de truc en local n’a plus aucun intérêt ! Le but c’est justement d’accélérer le chargement des pages web en mettant les lib JS sur les serveurs de Google, à priori connecté avec une grosse grosse bande passante. Mais c’est pas ça qui fait gagner du temps !
Le truc c’est que les navigateurs ont un cache, mais que le cache est gérer en fonction de l’url de la ressource, du coup si on va sur 15 sites qui utilisent jQuery, même si c’est le même fichier, on va le charger au moins 15 fois (et aussi l’avoir 15 fois en cache…). Avec ce que propose Google, si vraiment plein de sites et des gros sites utilisent cette solution alors quelque soit le site qu’on visite la lib javascript est déjà dans le cache et le navigateur de sait : c’est la même que celle de l’autre site puisque elle a la même url.
Donc faire la même chose en local, j’vois pas l’intérêt…
@francis: c’est vrai que ça serait l’idéal, mais après faut gérer en fonction du navigateur du visiteur de savoir si telle ou telle lib est déjà chargée ou pas, la chargée si elle ne l’est pas… C’est un peu remplacer un script par un autre, et pas complètement puisqu’on ne peut pas se passer des lib pour ceux qui n’ont pas un navigateur qui les preload.
@burningHat
Oh hé l’autre, comment il essai de me mettre la pression 🙂
@p4bl0
Oui et non. Car même si c’est en local, tu gardes l’avantage de déclencher le chargement d’une framework uniquement lorsque c’est nécessaire (if, try, etc…), donc grosse économie de bande passante dans certains cas ! De plus, si tu as plusieurs sites, rien ne t’empêche de mettre l’appli local sur un des sites (ou direct depuis un dossier sur ton serveur) et de l’appeler depuis tous les autres … donc aucun framework a ré-uploadé, gain de cache également (bon ok, à moins grande échelle que google) et facilité de mise à jour. Bref, on garde quand même pas mal d’avantages sans compter les nouvelles options que j’ai en tète) 😉
Je n’y connais pas grand chose en ce qui concerne les performances, mais je constate que pour jQuery 1.2.3, les fichiers hébergés par Google font:
* 30 Ko (98 Ko décompressé) pour la version normale;
* 16 Ko (56 Ko décompressé) pour la version minifiée.
Si je ne m’abuse, pour pouvoir envoyer un fichier compressé (avec gzip il me semble), il faut 1) que le navigateur l’accepte (ce qu’il déclare dans les en-têtes HTTP qu’il envoie) et 2) que le serveur soit configuré pour. Et, toujours sauf erreur de ma part, aAujourd’hui la plupart des navigateurs acceptent les fichiers compressés mais beaucoup de serveurs ne sont pas configurés pour. Donc pour un petit site qui n’utilise pas son propre serveur mais un hébergement mutualisé, ça peut être intéressant, si les serveurs Google tiennent la route.
L’idée soulevée par p4bl0 — que ça permette, le cas échéant, de profiter d’une bibliothèque JS déjà mise en cache parce que le visiteur aurait chargé le même fichier depuis un autre site — est intéressante également.
Donc la question principale pour moi est: peut-on se reposer sur Google? Les serveurs de Google API seront-ils toujours réactifs, et les fichiers proposés seront-ils disponibles à la même adresse, avec toujours la même réactivité, pour plusieurs années d’affilée?
@julien > je dois manquer d’imagination, mais je ne vois pas à quoi pourrait ressembler un projet similaire en local, alors que l’objectif est justement de faire du hotlinking sur des scripts distants pour éviter d’avoir à gérer les scripts chez soi ;)) A quelles options penses-tu ?
@burningHat > la question de la latence m’interroge aussi. Tu pourras peut-être éclairer ma lanterne à ce sujet parce que j’ai l’impression qu’on imagine souvent que le chargement d’un script distant est plus long qu’en « local » (c’est à dire finalement placé sur un serveur également…).
Et donc, je me demande si une requête sur « css4design.com/script.js » prend vraiment plus de temps que sur « code.google.com/script.js » sachant que j’imagine que la résolution des IP et tutti quanti doit se faire plus rapidement si l’URL est relative, mais comme la plupart des templates WordPress utilisent des variables comme « template_url » qui écrivent l’adresse complète…. Bref, tu m’as compris 😉
@francis > j’ai lu quelque chose à ce sujet, mais je ne suis pas convaincu et à ce sujet je partage assez les arguments de p4bl0. Mais bon, il faut tester à fond pour pouvoir trancher définitivement 😉
@p4bl0 > Très bonne présentation d’arguments qui militent en faveur du hotlink, donc. Merci 😉
@Florent v. > C’est sûr que c’est pas évident de passer le pas du hotlinking pour les raison de disponibilité dans le temps des services qui proposeront d’héberger des scripts et autres (ne doutons pas que l’initiative de Google fera des petits).
Mais bon, au pire, vu qu’en bon intégrateur tu t’assures que ton site fonctionne sans javascript… Il suffira, le jour où les serveurs de Google tomberont, de travailler à l’ancienne, c’est à dire comme aujourd’hui 😉
Hier soir je suis tombé sur un blog qui patinait dans la semoule à charger ce qu’il lui fallait depuis Flickr parce que:
1. l’appel au script était dans l’entête du site au lieu d’être prêt de la fin du fichier (erreur de débutant, certes, mais du coup on se retrouve à attendre bêtement l’affichage)
2. bah apparemment soit je suis tombé à un mauvais moment pour Flickr soit la liaison entre le script php du blog et Flickr était totalement foireuse (requête bâclée ou que sais-je)
Et c’est pas anodin, ça arrive régulièrement… Avec Google Analytic et AdSense comme le disait si bien Francis (d’ailleurs j’ai clairement remarqué une meilleure fluidité à mon expérience de surf depuis que j’ai bloqué Google Analytic, Google Syndication et autres sur mon NoScript).
Rien que ça, ça m’encourage à me dire que déléguer à outrance des ressources plus ou moins critiques de son site aux autres sous couvert de « c’est-trop-web-2.0-attitude » sans réfléchir plus que ça est idiot!
Pour répondre à ta question Bruno, la résolution d’un hardlink « local » sera toujours plus rapide pour le serveur web de l’hôte que celle d’un site distant parce que le DNS de l’hôte résoudra une adresse de sa zone propre sans avoir à faire appel aux redirecteurs… Si le serveur est sous ton contrôle propre, tu pourras même te passer d’une requête sur un DNS quelconque et taper directement sur le fichier hosts local pour gagner encore. Cependant, ça reste assez trivial sur le temps de chargement ce point-là.
Ce qui est trivial aussi c’est le chargement d’une lib, c’est pas sur ça qu’un webmaster ou un intégrateur compétent va gagner une seconde en le chargeant depuis son propre hosting franchement (surtout pas en déléguant à des serveurs soumis à des latences plus ou moins grandes pour rappeler mon exemple précédent). Au mieux quelques micro-secondes et au premier chargement seulement en plus ! Et c’est pas cher payé pour avoir une version « sous contrôle », qui répondra toujours au besoin de votre appli car connue à priori et surtout maîtrisée dans le temps (personne ne vous la changera sans vous demander votre avis sous prétexte que la nouvelle est plus mieux bien ou qu’on a conclu un juteux accord avec tel partenaire qui ne veut plus que cette lib-là mais pas celle-ci par exemple).
D’ailleurs si vous faites des benchs pour voir où ça pêche dans vos applis, vous constaterez certainement que c’est pas la lib jQuery qui met le plus de temps à se charger (par contre les images, le contenu puis tous les plugins que vous avez ajouté à votre lib plus vos scripts perso… là c’est une autre musique)
Bref, à part donner encore un peu plus d’importances aux serveurs de Google, je ne vois pas d’argument valable à l’utilisation de la méthode proposée par ces derniers en réalité.
Surtout un truc qui me chiffonne totalement dans la logique de l’intégrateur: on préfèrerait et trouverait plus logique d’aller chercher une lib sur les serveurs de google plutôt que d’utiliser celle qui est déjà incluse les 4/5 du temps dans le core du CMS ou du framework qu’on utilise pour développer… ça m’épate franchement comme raisonnement moi !
Je conclurais sur une note personnelle: comme tous ceux un tant soit peu soucieux de la sécurité et de la vie privée (et ceux qui font du développement web), j’ai une forte tendance à flusher régulièrement mon cache et à le faire de toutes façons automatiquement à la fermeture de mon navigateur.
Merci @burn’ pour ces explications complètes. Je me demandais si j’allais utiliser ce système dans mon nouveau template, du coup, je crois que je vais suivre ton avis sur la question.
Bien vu le coup de la résolution des DNS : on sent le professionnel des réseaux 😉
@BurningHat quand tu dis « plutôt que d’utiliser celle qui est déjà incluse les 4/5 du temps dans le core du CMS ou du framework » tu tapes dans le mille.