Microsoft CDN pour jQuery ou Google CDN? [fermé]

187

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.

Xaisoft
la source

Réponses:

151

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:

  • Combined.js? V = 2.2.0.6190 (Major.Minor.Iteration.Changeset)

É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.

Nick Craver
la source
26
Moins susceptible d'être bloqué? J'aimerais savoir comment vous avez eu cette idée. De toute façon, le réseau MS n'est pas celui de MS, ce sont les akamai qui font des serveurs à charge équilibrée depuis bien plus longtemps que Google, ce qui rend également absurde le "meilleur système de basculement". Vraiment, si vous faites des affirmations comme celle-ci, des preuves seraient bien.
blowdart
16
Certaines entreprises, et j'ai travaillé pour quelques-unes, bloquent carrément * .microsoft.com dans le cadre de leur blocage de la mise à jour de Windows. Est-ce correct? Non, ça arrive? Oui. Exemple: ajax.microsoft.com/...it relève du bloc * .microsoft.com et non de l'exception www, il est bloqué lorsqu'une entreprise choisit de bloquer tout sauf www.microsoft.com. Je n'ai pas dit que c'était très probable, j'ai dit que c'était plus probable, car je n'ai jamais vu Google bloqué mais j'ai vu l'inverse.
Nick Craver
5
Et j'ai vu Google bloqué pour arrêter Gmail sur des sites gouvernementaux. Mais comme c'est si rare, j'essaierais difficilement de l'utiliser comme justification dans ce cas.
blowdart
19
Depuis que cela a été écrit, MS a ajouté jQuery-UI à leur CDN: asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_UI_from_the_CDN_10
Will Dean
3
@Nick Microsoft a déplacé son CDN d'ajax.microsoft.com vers ajax.aspnetcdn.com. Il n'y a donc aucune chance de bloquer le CDN de Microsoft dans le cadre du blocage des mises à jour Windows.
Sachin Joseph
88

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.

Dave Ward
la source
7
si nous continuons à penser de cette façon, seul le plus grand pourra respirer. N'utilisez pas simplement google parce que c'est google et supposez que tout le monde est avec eux (la plupart sont sans doute avec eux). Mais laissez les meilleurs gagner, comparez les résultats et partez avec eux.
mamu
20
Ce n'est pas une hypothèse. Les sites du top 200 000 d'Alexa utilisant le CDN de Google sont plus nombreux que ceux de Microsoft sur 100: 1. En termes de popularité pour la mise en cache, le seul point en faveur du MS jQuery CDN est que Microsoft.com l'utilise, ce qui lui donne une grande visibilité à partir de cette seule référence (mais pas autant que les milliers de meilleurs sites référençant Google. ).
Dave Ward
@DaveWard, pouvez-vous vérifier que c'est toujours le cas, ou les tables ont-elles quelque peu changé ces dernières années?
snumpy
3
@snumpy: Le CDN de Google a considérablement élargi son avance par rapport à ce que j'ai vu. Il n'y a rien de mal avec le CDN Microsoft. C'est rapide et contient quelques fichiers que celui de Google n'a pas. L'avantage de la mise en cache intersite dépend cependant de la couverture à l'échelle du réseau, et Google domine tous les autres à cet égard.
Dave Ward
Parce que je suis passé de jQuery CDN à Microeoft pour héberger jQuery Mobile, j'ai déplacé mes autres téléchargements jQuery depuis Google pour réduire le nombre d'aller-retour DNS. Juste un autre facteur :)
Rob Grant
20

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.

Oscar Kilhed
la source
18

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.

dp.
la source
23
Depuis que cela a été écrit, MS a ajouté jQuery-UI à leur CDN: asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_UI_from_the_CDN_10
Will Dean
15

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.

Alistair
la source
3
C'était une bonne objection à l'époque, mais cela ne s'applique plus car le nom de domaine CDN recommandé est maintenant ajax.aspnetcdn.com. Le blocage de l'objection * .microsoft.com ne s'applique plus non plus.
Stephen Kennedy
c'est vrai. heureux qu'ils aient finalement résolu cette partie de celui-ci. Maintenant, je ne me sens pas si mal d'inclure le plugin jquery validate / cycle du ms cdn.
Alistair
La chose des cookies ne s'applique plus en raison du passage à aspnetcdn.
Rob Grant
11

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é.

lod3n
la source
7

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> 
Jeremy Cade
la source
1
Malheureusement, certains navigateurs (IE6) ne retarderont le traitement de ce script en ligne qu'après le chargement du script src =, donc cela ne fonctionnera pas comme prévu. Je souhaite que ce soit le cas!
Walden Leverich
2
Ainsi, vos utilisateurs IE6 éprouvent une expérience légèrement lente. Bon compromis si vous me demandez. IE6 est en déclin ... même dans les intranets d'entreprise.
Armstrongest
7

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.

achairapart
la source
1
Ouais, mais Twitter (selon encosia.com/2010/09/15/… de Dave Ward ) utilise jQuery 1.3.0 (dans "l'ancien" Twitter) donc ils n'ont pas vraiment d'importance ... encore ...
veggerby
Eh bien, les sites que j'ai créés il y a quelque temps utilisent toujours jQuery 1.3.0, comme le (ancien) Twitter. Cela compte toujours.
achairapart
6

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é:

  1. ajax.googleapis.com
  2. code.jquery.com
  3. ajax.aspnetcdn.com
  4. cdnjs.cloudflare.com

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

Rapports: http://www.webpagetest.org/video/compare.php?tests=121019_D2_KF0,121019_9Q_KF1,121019_WW_KF2,121019_9K_KF3

Voici le 2ème test (3 autres chacun):

Vidéo: http://www.webpagetest.org/video/view.php?id=121019_a7b351f706cad2c25664fee7ef349371f17c4e74

Rapports: http://www.webpagetest.org/video/compare.php?tests=121019_MP_KJN,121019_S6_KJP,121019_V9_KJQ,121019_VY_KJR

Anthony Hatzopoulos
la source
4

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.

mayank
la source
3

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.

silencieux
la source
Cela ne répond pas à la question. Pour critiquer ou demander des éclaircissements à un auteur, laissez un commentaire sous sa publication.
Fiona - myaccessible.website
1
Pour Fiona, c'est ma réponse à la question. La question est "est-ce important", ma réponse est "cela dépend de l'endroit où se trouve son public cible", et j'ai fourni un site pour tester la vitesse à partir de différents endroits à travers le monde pour le laisser décider quel CDN utiliser. Ce n'est pas un commentaire, c'est une réponse.
silencieux le
3

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.

Kent McNeill
la source
2

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.

mamu
la source
1

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


la source
1
un peu hors sujet peut-être, mais un point intéressant.
achairapart
1

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.

bloudraak
la source
1

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.

KnaveT
la source
-3

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)

Wil
la source
6
jQuery ne sera jamais défini à moins que vous ne l'introduisiez dans votre page. La mise en cache du fichier .js ne permet pas de le rendre disponible à toutes les pages du navigateur par défaut!
Falkayn
1
Cela fonctionne: S Re lire le script - s'il n'est pas défini, il écrit ceci et charge?
Wil
12
Je n'ai jamais compris pourquoi les gens font "<scr" + "ipt ..."
lâche anonyme
3
"En fonction du navigateur, de la quantité d'autres javascript précédents et de la qualité du code global, ceci est fait pour empêcher l'analyseur d'interpréter les balises <script> et </script> comme du code exécutable plutôt que comme une chaîne à écrire. "
SeanJA
2
Le problème est que 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.
jensgram