Où incluez-vous la bibliothèque jQuery à partir? Google JSAPI? CDN?

Question

Il y a quelques façons d'inclure jQuery UI et jQuery et je me demande ce que les gens utilisent?

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

Je l'ai récemment utilisé Google JSAPI, mais ai trouvé qu'il faut beaucoup de temps pour installer une connexion SSL ou même seulement 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 il est donc mis en mémoire cache lors de la visite d'autres sites et pour économiser la bande passante de notre serveur, mais si elle continue à être la partie lente du site, je peux changer le comprennent.

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

Modifier Juste visité 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 jQuery sans y compris les problèmes de l'année dernière:

<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, vous n'avez pas à vous soucier de la commutation entre http et https.

Answer 1

Sans aucun doute je choisir d'avoir JQuery servi par les serveurs API Google. Je ne suis pas avec la méthode JSAPI puisque je ne tirent parti de toute autre Google API, les si jamais changé que je le considérerais ...

Première: Les serveurs de Google api sont distribués à travers le monde au lieu de mon seul emplacement du serveur:. Serveurs Closer signifie généralement plus rapidement les temps de réponse pour le visiteur

Deuxième: Beaucoup de gens choisissent d'avoir JQuery hébergé sur Google, alors quand un visiteur vient sur mon site, ils peuvent déjà avoir le script JQuery dans leur cache local. contenu pré-cache signifie généralement plus rapides temps de charge pour le visiteur.

Troisième: Ma société d'hébergement Web me charge pour la bande passante utilisée. Aucun sens consommation 18k par session utilisateur si le visiteur peut obtenir le même fichier ailleurs.

Je comprends que je place une partie de confiance sur Google pour servir le fichier de script correct, et être en ligne et disponibles. Jusqu'à ce point, je ne l'ai pas été déçu par l'utilisation de Google et continuera cette configuration jusqu'à ce qu'il est logique de ne pas.

Une chose à remarquer ... Si vous avez un mélange de pages sécurisées et non sécurisées sur votre site, vous pouvez modifier dynamiquement la source de Google pour éviter l'avertissement habituel que vous voyez lors du chargement de l'insécurité contenu dans une page sécurisée:

Voici ce que je suis venu avec:

<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 - Quelques suggestions ont été faites pour réduire la complexité du code en supprimant le HTTP et HTTPS et il suffit d'utiliser 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>

En outre, vous pouvez également changer l'URL pour refléter le nombre important jQuery si vous vouliez vous assurer que la dernière version majeure des bibliothèques jQuery ont été chargés:

