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


42

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.

Les deux premiers points ne s'appliquent que si vous craignez que Google ne tombe en panne ou se fasse pirater.
user16764

1
@ user16764 - ou ils enlèvent leur copie de jQuery pour une raison quelconque (politique, qui sait).
M. Jefferson

2
Une autre raison est de ne pas protéger la vie privée. L'utilisation d'un contenu hébergé par des tiers offre à ce dernier un moyen de suivre les utilisateurs auxquels il est difficile de se soustraire.
Ian Newson

de plus, certains CDN, spécialement les hôtes Google, ont parfois tendance à restreindre les fichiers de certains pays
azerafati

Réponses:


58

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.


+1 Vous offre les avantages du CDN et couvre également les pièges potentiels.
Quentin-Starin

5
Quelle est la pertinence de la disponibilité? Si son site n'est pas opérationnel, avoir le js en ligne n'est pas un avantage :)
Boris Yankov

3
@ BorisYankov, si le CDN est en panne et que votre site est actif et que vous n'avez pas utilisé de solution de secours locale, votre site ne fonctionnera pas. C'est la pertinence du temps de disponibilité. Si votre site est en panne, votre site est en panne et la copie locale n'aura pas d'importance.
zzzzBov

CDN aura également des serveurs partout, donc vous obtiendrez la ressource du nœud le plus proche.
hanzolo

35

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.


4
Ah, je suis sûr que je peux faire un meilleur travail en hébergeant des actifs statiques que Google. ;)
Xeoncross

Ne pas utiliser les deux (CDN + local) est tout simplement négligeable. Dommage que ce soit la meilleure réponse à mon humble avis.
Quentin-Starin

@ qes Assez, j'ai ajouté une nouvelle phrase à la fin de ma réponse.
CFL_Jeff

17

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.


5
Cela présente l’avantage supplémentaire de vous permettre de développer hors ligne.
RSG

L'utilisation d'une URL relative au protocole n'est plus aussi utile qu'elle l'était auparavant (voir paulirish.com/2010/the-protocol-relative-url ). Il est raisonnable ici de simplement taper https://.
GKFX

5

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.


4

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 .


0

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>

0

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.


Une politique de sécurité qui élimine ou restreint de quelque manière que ce soit le contenu CDN de Google ou de jQuery va détruire beaucoup de sites Web, pas seulement celui du demandeur. En d'autres termes, il y a de plus gros problèmes à craindre.

2
@Snowman ... comme le grand pare-feu en Chine (qui casse régulièrement les sites Stack Exchange qui utilisent un CDN pour ses scripts)?
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.