D'où incluez-vous la bibliothèque jQuery? Google JSAPI? CDN?

Il existe plusieurs façons d'inclure jQuery et jQuery UI et je me demande ce que les gens utilisent?

• Google JSAPI
• Site de jQuery
• votre propre site / serveur
• un autre CDN

J'ai récemment utilisé Google JSAPI, mais j'ai constaté qu'il fallait beaucoup de temps pour configurer une connexion SSL ou même uniquement pour résoudre google.com. J'utilise les éléments suivants pour Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

J'aime l'idée d'utiliser Google afin qu'il soit mis en cache lors de la visite d'autres sites et pour économiser la bande passante de notre serveur, mais si cela continue d'être la partie lente du site, je peux changer l'inclusion.

Qu'est ce que tu utilises? Avez-vous eu des problèmes?

Edit: Je viens de visiter le site de jQuery et ils utilisent la méthode suivante:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

Edit2: Voici comment j'ai inclus jQuery sans aucun problème au cours de la dernière année:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

La différence est la suppression de http:. En supprimant cela, vous n'avez pas à vous soucier de basculer entre http et https.

Sans aucun doute, je choisis de faire servir JQuery par les serveurs Google API. Je n'ai pas opté pour la méthode jsapi car je ne tire parti d'aucune autre API Google, mais si cela changeait, je l'envisagerais ...

Premièrement: les serveurs Google api sont distribués à travers le monde au lieu de mon emplacement de serveur unique: des serveurs plus proches signifient généralement des temps de réponse plus rapides pour le visiteur.

Deuxièmement: de nombreuses personnes choisissent d'avoir JQuery hébergé sur Google, donc lorsqu'un visiteur vient sur mon site, il se peut qu'il ait déjà le script JQuery dans son cache local. Le contenu pré-mis en cache signifie généralement des temps de chargement plus rapides pour le visiteur.

Troisièmement: ma société d'hébergement Web me facture la bande passante utilisée. Cela n'a aucun sens de consommer 18k par session utilisateur si le visiteur peut obtenir le même fichier ailleurs.

Je comprends que je place une partie de la confiance sur Google pour servir le bon fichier de script et pour être en ligne et disponible. Jusqu'à présent, je n'ai pas été déçu d'utiliser Google et je continuerai cette configuration jusqu'à ce qu'il soit logique de ne pas le faire.

Une chose mérite d'être soulignée ... Si vous avez un mélange de pages sécurisées et non sécurisées sur votre site, vous souhaiterez peut-être modifier dynamiquement la source Google pour éviter l'avertissement habituel que vous voyez lors du chargement de contenu non sécurisé dans une page sécurisée:

Voici ce que j'ai trouvé:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

MISE À JOUR 9/8/2010 - Certaines suggestions ont été faites pour réduire la complexité du code en supprimant le HTTP et HTTPS et en utilisant simplement la syntaxe suivante:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

De plus, vous pouvez également modifier l'URL pour refléter le numéro majeur jQuery si vous souhaitez vous assurer que la dernière version majeure des bibliothèques jQuery a été chargée:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Enfin, si vous ne souhaitez pas utiliser Google et préférez jQuery, vous pouvez utiliser le chemin source suivant (gardez à l'esprit que jQuery ne prend pas en charge les connexions SSL):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

Une raison pour laquelle vous souhaiterez peut-être héberger sur un serveur externe est de contourner les limitations du navigateur des connexions concurrentes à un serveur particulier.

Cependant, étant donné que le fichier jQuery que vous utilisez ne changera probablement pas très souvent, le cache du navigateur se déclenchera et rendra ce point théorique pour la plupart.

La deuxième raison de l'héberger sur un serveur externe est de réduire le trafic vers votre propre serveur.

Cependant, étant donné la taille de jQuery, il est probable que ce soit une petite partie de votre trafic. Vous devriez probablement essayer d'optimiser votre contenu réel.

jQuery 1.3.1 min ne fait que 18k. Je ne pense pas que ce soit trop de succès à poser sur le chargement de la page initiale. Il sera mis en cache après cela. En conséquence, je l'héberge moi-même.

Si vous souhaitez utiliser Google, le lien direct peut être plus réactif. Chaque bibliothèque a le chemin d'accès répertorié pour le fichier direct. Ceci est le chemin jQuery

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Relisez simplement votre question, y a-t-il une raison pour laquelle vous utilisez https? Ceci est la balise de script que Google répertorie dans leur exemple

<script src="http://www.google.com/jsapi"></script>

Je ne voudrais pas qu'un site public que j'ai développé dépende d'un site externe, et donc, j'hébergerais jQuery moi-même.

Êtes-vous prêt à avoir une panne sur votre site lorsque l'autre (Google, jquery.com, etc.) tombe en panne? Moins de dépendances est la clé.

