Référencement de bibliothèques javascript localement ou en externe?

Question

Nous développons actuellement une application ASP.NET MVC qui sera déployée sur un intranet d'entreprise, avec une version client légèrement modifiée disponible sur Internet. Nous utilisons un certain nombre de bibliothèques javascript externes (par exemple jQuery) et une discussion a été lancée concernant le référencement des bibliothèques - devons-nous les référencer à partir d'une source externe (par exemple via la méthode jQuery de chargement de Google) ou garder notre propre version localement et référence à partir de là? Le chef de projet s'inquiète un peu d'avoir une «dépendance» vis-à-vis de Google (ou de quiconque) si nous nous référons à partir de là, et pense que disposer de notre propre copie de la bibliothèque nous rend plus indépendant. D'un autre côté, j'ai entendu dire qu'il y a un certain nombre d'avantages à laisser quelqu'un d'autre héberger la bibliothèque - par exemple, ils s'occupent de la gestion des versions, Google n'ira nulle part bientôt ...

(pour le but de la discussion supposons que l'intranet sur lequel nous hébergeons a un accès externe - évidemment, s'il s'avère que la décision n'est pas vraiment prise pour nous!)

Donc. Est-ce que cela compte? Et si oui, que devrions-nous faire et pourquoi?

(J'apprécie que ce soit subjectif - mais il serait très utile d'obtenir des conseils de toute personne ayant de l'expérience ou des réflexions sur le sujet.Ne sais pas si c'est un candidat pour wiki communautaire ou non, laissez-moi savoir mettre là-bas et je saurai pour l'avenir!)

Merci :)

Answer 1

est l'application essentielle pour vos utilisateurs internes? Si l'Internet est en panne, votre entreprise en souffrira-t-elle parce que les utilisateurs internes ne peuvent pas accéder aux applications? C'est vraiment plus sur le risque que toute autre chose. En outre, en cas de changement ou de rupture, ne voudriez-vous pas gérer la 'mise à niveau'?

Answer 2

vous pouvez faire quelque chose comme

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

<script type="text/javascript"/> 
if(window.$) { 
    // jquery script goes here 
} else { 
    var elmScript = document.createElement('script'); 
    elmScript .src = 'jQuery.js'; // path to jquery 
    elmScript .type = 'text/javascript';   
    document.getElementsByTagName('head')[0].appendChild(elmScript); 
} 
</script> 

Answer 3

Malgré la complexité-problèmes qui se posent d'avoir votre code dispersés sur plusieurs sites, dont certains vous ne contrôlez pas, il y a aussi une légère perte de performances à payer pour extraire le contenu de plusieurs domaines (par exemple, une recherche DNS supplémentaire). Pour un site Web public, où beaucoup d'utilisateurs seront des débutants, il peut être avantageux de mettre le code en cache déjà, mais sinon je ne vois pas vraiment le point.

Answer 4

Généralement, la raison d'utiliser une bibliothèque hébergée est la performance. Je ne téléchargerai qu'un nombre limité de fichiers par hôte. L'utilisation d'une bibliothèque hébergée chargera donc les fichiers d'un hôte différent et donc parallèlement aux autres fichiers. La deuxième raison est que ces fichiers sont généralement compressés et que les en-têtes de cache sont correctement définis. Et ces fichiers sont généralement stockés dans un CDN, ce qui signifie que vos utilisateurs téléchargent le fichier à partir des hôtes qui leur sont les plus proches.

Mais toutes ces raisons ne sont pas si importantes dans un environnement intranet.

Answer 5

La raison principale (seulement?) De le faire serait pour des raisons de performance comme @ Kau-Boy l'a déjà mentionné. JQuery est une bibliothèque relativement petite (pour ce qu'elle vous donne) et elle sera mise en cache localement par les navigateurs/proxies/FAI de votre utilisateur externe. Donc, cela ne vous donne vraiment rien sauf un petit gain de latence.

Si vous vous trouvez en ajoutant de nombreux fichiers Javascript externes alors vous devriez peut-être reconsidérer votre stratégie de conception globale. Choisissez une bonne bibliothèque générale (je considère personnellement que jQuery est imbattable - c'est la partie subjective) et apprenez-la à l'envers. Vous ne devriez pas avoir à ajouter beaucoup plus de bibliothèques à part le plugin impair, qui devrait être inclus page par page de toute façon.

Quelques très bonnes réponses des autres ici d'ailleurs.