Le CDN que vous utilisez pour créer un lien vers votre fichier jquery ou tout autre fichier javascript est-il vraiment important? L'un est-il potentiellement plus rapide que l'autre? Quels autres facteurs pourraient jouer un rôle dans quel cdn vous décidez d'utiliser? Je sais que Microsoft, Yahoo et Google ont tous des CDN maintenant.
Réponses:
Mise à jour basée sur les commentaires:
Version courte: Cela n'a pas beaucoup d'importance, mais cela peut dépendre de ce qu'ils hébergent. Ils hébergent tous des choses différentes: Google n'héberge pas jQuery.Validate, Microsoft n'a pas hébergé jQuery-UI, depuis 2016 ils le font !!, Microsoft propose leurs scripts qui autrement seraient servis via ScriptResource.axdet une intégration plus facile (par exemple ScriptManager avec ASP. Net 4.0 ).
Remarque importante: si vous créez une application intranet, éloignez-vous de l'approche CDN. Peu importe qui l'héberge, à moins que vous ne soyez sur un serveur très surchargé en interne, aucun CDN ne vous donnera plus de performances que l'Ethernet local de 100 Mo / 1 Go. Si vous utilisez un CDN pour une application strictement interne, vous affectez les performances . Définissez correctement les en-têtes d'expiration de votre cache et ignorez que les CDN existent dans le scénario intranet uniquement.
Les chances d'être bloqué semblent être à peu près égales, presque nulles. J'ai travaillé sur des contrats où ce n'est pas vrai, mais cela semble être une exception. De plus, depuis la publication initiale de cette réponse, le contexte qui l'entoure a beaucoup changé, le CDN Microsoft a fait beaucoup de progrès.
Le projet sur lequel je suis actuellement utilise les deux CDN qui fonctionnent le mieux pour notre solution. Plusieurs facteurs jouent dans cela. Les utilisateurs avec un navigateur plus ancien font probablement encore 2 requêtes simultanées par domaine comme recommandé par la spécification HTTP . Ce n'est pas un problème pour quiconque exécute quelque chose de décemment nouveau qui prend en charge le pipelining (tous les navigateurs actuels), mais sur la base d'un autre facteur, nous éliminons également cette limitation, du moins en ce qui concerne le javascript.
Le CDN de Google que nous utilisons pour:
Le CDN de Microsoft que nous utilisons pour:
Notre serveur:
Étant donné qu'une partie de notre processus de construction consiste à combiner et à réduire tous les javascript personnalisés, nous le faisons via un gestionnaire de scripts personnalisé qui inclut les versions de publication ou de débogage (non minifiées) de ces scripts en fonction de la construction. Étant donné que Google n'héberge pas le package de validation jQuery, cela peut être un inconvénient. MVC inclut / utilise cela dans sa version 2.0, vous pouvez donc compter entièrement sur le CDN de Microsoft pour tous vos besoins, et tout cela automatiquement via le ScriptManager .
Le seul autre argument à faire valoir serait les temps DNS, il y a un coût en termes de vitesse de chargement des pages. En moyenne: simplement parce qu'il est plus utilisé (il existe depuis plus longtemps) ajax.googleapis.comest susceptible d'être retourné par DNS plus tôt que ajax.microsoft.com, simplement parce que le serveur DNS local était plus susceptible d'en recevoir une demande (il s'agit d'un premier utilisateur dans la pénalité de zone) . C'est une chose très mineure et ne devrait être prise en compte que si les performances sont extrêmement importantes, jusqu'à la milliseconde.
(Oui: je me rends compte que ce point est contraire à mon utilisation des deux CDN, mais dans notre cas, le temps DNS est largement éclipsé par le temps d'attente sur le javascript / blocage qui se produit)
Enfin, si vous ne l'avez pas regardé, l'un des meilleurs outils est Firebug , et quelques plug-ins pour cela: Page Speed et YSlow . Si vous utilisez un CDN mais que vos pages demandent des images à chaque fois en raison de l'absence d'en-têtes de cache, vous manquez le fruit à portée de main. Le panneau Net de Firebug peut vous donner rapidement une ventilation rapide du temps de chargement de votre page, et Page Speed / YSlow peut offrir de bonnes suggestions pour vous aider.
Vous devez absolument utiliser le CDN Google pour jQuery (et cela provient d'un développeur centré sur Microsoft).
Ce sont de simples statistiques. Ceux qui envisageraient d'utiliser le MS CDN pour jQuery seront toujours une minorité. Il y a trop de développeurs non-MS utilisant jQuery qui utiliseront Google et n'envisageraient pas d'utiliser Microsoft. Étant donné que l' un des grands avantages d'un CDN public est l'amélioration de la mise en cache , la répartition de l'utilisation entre plusieurs CDN diminue le potentiel de cet avantage.
Google vous enverra une version de jQuery minifiée avec son propre logiciel, cette version est 6kb plus légère que la version minifiée standard servie par MS. Optez pour Google.
Une chose mineure à considérer est que les deux sociétés proposent des bibliothèques "supplémentaires" légèrement différentes:
Selon vos besoins, cela peut être pertinent.
Il convient également de noter que ajax.microsoft.com est un sous-domaine des demandes microsoft.com, envoyer tous les cookies microsoft.com en ajoutant au temps global nécessaire pour récupérer le fichier.
De plus, ajax.microsoft.com utilise la compression IIS7 par défaut qui est inférieure à la compression standard utilisée par d'autres serveurs Web.
http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js - 33,4 Ko
http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js - 26,5 Ko
De plus, comme d'autres l'ont mentionné, google CDN est beaucoup plus populaire, ce qui augmente considérablement les chances qu'un fichier soit mis en cache.
Je recommande donc fortement d'utiliser google.
Cela n'a probablement pas d'importance, mais vous pouvez le valider avec des tests A / B. Envoyez la moitié de votre trafic à un CDN et l'autre à l'autre, et configurez un profilage pour mesurer la réponse. Je pense qu'il est plus important de pouvoir changer facilement au cas où l'un ou l'autre aurait de graves problèmes d'indisponibilité.
Je sais que j'arrive un peu tard ici, mais voici le code que j'ai utilisé en production. Je n'ai jamais eu de problèmes avec cela, mais votre kilométrage peut varier. Assurez-vous de le tester dans votre propre environnement.
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">
!window.jQuery && document.write('<script src="/scripts/jquery-1.4.2.min.js"><\/script>')
</script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.4/jquery-ui.min.js" type="text/javascript"></script>
<script type="text/javascript">
!window.jQuery.ui && document.write('<script src="/scripts/jquery-ui-1.8.2.min.js"><\/script>')
</script> Il s'agit de statistiques: jquery.com charge jQuery de Google. Tout comme Twitter, Stackoverflow et bien d'autres. Donc, il y a des possibilités assez élevées que l'utilisateur de votre site Web l'ait déjà mis en cache = aucun téléchargement du tout .
Oubliez le validateur, la bande passante et la vitesse car c'est le principal avantage. Sinon, toute autre option CDN fonctionnera essentiellement au même niveau.
L'un est-il potentiellement plus rapide que l'autre?
J'étais en fait curieux de cela moi-même, alors j'ai configuré une page de test jsbin en utilisant chacun des éléments suivants, puis je l'ai exécutée via l'outil de comparaison visuelle de webpagetest.org. J'ai testé:
Qui a été le plus rapide: code.jquery.com de 0,1 seconde dans les deux tests
Qui a été le plus lent: ajax.aspnetcdn.com de 0,7 seconde au premier test et ajax.googleapis.com de 1 seconde au deuxième test
Voici le 1er test (chacun a été testé 3 fois):
Vidéo: http://www.webpagetest.org/video/view.php?id=121019_16c5e25eff2937f63cc1714ed1eac814794e62b3
Voici le 2ème test (3 autres chacun):
Vidéo: http://www.webpagetest.org/video/view.php?id=121019_a7b351f706cad2c25664fee7ef349371f17c4e74
Comme indiqué par Pingdom :
Quand quelqu'un visite votre site, s'il a déjà visité un autre site qui utilise le même fichier jQuery sur le même CDN, le fichier aura été mis en cache et n'a pas besoin d'être téléchargé du tout. Ça ne peut pas aller plus vite que ça.
Cela signifie que le CDN le plus largement utilisé aura les chances de son côté, ce qui peut être rentable pour votre site.
Quelques observations sur les performances: le CDN de Google est systématiquement le plus lent des trois en Amérique du Nord et en Europe. En Europe, le CDN de Microsoft est le plus rapide.
Je pense que cela dépend de l'endroit où se trouve votre public cible. Vous pouvez utiliser alertra.com pour vérifier à la fois la vitesse du CDN à partir de nombreux endroits dans le monde.
Une considération supplémentaire - si votre site est SSL et que vous devez prendre en charge Android 2.1 (ou version antérieure), le certificat SSL sur la version HTTPS du CDN Microsoft plantera ces versions du navigateur Android, conformément à ce numéro: http: // code .google.com / p / android / issues / detail? id = 5001 . Ce n'est pas la «faute» de Microsoft, car le certificat SSL est techniquement valide et le défaut est dans l'implémentation SSL d'Android ... mais cela plantera votre site, néanmoins.
Le certificat SSL sur le CDN de Google ne va pas à l'encontre de ce problème particulier (relatif au "Certificate Subject Alt Name" du certificat).
Donc, pour la prise en charge de SSL + Android 2.1, utilisez le CDN Google.
Ma réponse est un peu différente des autres, j'irai avec Microsoft si vous avez besoin d'un validateur jquery dont presque tout le monde a besoin si vous utilisez jquery.
La connexion http Microsoft CDN est Keep-Alive, ce qui est important lorsque vous demandez plusieurs éléments.
Donc, si vous avez besoin de la validation jquery, utilisez Microsoft CDN, même si vous avez besoin de jquery ui, utilisez Microsoft, car Google ne maintient pas keep-alive, donc chaque requête est indépendante. donc mélanger de cette manière est plus. si vous utilisez Microsoft uniquement pour le validateur, vous établissez une connexion séparée avec le serveur Google pour chaque demande.
En été, il est dit que Microsoft n'offre pas d'interface utilisateur, ce n'est pas correct (plus). Il peut être téléchargé à l' adresse http://www.asp.net/ajaxlibrary/cdn.ashx .
Lorsque vous utilisez Google CDN, pensez également que parfois les gens font des fautes de frappe telles que ajax.googelapis.com. Cela pourrait potentiellement créer une attaque xss (cross site scripting) vraiment désagréable. J'ai en fait testé cela en enregistrant une faute de frappe sur googlapis.com et je me suis rapidement retrouvé à servir des demandes de javascript, de cartes, de css, etc.
J'ai envoyé un e-mail à Google et leur ai demandé d'enregistrer des URL de typo CDN similaires, mais je n'ai pas eu de réponse. Cela pourrait être une vraie raison de ne pas compter sur les CDN car il y a des attaquants potentiellement dangereux qui attendent les requêtes de faute de frappe et peuvent facilement renvoyer jquery, etc. avec une charge utile xss.
Je vous remercie
Selon le secteur d'activité cible de l'application, vous ne souhaiterez peut-être pas utiliser un CDN géré par d'autres organisations. Cela soulève souvent des problèmes de conformité, de respect de la vie privée et de confidentialité.
Par exemple, lorsque vous incluez Google Analytics dans une application sécurisée, le navigateur envoie toujours l'URL actuelle en tant qu'en-tête "référent". Tous les identifiants, par exemple un identifiant de session ou un jeton secret, peuvent apparaître dans leurs journaux. Par exemple, si une adresse IP client de 192.0.2.5 fait référence à https: //healthsystem.example/condition/impotence , alors vous pouvez déduire des informations considérées comme plutôt privées.
D'autres cas incluent des informations importantes, telles qu'un numéro de compte, un numéro de sécurité sociale ou des informations de session dans l'URL. Ce type de données ne doit jamais figurer dans l'URL car il peut être utilisé en dehors de l'application.
Bien que vous puissiez faire confiance à Google, Microsoft ou Yahoo, vos utilisateurs ne le peuvent pas.
Pour des secteurs comme la finance, le juridique et la santé, vous pouvez créer votre propre CDN avec l'aide d'un fournisseur (par exemple Akamai) avec lequel vous pouvez signer un BAA.
Je vous conseillerais de baser votre utilisation sur la localisation générale des utilisateurs que vous ciblez.
Si votre site est destiné au grand public, utiliser le CDN de Google serait un bon choix.
Si votre site cible également la Chine, utiliser le CDN de Microsoft serait un meilleur choix. Je sais d'après mon expérience, car les serveurs de Google ont continué à être bloqués par le gouvernement chinois, rendant les sites Web qui les utilisent non chargeables.
* Notez que vous pouvez créer des sites spécifiques à une région, par exemple cn.mysite.com pour répondre spécifiquement à la Chine, mais si vous manquez de ressources et de temps, cela vaut la peine d'être pris en considération.
Liste complète des CDN Microsoft ici. http://www.asp.net/ajaxlibrary/cdn.ashx
Ils ont depuis renommé ajax.aspnetcdn.com , ce qui réduit le risque de blocage par les règles de pare-feu.
J'utiliserais les deux!
Comme l'hébergement Google Jquery existe depuis beaucoup plus longtemps, les chances sont beaucoup plus élevées que les gens l'aient déjà mis en cache par rapport à celui de Microsoft, donc je l'aurais en premier.
Personnellement, j'utiliserais quelque chose comme ça -
if (typeof jQuery == 'undefined') {
// jQuery is not loaded
document.write("<scr" + "ipt type=\"text/javascript\" src=\"http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js\"></scr" + "ipt>");
}
} else {
// jQuery is loaded
}(Je ne suis pas sûr que cela fonctionne à 100%, mais j'allais juste écrire l'idée et non l'exemple - Cela fait référence au Jquery hébergé par Google et non à celui de Microsoft car je n'ai pas trouvé le lien)
jQuerycela ne sera jamais défini tant que vous ne l' avez pas chargé activement. Dans votre script, la première branche sera toujours exécutée (sauf si vous avez une autre inclusion jQuery ci-dessus), rendant le script superflu.