web-dev-qa-db-fra.com

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

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

  • Google JSAPI
  • le 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 le problème lié à google.com. J'ai utilisé 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 pour 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 à être la partie lente du site, je peux modifier l'inclusion.

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

Edit: vient de visiter le site de jQuery et utilise 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 intégré jQuery sans aucun problème depuis un an:

<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 plus à vous soucier de la commutation entre http et https.

javascriptjquerysslgoogle-ajax-libraries
242
Darryl Hein

Sans aucun doute, je choisis de faire servir JQuery par les serveurs API Google. Je n’ai pas opté pour la méthode jsapi car je n’utilise aucune autre API Google. Toutefois, si cela change jamais, je l’envisage ...

First: Les serveurs api de Google sont répartis dans le monde entier 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ème: De nombreuses personnes choisissent d’héberger JQuery sur Google. Ainsi, lorsqu’un visiteur se rend sur mon site, il est possible 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 courts pour le visiteur.

Troisième: Mon hébergeur me facture pour la bande passante utilisée. Pas de 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 fichier de script correct, 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 que cela devienne logique.

ne chose à souligner ... Si vous avez un mélange de pages sécurisées et non sécurisées sur votre site, vous pouvez modifier dynamiquement le code source de Google pour éviter l'avertissement habituel que vous voyez lors du chargement de contenu non sécurisé dans un site Web. 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>

PDATE 9/8/201 - Certaines suggestions ont été faites pour réduire la complexité du code en supprimant les protocoles 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>

En outre, vous pouvez également modifier l'URL afin de refléter le numéro majeur jQuery si vous voulez 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 (n'oubliez pas 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>
153
Dscoduc

Une des raisons pour lesquelles vous pouvez souhaiter héberger sur un serveur externe est de contourner les limitations du navigateur relatives aux connexions simultanées à un serveur particulier.

Cependant, étant donné que le fichier jQuery que vous utilisez ne changera probablement pas très souvent, le cache du navigateur entrera en jeu et rendra ce point inutile pour la plupart.

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

Cependant, étant donné la taille de jQuery, il y a de fortes chances qu'il s'agisse d'une petite partie de votre trafic. Vous devriez probablement essayer d'optimiser votre contenu actuel.

19
Franci Penov

jQuery 1.3.1 min est seulement 18k. Je ne pense pas que ce soit un succès à demander lors du chargement initial de la page. Ce sera mis en cache après cela. En conséquence, je l’accueille moi-même.

14
Mark Hurd

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

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

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

Acceptez-vous une panne sur votre site lorsque l'autre (Google, jquery.com, etc.) tombe en panne? Moins de dépendances est la clé.

8
slacy

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 lorsqu'elles sont récupérées (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, comme le chargement de jquery.js a lieu indépendamment pour plusieurs pages, le chargement et le rendu du chargement sont terminés avant le chargement de jquery. Ainsi, tout style jquery que vous exécutez sera visible . changer 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 un tableau simple et modifiez l’arrière-plan des cellules en jaune avec la méthode setOnLoadCallback () vs $ (document) .ready () avec un chargement statique jquery.min.js. La deuxième méthode n'aura pas de scintillement notable. Le premier sera. Personnellement, je pense que ce n'est pas une bonne expérience utilisateur.

Par exemple, lancez 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 la table apparaître puis les lignes deviennent jaunes.

Le deuxième problème de la méthode google.load () est qu’elle n’héberge qu’un nombre limité de fichiers. C'est un problème pour jQuery car il dépend extrêmement du plug-in. Si vous essayez d'inclure un plugin jquery avec une balise <script src="..."> et google.load(), le plug-in échouera probablement avec les messages "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 ne s'agit que d'une seule charge externe. En supposant que vous ayez des plugins et votre propre code Javascript, vous avez au moins deux demandes externes pour charger votre code Javascript. Vous feriez probablement mieux d’obtenir jQuery, tous les plug-ins pertinents, votre propre code et de le placer dans un seul fichier.

De Si vous utilisez l'API Ajax Libraries de Google pour l'hébergement? :