Avantages: héberger sur Google présente des avantages

• Probablement plus rapide (leurs serveurs sont plus optimisés)
• Ils gèrent correctement la mise en cache - 1 an (nous avons du mal à être autorisés à effectuer les modifications pour obtenir les en-têtes directement sur nos serveurs)
• Les utilisateurs qui ont déjà eu un lien vers la version hébergée par Google sur un autre domaine ont déjà le fichier dans leur cache

Les inconvénients:

• Certains navigateurs peuvent le voir comme inter-domaine XSS et interdire le fichier.
• Particulièrement les utilisateurs exécutant le plugin NoScript pour Firefox

Je me demande si vous pouvez INCLURE à partir de Google, puis vérifier la présence d'une variable globale, ou quelque chose comme ça, et si l'absence de charge de votre serveur?

Il y a quelques problèmes ici. Tout d'abord, la méthode de chargement asynchrone que vous avez spécifiée:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

a quelques problèmes. Les balises de script mettent en pause le chargement de la page pendant leur récupération (si nécessaire). Maintenant, s'ils sont lents à charger, c'est mauvais mais jQuery est petit. Le vrai problème avec la méthode ci-dessus est que parce que le chargement de jquery.js se produit indépendamment pour de nombreuses pages, ils termineront le chargement et restitueront avant que jquery ne soit chargé, donc tout style jquery que vous effectuez sera un changement visible pour l'utilisateur .

L'autre façon est:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Essayez quelques exemples simples comme, avoir un tableau simple et changer l'arrière-plan des cellules en jaune avec la méthode setOnLoadCallback () vs $ (document) .ready () avec une charge statique jquery.min.js. La deuxième méthode n'aura aucun scintillement notable. La première volonté. Personnellement, je pense que ce n'est pas une bonne expérience utilisateur.

À titre d'exemple, exécutez ceci:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

Vous (devriez) voir le tableau apparaître, puis les lignes deviennent jaunes.

Le deuxième problème avec la méthode google.load () est qu'elle n'héberge qu'une plage limitée de fichiers. C'est un problème pour jquery car il est extrêmement dépendant du plug-in. Si vous essayez d'inclure un plugin jquery avec une <script src="...">balise et que google.load()le plugin échouera probablement avec des messages de "jQuery n'est pas défini" car il n'a pas encore été chargé. Je ne vois pas vraiment de solution.

Le troisième problème (avec l'une ou l'autre méthode) est qu'il s'agit d'une charge externe. En supposant que vous ayez quelques plugins et votre propre code Javascript, vous devez au moins deux demandes externes pour charger votre Javascript. Vous feriez probablement mieux d'obtenir jquery, tous les plug-ins pertinents et votre propre code et de le mettre dans un fichier minifié.

De Devriez - vous utiliser l'API Ajax bibliothèques Google pour hébergement? :

En ce qui concerne les temps de chargement, vous chargez en fait deux scripts - le script jsapi et le script mootools (la version compressée ci-dessus). C'est donc deux connexions, plutôt qu'une. D'après mon expérience, j'ai constaté que le temps de chargement était en réalité 2 à 3 fois plus lent que le chargement à partir de mon propre serveur partagé personnel, même s'il provenait de Google, et ma version du fichier compressé était deux fois plus grande que celle de Google. Ceci, même après que le fichier a été chargé et (vraisemblablement) mis en cache. Donc pour moi, puisque la bande passante n'a pas beaucoup d'importance, ça ne va pas avoir d'importance.

Enfin, vous avez le problème potentiel d'un navigateur paranoïaque signalant la demande comme une sorte de tentative XSS. Ce n'est généralement pas un problème avec les paramètres par défaut, mais sur les réseaux d'entreprise où l'utilisateur peut ne pas contrôler le navigateur qu'il utilise, sans parler des paramètres de sécurité, vous pouvez avoir un problème.

Donc, à la fin, je ne peux pas vraiment me voir utiliser l'API Google AJAX pour jQuery au moins (les API les plus "complètes" sont une histoire différente à certains égards), sauf pour publier des exemples ici.

En plus des personnes qui conseillent de l'héberger sur son propre serveur, j'avais proposé de le garder sur un domaine distinct (par exemple static.website.com) pour permettre aux navigateurs de le charger dans un autre fil de contenu. Cette astuce fonctionne également pour toutes les choses statiques, par exemple les images et les CSS.

Je dois voter -1 pour les bibliothèques hébergées sur Google. Ils collectent des données, de style Google Analytics, avec leurs enveloppes autour de ces bibliothèques. Au minimum, je ne veux pas qu'un navigateur client fasse plus que ce que je lui demande de faire, encore moins quoi que ce soit d'autre sur la page. Au pire, il s'agit de la "nouvelle version" de Google de ne pas être maléfique - en utilisant du javascript discret pour collecter plus de données d'utilisation.

