web-dev-qa-db-fra.com

Référencement javascript externe vs hébergement de ma propre copie

Disons que j'ai une application Web qui utilise jQuery. Est-il préférable d'héberger les fichiers javascript nécessaires sur mes propres serveurs avec les fichiers de mon site Web, ou de les référencer sur le CDN de jQuery (exemple: http://code.jquery.com/jquery-1.7.1. min.js )?

Je peux voir des pros des deux côtés:

  • Si c'est sur mes serveurs, c'est une dépendance externe de moins; si jQuery est tombé en panne ou a changé sa structure d'hébergement ou quelque chose comme ça, alors mon application tombe en panne. Mais j'ai l'impression que cela n'arrivera pas souvent; il doit y avoir beaucoup de petits sites qui font cela, et l'équipe jQuery voudra éviter de les casser.
  • Si c'est sur mes serveurs, c'est une référence externe de moins que quelqu'un pourrait appeler un problème de sécurité
  • S'il est référencé en externe, je n'ai pas à me soucier de la bande passante pour servir les fichiers (même si je sais que ce n'est pas tant que ça).
  • S'il est référencé en externe et que je déploie ce site Web sur de nombreux serveurs qui doivent avoir leurs propres copies de tous les fichiers, alors c'est un fichier de moins que je dois me rappeler de copier/mettre à jour.
web-developmentjavascriptcss
43
Mr. Jefferson

Vous devez faire les deux:

Commencez par l'hébergement à partir d'un CDN tel que Google's car il aura probablement un temps de mise à jour plus élevé que votre propre site et sera configuré pour le temps de réponse le plus rapide. De plus, toute personne ayant visité une page qui renvoie au CDN utilisera sa copie en cache du fichier, de sorte qu'elle n'aura même pas à télécharger à nouveau une copie, ce qui accélérera le chargement initial.

Ajoutez ensuite une référence de secours à votre propre serveur au cas où le CDN serait en panne (peu probable, mais sûr est sûr). Les solutions de repli sont relativement faciles à comprendre, mais doivent être personnalisées en fonction du script utilisé:

<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"></script>
<script>
    if (!window.jQuery) document.write('<script src="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

Assurez-vous de ne pas écrire </script> n'importe où dans un <script> élément, car il fermera l'élément HTML et entraînera l'échec du script. La solution simple consiste à utiliser une barre oblique inversée comme échappement: <\/script>.

Une raison de plus pour faire les deux:

Si vous choisissez un CDN populaire, il est très peu probable qu'il ait un temps d'arrêt, mais dans un avenir lointain lointain (~ 18 mois à partir de maintenant étant donné loi de Moore ) lorsque le format d'hébergement change, ou que l'adresse est ajustée, ou que le réseau est placé derrière un mur payant, ou autre chose, il est possible que votre lien ne fonctionne plus tel quel. Si vous utilisez une solution de rechange, cela vous donnera un peu de temps pour vous adapter à tout nouveau format d'hébergement avant d'avoir à parcourir tous les sites Web que vous avez créés et à modifier les liens CDN.

une autre raison de faire les deux:

Récemment, j'ai été frappé par une série de pannes Internet. J'ai pu continuer à travailler localement sur des projets où j'avais lié des copies locales des ressources de script, et j'ai rapidement constaté qu'il y avait un certain nombre de projets qui devaient avoir des copies locales liées.

58
zzzzBov

J'ai eu la même question, puis j'ai lu cet article et j'ai été vendu à l'idée de laisser Google Host ma bibliothèque jQuery.

L'article indique les principaux avantages de permettre à vos bibliothèques d'être hébergées par le Content Delivery Network (CDN) de Google:

  • Latence diminuée - Les utilisateurs qui ne sont pas physiquement proches de votre serveur pourront télécharger jQuery plus rapidement depuis Google que si vous les obligez à le télécharger depuis votre serveur situé arbitrairement.
  • Parallélisme accru - Les navigateurs limitent le nombre de connexions pouvant être établies simultanément. Selon le navigateur, cette limite peut être aussi faible que deux connexions par nom d'hôte. L'utilisation du Google AJAX Libraries CDN élimine une demande à votre site, permettant à plus de votre contenu local d'être téléchargé en parallèle.
  • Meilleure mise en cache - En utilisant les bibliothèques Google AJAX, vos utilisateurs peuvent ne pas avoir besoin de télécharger jQuery du tout. De l'autre Par contre, si vous hébergez jQuery localement, vos utilisateurs doivent le télécharger au moins une fois. Chacun de vos utilisateurs a probablement déjà des dizaines de copies identiques de jQuery dans le cache de leur navigateur, mais ces copies de jQuery sont ignorées lors de leur visite sur votre site.

En ce qui concerne les deux puces que vous avez répertoriées en tant que pros pour l'hébergement de votre propre bibliothèque, n'oubliez pas que c'est Google qui héberge la version cloud, et Google sait ce qu'ils font et peut faire confiance en termes de disponibilité et de sécurité. Cependant, @zzzzBov fait un très bon point dans sa réponse à cette question, où il recommande également de stocker une copie locale de la bibliothèque et de le faire par défaut dans le cas peu probable où la version CDN ne serait pas accessible pour une raison quelconque.

35
CFL_Jeff

Personnellement, je m'inspire de http://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
<script>!window.jQuery && document.write(unescape('%3Cscript src="includes/js/libs/jquery-1.6.1.min.js"%3E%3C/script%3E'))</script>

Cela extrait le fichier jQuery principal de Google, mais s'il ne se charge pas pour une raison quelconque, la ligne suivante le charge à partir de votre propre serveur.

17
Adrian J. Moreno

Il est préférable d'utiliser un CDN, et si ce CDN se trouve être Google, tant mieux - comme l'ont noté @CFL_Jeff et @Morons.

J'ajoute cette réponse pour souligner quelque chose qui passe souvent inaperçu lorsque l'on pointe ailleurs, ce qui évite l'avertissement de contenu mixte . Envisagez d'utiliser des URL sans protocole, par exemple:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript">
</script>

Il y a encore quelques problèmes de support dans l'utilisation d'URL sans protocole, alors jetez un coup d'œil aux réponses sur Puis-je changer tous mes liens http: // en seulement //? sur SO, mais faites à essayez au moins de gérer les avertissements potentiels de contenu mixte de la manière certains.

5
jcmeloni

Vous devez le référencer à Bibliothèque d'API de Google ..

La principale raison à cela est d'accélérer le chargement de vos pages . Si votre utilisateur a déjà visité un autre site référençant la même bibliothèque, il sera déjà stocké dans le cache des navigateurs et il n'aura pas du tout besoin d'être téléchargé.

4
Morons

Je peux me tromper, mais l'implémentation de document.write écrase tout ce que le DOM a. Comme il est recommandé de placer les fichiers JavaScript à la fin du corps,

Je propose la méthode suivante basée sur les réponses précédentes:

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

if(!window.jQuery)
{
    //Creates the script element
    var script = document.createElement('script'); 
    //Adds the type attribute with "text/javascript" value
        script.setAttribute('type', 'text/javascript'); 
    //Adds the source attribute and populates it
        script.setAttribute('src', 'Put_The_Relative_Path_To_Your_JavaScript_File_Here'); 
    //Adds it to the end of the body, as it is good practice, to prevent render-blocking.  
    document.body.appendChild(script);

}

//Note that there's no need for you to verify with an onload function, since all scripts
//must be loaded before going to the next one! 

</script>
0
Jose A

Je voudrais ajouter qu'héberger une copie locale est une meilleure pratique car rien de ce qui précède n'indique quoi que ce soit lié à une posture sécurisée par laquelle la géolocalisation et la liste blanche stricte sont impératives. Ne pas héberger ce fichier localement suppose de pousser une position de sécurité réduite sur vos clients.

0
Mark