En ce qui concerne le temps de chargement, vous chargez en réalité deux scripts: le script jsapi et le script mootools (la version compressée indiqué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é deux à trois fois plus long que celui de mon propre serveur partagé, même s'il provenait de Google, et que ma version du fichier compressé était supérieure de quelques Ko à celle de Google. Ceci, même après que le fichier ait été chargé et (probablement) mis en cache. Donc, pour moi, puisque la bande passante importe peu, cela n’a aucune 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 avoir le contrôle sur le navigateur qu'il utilise, sans parler des paramètres de sécurité susceptibles de poser problème.

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

6
cletus

Les avantages: Héberger sur Google a 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 à apporter les modifications nécessaires pour obtenir les en-têtes sur nos serveurs)
  • Les utilisateurs qui ont déjà 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 un domaine inter-domaines XSS et interdire le fichier.
  • Particulièrement les utilisateurs du plugin NoScript pour Firefox

Je me demande si vous pouvez inclure de Google, puis vérifiez la présence de certaines variables globales, ou de telles variables, et si l'absence de charge de votre serveur?

6
Kristen

En plus des personnes qui conseillent de l'héberger sur son propre serveur, j'avais proposé de le conserver sur un domaine séparé (par exemple, static.website.com) afin de permettre aux navigateurs de le charger séparément des autres threads de contenu. Cette astuce fonctionne également pour tous les objets statiques, comme les images et les CSS.

4
Sergii

Je dois voter -1 pour les bibliothèques hébergées sur Google. Ils collectent des données, 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, encore moins n'importe quoi d'autre sur la page. Au pire, il s'agit de la "nouvelle version" de Google: ne pas être méchant - utiliser du javascript discret pour collecter davantage de données d'utilisation.

Note: 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 de Google n'étaient pas ce à quoi je m'attendais.

4
jro

Je vais ajouter cela comme une raison pour héberger localement ces fichiers.

Récemment, un nœud du sud de la Californie sur TWC n'a pas été en mesure de résoudre le domaine ajax.googleapis.com (pour les utilisateurs dotés d'IPv4), nous ne récupérons donc pas les fichiers externes. Cela a été intermittent jusqu'à hier (à présent, il est persistant). Parce que c'était intermittent, j'avais énormément de problèmes pour résoudre les problèmes de SaaS utilisateur. Nous avons passé d'innombrables heures à essayer de comprendre pourquoi certains utilisateurs ne rencontraient aucun problème avec le logiciel, tandis que d'autres étaient en chute libre. 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 la question parce que j'utilisais moi-même cet "itinéraire" particulier vers le fichier et n'utilisais que IPV4. J'ai découvert le problème avec des outils de développement 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 retournerai probablement jamais vers des fichiers hébergés en externe, car: Google n'a pas besoin de descendre pour que cela devienne un problème, et ... n'importe lequel de ces nœuds peut être compromis avec le piratage DNS et transmettre des messages malveillants. au lieu du fichier réel. J'ai toujours pensé que j'étais en sécurité en ce qu'un domaine Google ne tomberait jamais. Maintenant, je sais que tout nœud entre un utilisateur et l'hôte peut être un point d'échec.

3
basedrop

Je suis peut-être de la vieille école à ce sujet, mais je fronce toujours les sourcils à la recherche de liens. Peut-être que Google est l'exception, mais en général, héberger les fichiers sur votre propre serveur n'est que de bonnes manières.

3
Matt Howell

Voici quelques ressources utiles, espérons peut vous aider à choisir votre CDN. MS a récemment ajouté un nouveau domaine pour les bibliothèques de diffusion 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 la technologie la plus populaire utilisée sur le Web pour toutes les technologies. http://trends.builtwith.com/

L'espoir peut vous aider à choisir.

2
GibboK

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

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

2
geowa4

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

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

Lors du premier chargement, une solution basée sur un CDN peut être gagnante, car vous devez charger les kilo-octets jquery supplémentaires à partir de votre propre serveur (mais sans demande supplémentaire). Je doute que la différence soit notable, cependant. Et puis, lors du premier chargement avec le cache effacé, votre propre solution hébergée sera probablement toujours beaucoup plus rapide, en raison du nombre accru de demandes (et de recherches DNS) nécessaires pour extraire le jQuery CDN.

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

0
benzkji