Référencement de javascript externe et 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 les avantages 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 du genre, mon application se casse. Mais je sens que cela n'arrivera pas souvent; Il doit y avoir beaucoup de sites de petite taille faisant cela, et l'équipe de 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é
• Si elle est référencée en externe, je n'ai pas à m'inquiéter de la bande passante pour traiter les fichiers (bien que je sache que ce n'est pas beaucoup).
• S'il est référencé en externe et que je déploie ce site Web sur de nombreux serveurs qui doivent disposer de leurs propres copies de tous les fichiers, il ne faut pas oublier de copier / mettre à jour ce fichier.

Vous devriez faire les deux:

Commencez par un hébergement à partir d'un CDN tel que Google, car son temps de disponibilité sera probablement plus élevé que celui de votre propre site et il sera configuré pour le temps de réponse le plus rapide. De plus, toute personne ayant visité une page ayant un lien vers le CDN utilisera sa copie en cache du fichier. Ainsi, 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 safe est sécurisé). Les solutions de remplacement 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 que vous n'écrivez </script>nulle part dans un <script>élément, car cela ferme l'élément HTML et provoque l'échec du script. La solution simple est d'utiliser une barre oblique inverse comme une échappatoire <\/script>.

_{Une autre raison de faire les deux:}

Si vous choisissez un CDN populaire, il est très improbable qu'il ait un jour d'indisponibilité, mais dans un futur lointain (environ 18 mois à compter de maintenant, conformément à la loi de Moore ) lorsque le format d'hébergement change ou que l'adresse est modifiée. réseau est placé derrière un paywall, ou autre chose, il est possible que votre lien ne fonctionne plus tel quel. Si vous utilisez une solution de secours, vous aurez alors un peu de temps pour vous adapter à tout nouveau format d'hébergement avant de devoir 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ù je liais des copies locales de ressources de script et j'ai rapidement constaté qu'un certain nombre de projets nécessitaient de lier des copies locales.

J'avais la même question, puis j'ai lu cet article et l'idée de laisser Google héberger ma bibliothèque jQuery me laissait convaincre.

L'article indique les principaux avantages de l'hébergement de vos bibliothèques sur le réseau de diffusion de contenu (CDN) de Google:

• Latence réduite - Les utilisateurs qui ne se trouvent pas physiquement près de votre serveur pourront télécharger jQuery plus rapidement depuis Google que si vous les obligiez à 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 basse que deux connexions par nom d'hôte. L'utilisation du CDN Google AJAX Libraries de Google élimine une demande adressée à votre site, ce qui permet de télécharger davantage de contenu local en parallèle.
• Meilleure mise en cache - Grâce aux bibliothèques Google AJAX, vos utilisateurs n'ont peut-être pas besoin de télécharger jQuery du tout. D'autre part, 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 la visite de votre site.

En ce qui concerne les deux points que vous avez énumérés en tant que professionnels de l'hébergement de votre propre bibliothèque, rappelez-vous qu'il s'agit de Google hébergeant la version cloud, et que Google sait ce qu'il fait et qu'il peut faire confiance à la disponibilité et à la sécurité. Cependant, @zzzzBov fait un très bon point dans sa réponse à cette question, dans laquelle il recommande également de stocker une copie locale de la bibliothèque et de la remplacer par défaut dans le cas peu probable où la version CDN ne serait pas accessible pour une raison quelconque.

Personnellement, je me fie à 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 principal de jQuery de Google, mais s’il ne se charge pas pour une raison quelconque, la ligne suivante le charge à partir de votre propre serveur.

Il est préférable d’utiliser un CDN, et si ce dernier est Google, tant mieux, comme l’ont indiqué @CFL_Jeff et @Morons.

J'ajoute cette réponse pour signaler quelque chose qui est souvent négligé lorsque vous pointez ailleurs, ce qui évite l'avertissement de contenu mixte . Pensez à utiliser des URL sans protocole, par exemple:

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

L’utilisation d’URL sans protocole pose toujours quelques problèmes de support, aussi jetez un œil aux réponses sur Puis-je changer tous mes liens http: // en seulement //? sur SO, mais essayez au moins de gérer les avertissements de contenu mixte potentiels d’ une manière ou d’ une autre.

Vous devriez le référencer à la bibliothèque d'API de Google .

La raison principale en 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, celui-ci sera déjà stocké dans la mémoire cache du navigateur et ne nécessitera aucun téléchargement .

Je peux me tromper, mais implémenter document.write écrase tout ce que le DOM a. Comme il est judicieux de mettre des 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>

J'aimerais ajouter qu'héberger une copie locale est une pratique recommandée, car rien de ce qui précède n'indique quoi que ce soit lié à une posture sécurisée dans laquelle la géolocalisation et une liste blanche stricte sont impératives. Ne pas héberger ce fichier localement suppose de forcer une sécurité moindre sur vos clients.