<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 voulez pas utiliser Google et préférez jQuery vous pouvez utiliser le chemin source suivante (garder à 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>

Answer 2

Une raison pour laquelle vous voudrez peut-être héberger sur un serveur externe est de contourner les limitations du navigateur de connexions concurent au serveur particulier.

Cependant, étant donné que le fichier jQuery que vous utilisez ne sera probablement pas changer très souvent, le cache du navigateur et lancera faire ce point discutable 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, les chances sont que ce sera une petite partie de votre trafic. Vous devriez probablement essayer d'optimiser votre contenu.

Answer 3

jQuery 1.3.1 min est seulement 18k taille. Je ne pense pas que ce soit trop d'un coup de demander à la charge de la page initiale. Elle sera mise en mémoire cache après. En conséquence, je serai l'hôte moi-même.

Answer 4

Si vous souhaitez utiliser Google, le lien direct peut être plus réactif. Chaque bibliothèque a le chemin indiqué 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>

Il suffit de relire votre question, est-il une raison que vous utilisez https? Ceci est la balise de script listes Google dans leur exemple

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

Answer 5

Je ne voudrais pas que tout site public que j'ai développé à dépendre d'un site externe, et donc, je me jQuery hôte.

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

Answer 6

Plus: hôte sur Google a des avantages

• Probablement plus rapidement (leurs serveurs sont plus optimisés)
• Ils gèrent la mise en cache correctement - 1 an (nous luttons pour être autorisés à faire les changements pour obtenir les en-têtes à droite 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

Moins:

• Certains navigateurs peuvent voir comme interdomaine XSS et désavouer le fichier.
• particulièrement les utilisateurs exécutant le plugin NoScript pour Firefox

Je me demande si vous pouvez inclure de Google, puis vérifiez la présence d'une variable globale, ou somesuch, et si la charge d'absence de votre serveur?

Answer 7

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

<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. balises de script pause la charge de la page alors qu'ils sont récupérés (le cas échéant). Maintenant, s'ils sont lents à charger c'est mauvais, mais jQuery est faible. Le vrai problème avec la méthode ci-dessus est que, parce que la charge de jquery.js se produit indépendamment pour de nombreuses pages, ils termineront le chargement et le rendu avant jquery a chargé de sorte que toute jquery vous coiffant ne 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, une table simple et changer l'arrière-plan des cellules au jaune avec la méthode setOnLoadCallback () vs $ (document) .ready () avec une charge de jquery.min.js statique. La deuxième méthode aura pas de scintillement perceptible. La première volonté. Personnellement, je pense que c'est pas une bonne expérience utilisateur.

À titre d'exemple exécuter 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>

(si) voir le tableau apparaît, puis les lignes jaunir.

Le deuxième problème avec la méthode google.load () est qu'il accueille une gamme limitée de fichiers. Ceci est un problème pour jquery car il est plug-in très dépendante. Si vous essayez d'inclure un plugin jquery avec une étiquette de <script src="..."> et google.load() le plugin va probablement échouer avec les messages de « jQuery n'est pas défini » parce qu'il n'a pas encore chargé. Je ne vois pas vraiment une façon de contourner cela.

Le troisième problème (avec ou l'autre méthode) est qu'ils sont une charge externe. En supposant que vous avez des plugins et votre propre code Javascript que vous êtes à un minimum de deux requêtes externes à charger votre Javascript. Vous êtes probablement mieux obtenir jquery, de tous les plug-ins pertinents et votre propre code et de le mettre dans un fichier minified.

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

  

Pour ce qui est temps de chargement, vous êtes réellement   deux scripts de chargement - le script JSAPI   et le script Mootools (le   version comprimée ci-dessus). Alors   soit deux connexions, plutôt que   un. Dans mon expérience, je trouve que   le temps de chargement était en fait 2-3 fois   plus lent que le chargement de ma propre   serveur partagé personnel, même si elle   provenait de Google, et ma version   du fichier compressé était deux   K plus grand que Google. Cela, même   Une fois le fichier chargé et avait   (Probablement) mis en cache. Donc, pour moi, depuis   la bande passante ne pas beaucoup d'importance,   ne va pas à la matière.

Enfin, vous avez le problème potentiel d'un navigateur paranoïaque signalant la demande comme une sorte de tentative XSS. Il 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 avoir le contrôle sur le navigateur qu'ils utilisent encore moins les paramètres de sécurité que vous pouvez avoir un problème.

Donc à la fin, je ne peux pas me voir vraiment en utilisant l'API Google AJAX pour jQuery au moins (plus API « complets » sont une autre histoire, à certains égards) beaucoup, sauf pour poster des exemples ici.

Answer 8

En plus des personnes qui conseils pour l'héberger sur propre serveur, je propose de le garder sur le domaine séparé (par exemple static.website.com) pour permettre aux navigateurs pour le charger dans séparément des autres fil contenu. Cette astuce fonctionne aussi pour tous les éléments statiques, dites images et css.

Answer 9

Je dois voter -1 pour les bibliothèques hébergées sur Google. Ils recueillent des données, Google Analytics style, avec leur emballage autour de ces bibliothèques. Au minimum, je ne veux pas un navigateur client faire plus que je demande à faire, beaucoup moins quoi que ce soit d'autre sur la page. Au pire, cela est « nouvelle version » de Google de ne pas être mal -. Utilisant javascript discret pour recueillir plus de données sur l'utilisation

Note: si elles ont changé cette pratique, super. Mais la dernière fois que je considérais à l'aide de leurs bibliothèques hébergées, je surveillé le trafic sortant http sur mon site, et les appels périodiques sur les serveurs de Google n'étaient pas quelque chose que je m'y attendais à voir.

Answer 10

Je pourrais être vieille école à ce sujet, mais je froncer les sourcils toujours sur hotlinks. Peut-être que Google est l'exception, mais en général, il est vraiment juste de bonnes manières pour héberger les fichiers sur votre propre serveur.

Answer 11

Je vais ajouter ceci comme une raison d'accueillir ces fichiers localement.

Récemment, un noeud 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) seulement si nous ne recevons pas les fichiers externes. Cela a été Intermittant jusqu'à hier (maintenant il est persistant.) Parce qu'il était intermittant, je faisais des tonnes de problèmes Résolution des problèmes d'utilisateur SaaS. Nous avons passé d'innombrables heures à essayer de suivre pourquoi certains utilisateurs avaient aucun problème avec le logiciel, et d'autres ont été tanking. Dans mon processus de débogage d'habitude je ne suis pas l'habitude de demander à un utilisateur s'ils ont IPv6 désactivé.

Je suis tombé sur la question parce que je me servais de cette « route » particulière au dossier et aussi je utilise uniquement IPV4. J'ai découvert le problème avec des outils développeurs me disant jquery ne chargeait pas, puis a commencé à faire traceroute etc ... pour trouver la vraie question.

Après cela, je vais très probablement jamais revenir à l'extérieur des fichiers hébergés parce que: Google ne doit pas descendre pour que cela devienne un problème, et ... un de ces nœuds peut être compromis avec DNS et détournement d'avion livrer js malicieux au lieu du fichier réel. Toujours pensé que j'étais en sécurité en ce qu'un domaine Google ne serait jamais aller vers le bas, maintenant je sais un nœud entre un utilisateur et l'hôte peut être un point échec.

Answer 12

ajoutez seulement la dernière version du site jQuery: http: // code. jquery.com/jquery-latest.pack.js Il convient à mes besoins et je ne jamais avoir à vous soucier de la mise à jour.

EDIT: Pour une application web importante, contrôler certainement; télécharger et servez-vous. Mais pour mon site personnel, je ne pouvais pas moins de soins. Les choses ne disparaissent pas comme par magie, ils sont généralement déconseillés en premier. Je continue avec assez de savoir ce qu'il faut changer pour les versions ultérieures.

Answer 13

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

Old 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 la technologie la plus populaire utilisée sur le web à travers toutes les technologies. http://trends.builtwith.com/

L'espoir peut vous aider à choisir.

Answer 14

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

Answer 15

Dans la 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>

Answer 16

je serai l'hôte avec mes autres fichiers js sur mon propre serveur, et, c'est ce point, combiner et rapetisser les (avec django-compresser, ici, mais ce n'est pas le point) pour être servi comme un seul fichier js, avec tout les besoins du site mis. Vous aurez besoin de servir vos propres fichiers js de toute façon, donc je ne vois aucune raison de ne pas ajouter les octets supplémentaires jquery là aussi - certains plus kbs sont beaucoup plus moins coûteux de transférer, que plus de demandes à effectuer. Vous n'êtes pas dépendant à personne, et dès que vos minified js sont mises en cache, vous êtes super rapide aussi bien.

Lors de la première charge, une solution CDN pourrait gagner, parce que vous devez charger les kilooctets jquery supplémentaires à partir de votre propre serveur (mais, sans une demande supplémentaire). Je doute que la différence est notable, cependant. Et puis, sur une première charge avec le cache effacé, votre propre solution hébergée sera probablement toujours beaucoup plus rapide, en raison de plus de demandes (et les recherches DNS) nécessaires, pour aller chercher le jquery CDN.

Je me demande comment ce point est presque jamais mentionné, et comment CDNs semblent dominer le monde :)