D'où incluez-vous la bibliothèque jQuery? Google JSAPI? CDN?
Il y a quelques 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 faut beaucoup de temps pour configurer une connexion SSL ou même seulement pour résoudre google.com. j'ai utilisé ce qui suit 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 donc il est mis en cache lors de la visite d'autres sites et pour économiser la bande passante de notre serveur, mais si elle continue d'être la partie lente du site, je peux changer l'inclusion.
Qu'utilisez-vous? Avez-vous eu des problèmes?
Edit: vient 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 pour 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 cela, vous n'avez pas besoin de vous inquiéter commutation entre http et https.
16 réponses
Sans aucun doute, je choisis D'avoir jQuery servi par les serveurs de L'API Google. Je ne suis pas allé avec la méthode jsapi puisque je ne tire pas parti d'autres API Google, mais si cela changeait, je le considérerais...
Premièrement: les serveurs de l'api Google 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: beaucoup de gens choisissent D'avoir jQuery hébergé sur Google, donc quand un le visiteur vient sur mon site, il peut déjà avoir 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. Aucun sens consommant 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 pour être en ligne et disponible. Jusqu'à ce point, je n'ai pas été déçu par L'utilisation de Google et continuera cette configuration jusqu'à ce qu'il soit logique de ne pas.
Une chose mérite d'être souligné... 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 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 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é de le code en supprimant le HTTP et HTTPS et utilisez 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 pour refléter le nombre 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 voulez 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 pouvez héberger sur un serveur externe est de contourner les limitations du navigateur des connexions concurentes à 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 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, compte tenu de la taille de jQuery, les chances sont que ce sera un petit une partie de votre trafic. Vous devriez probablement essayer d'optimiser votre contenu réel.
Jquery 1.3.1 min est seulement 18k en taille. Je ne pense pas que ce soit trop difficile à demander lors du chargement initial de la page. Il sera mis en cache après ça. En conséquence, je l'héberge moi-même.
Si vous souhaitez utiliser Google, le lien direct peut être plus réactive. Chaque bibliothèque a le chemin répertorié 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? C'est la balise de script Google lists dans leur exemple
<script src="http://www.google.com/jsapi"></script>
<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.) descend? Moins de dépendances est la clé.
Avantages: L'hôte sur Google a des avantages
- probablement plus rapide (leurs serveurs sont plus optimisés)
- ils gèrent la mise en cache correctement - 1 an (nous avons du mal à être autorisés à apporter les modifications pour obtenir les en-têtes 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
Inconvénients:
- Certains navigateurs peuvent le voir comme XSS Cross-domain et interdire le fichier.
- en particulier les utilisateurs exécutant le plugin NoScript pour Firefox
Je me demande si vous pouvez inclure de Google, puis vérifier la présence d'une variable globale, ou somesuch, et si l'absence 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 interrompent le chargement de la page pendant qu'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 parce que le jquery.le chargement js se produit indépendamment pour de nombreuses pages, elles finiront le chargement et le rendu avant le chargement de jquery, de sorte que tout style jQuery que vous effectuerez 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 une table simple et changer l'arrière-plan des cellules en jaune avec la méthode setOnLoadCallback() vs $(document).ready() avec un jQuery statique.min.charge js. La deuxième méthode n'aura pas de scintillement notable. La première sera. 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 la table apparaître, puis les lignes vont jaune.
Le deuxième problème avec google.la méthode load() est qu'elle n'héberge qu'une gamme limitée 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 le moyen de contourner ça.
Le troisième problème (avec l'une ou l'autre méthode) est qu'ils sont une charge externe. En supposant que vous avoir des plugins et votre propre code Javascript vous êtes jusqu'à un minimum de 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é.
À partir de devriez-vous utiliser L'API Ajax Libraries de Google pour L'hébergement?:
En ce qui concerne les temps de chargement, vous êtes en fait chargement de deux scripts - le script jsapi et le script mootools (le version compressée d'en haut). Si que est deux connexions, plutôt que un. Dans mon expérience, j'ai trouvé que le temps de chargement était en fait 2-3 fois plus lent que le chargement de mon propre personnels serveur partagé, même si elle venait de Google, et ma version du fichier compressé était un couple de K plus grand que celui de Google. après le chargement du fichier et (vraisemblablement) mis en cache. Donc pour moi, depuis la bande passante n'a 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. 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'ils utilisent et encore moins les paramètres de sécurité que 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 plus "complètes" sont une histoire différente à certains égards), sauf pour poster des exemples ici.
En plus des personnes qui conseillent de l'héberger sur leur propre serveur, j'avais proposé de le garder sur un domaine séparé (par exemple static.website.com) pour permettre aux navigateurs de le charger séparément des autres threads de contenu. Cette astuce fonctionne également pour toutes les choses statiques, disons les images et css.
Je dois voter -1 pour les bibliothèques hébergées sur Google. Ils recueillent des données, style google analytics, avec leurs wrappers 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, et encore moins rien d'autre sur la page. Au pire, C'est la "nouvelle version" de Google de ne pas être mal-en utilisant JavaScript discret pour recueillir 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 leur 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 suis peut-être vieille école à ce sujet, mais je fronce toujours les sourcils sur hotlinking. Peut-être que Google est l'exception, mais en général, c'est vraiment juste de bonnes manières d'héberger les fichiers sur votre propre serveur.
Je vais ajouter ceci comme une raison pour 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 problème ajax.googleapis.com domaine (pour les utilisateurs avec IPv4) seulement pour que nous n'obtenions pas les fichiers externes. Cela a été intermittent jusqu'à hier (maintenant c'est persistant.) Parce que c'était intermittent, j'avais des tonnes de problèmes pour résoudre les problèmes des utilisateurs SaaS. Passé d'innombrables heures à essayer de suivre pourquoi certains utilisateurs n'avaient aucun problème avec le logiciel, et d'autres ont été tanking. 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 de développement en me disant que jquery ne chargeait pas, puis j'ai commencé à faire des traceroutes, etc... pour trouver le vrai problème.
Après cela, je ne reviendrai probablement jamais aux fichiers hébergés en externe parce que: google ne doit pas descendre pour que cela devienne un problème, et... n'importe lequel de ces nœuds peut être compromis avec le détournement DNS et fournir des js malveillants au lieu du fichier réel. J'ai toujours pensé que j'étais en sécurité dans le fait 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.
Je viens d'inclure la dernière version du site jQuery: http://code.jquery.com/jquery-latest.pack.js Il 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-la et servez-la vous-même. Mais pour mon site personnel, Je ne pouvais pas me soucier moins. Les choses ne disparaissent pas comme par magie, elles sont généralement dépréciées en premier. Je le suis assez pour savoir quoi changer pour les futures versions.
Voici une ressource utile, hope peut vous aider à choisir votre CDN. MS a récemment ajouté un nouveau domaine pour les bibliothèques de livraison à travers 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 plupart technologie populaire utilisée sur le web à travers toutes les technologies. http://trends.builtwith.com/
L'espoir peut vous aider à choisir.
Si je suis responsable du site' live', je ferais mieux d'être conscient de tout ce qui se passe sur 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 changement
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>
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 ce que le site doit y mettre. 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 jQuery supplémentaires là aussi - un peu plus de kbs sont beaucoup plus 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 super rapide.
Lors du premier chargement, une solution 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 que la différence soit perceptible, cependant. Et puis, lors d'un premier chargement avec le cache effacé, votre propre solution hébergée sera probablement toujours beaucoup plus rapide, en raison de plus de requêtes (et de recherches DNS) nécessaires, pour récupérer le jquery CDN.
Je me demande comment ce point est presque jamais mentionné, et comment les CDN semblent prendre le contrôle du Monde :)