Remarque: s'ils ont changé cette pratique, super. Mais la dernière fois que j'ai envisagé d'utiliser leurs bibliothèques hébergées, j'ai surveillé le trafic http sortant sur mon site, et les appels périodiques vers les serveurs Google n'étaient pas quelque chose que je m'attendais à voir.

Je pourrais être old-school à ce sujet, mais je fronce toujours les sourcils sur hotlinking. Google est peut-être l'exception, mais en général, c'est vraiment juste de bonnes manières d'héberger les fichiers sur votre propre serveur.

J'ajouterai cela comme une raison d'héberger localement ces fichiers.

Récemment, un nœud en Californie du Sud sur TWC n'a pas été en mesure de résoudre le domaine ajax.googleapis.com (pour les utilisateurs avec IPv4) uniquement afin que nous n'obtenions pas les fichiers externes. Cela a été intermittent jusqu'à hier (maintenant il est persistant.) Parce qu'il était intermittent, j'avais des tonnes de problèmes pour résoudre les problèmes des utilisateurs SaaS. J'ai passé d'innombrables heures à essayer de comprendre pourquoi certains utilisateurs n'avaient aucun problème avec le logiciel, tandis que d'autres se débattaient. Dans mon processus de débogage habituel, je n'ai pas l'habitude de demander à un utilisateur s'il a désactivé IPv6.

Je suis tombé sur le problème parce que j'utilisais moi-même cette "route" particulière vers le fichier et que j'utilise uniquement IPV4. J'ai découvert le problème avec les outils des développeurs me disant que jquery ne se chargeait pas, puis j'ai commencé à faire des traceroutes etc ... pour trouver le vrai problème.

Après cela, je ne reviendrai probablement jamais sur les fichiers hébergés en externe car: google n'a pas à descendre pour que cela devienne un problème, et ... l'un de ces nœuds peut être compromis avec le détournement de DNS et livrer des js malveillants au lieu du fichier réel. J'ai toujours pensé que j'étais en sécurité dans la mesure où un domaine Google ne tomberait jamais, maintenant je sais que n'importe quel nœud entre un utilisateur et l'hôte peut être un point d'échec.

Je viens d'inclure la dernière version du site jQuery: http://code.jquery.com/jquery-latest.pack.js Elle convient à mes besoins et je n'ai jamais à me soucier de la mise à jour.

EDIT: Pour une application Web majeure, contrôlez-la certainement; téléchargez-le et servez-le vous-même. Mais pour mon site personnel, je m'en fichais. Les choses ne disparaissent pas comme par magie, elles sont généralement obsolètes en premier. Je me tiens suffisamment au courant pour savoir quoi changer pour les prochaines versions.

Voici quelques ressources utiles, l'espoir peut vous aider à choisir votre CDN. MS a récemment ajouté un nouveau domaine pour les bibliothèques de livraison via leur CDN.

Ancien format: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Nouveau format: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Cela ne devrait pas envoyer tous les cookies pour microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Voici quelques statistiques sur les technologies les plus utilisées sur le Web dans toutes les technologies. http://trends.builtwith.com/

L'espoir peut vous aider à choisir.

Si je suis responsable du site « en direct » je mieux d' être au courant de tout ce qui se passe et dans mon site. Pour cette raison, j'héberge moi-même la version jquery-min sur le même serveur ou sur un serveur statique / externe mais de toute façon un emplacement où seul moi (ou mon programme / proxy) peut mettre à jour la bibliothèque après avoir vérifié / testé chaque modification

En tête:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

Fin du corps:

<script type="text/javascript">
google.load("jquery", "version");
</script>

Je l'héberge avec mes autres fichiers js sur mon propre serveur, et, c'est ce point, les combiner et les réduire (avec django-compresser, ici, mais ce n'est pas le point) pour être servi comme un seul fichier js, avec tout le site besoins mis en elle. Vous devrez de toute façon servir vos propres fichiers js, donc je ne vois aucune raison de ne pas y ajouter les octets jquery supplémentaires - certains kbs de plus sont beaucoup moins chers à transférer que plus de demandes à effectuer. Vous n'êtes dépendant de personne et dès que votre js minifié est mis en cache, vous êtes également très rapide.

Au premier chargement, une solution basée sur CDN peut gagner, car vous devez charger les kilo-octets jquery supplémentaires à partir de votre propre serveur (mais sans demande supplémentaire). Je doute cependant que la différence soit perceptible. Et puis, lors d'un premier chargement avec un cache effacé, votre propre solution hébergée sera probablement toujours beaucoup plus rapide, en raison de plus de demandes (et de recherches DNS) nécessaires, pour récupérer la requête CDN.

Je me demande comment ce point n'est presque jamais mentionné et comment les CDN semblent conquérir le monde :)