Microsoft CDN pour jQuery ou Google CDN?
Le CDN que vous utilisez pour lier votre fichier jQuery ou tout fichier javascript est-il important? L'un est-il potentiellement plus rapide que l'autre? Quels autres facteurs pourraient jouer un rôle dans lequel cdn vous décidez d'utiliser? Je sais que Microsoft, Yahoo et Google ont tous des CDN maintenant.
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 !!, Microsoft propose ses scripts qui seraient autrement servis via ScriptResource.axd et une intégration plus facile (par exemple, ScriptManager avec ASP.Net 4. ).
Note importante: Si vous construisez une application intranet, éloignez-vous de l'approche CDN. Peu importe qui l'héberge, sauf si vous êtes sur un serveur surchargé en interne very , aucun CDN ne vous donnera plus de performances que ne le fera un serveur Ethernet local de 100mb/1GB. Si vous utilisez un CDN pour une application strictement interne, vous êtes nuit aux performances . Définissez correctement vos en-têtes d'expiration de cache et ignorez les CDN existant 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 originale de cette réponse, le contexte qui l’entoure a considérablement changé, le CDN de Microsoft a beaucoup progressé.
Le projet en cours d'utilisation utilise les deux CDN, ce qui fonctionne le mieux pour notre solution. Plusieurs facteurs jouent dans cela. Les utilisateurs avec un ancien navigateur font probablement encore 2 demandes 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 tout à fait nouveau que prend en charge le traitement en pipeline (tous les navigateurs actuels), mais en fonction d'un autre facteur, nous éliminons également cette limitation, du moins en ce qui concerne javascript. .
Le CDN de Google que nous utilisons pour:
Le CDN de Microsoft que nous utilisons pour:
- MicrosoftAjax.js
- MicrosoftAjaxWebForms.js (jusqu'à la version 4.0, nous ne supprimons pas complètement tous les UpdatePanels)
- jQuery.Validate.min.js
Notre serveur:
- Combined.js? V = 2.2.0.6190 (Major.Minor.Iteration.Changeset)
Dans la mesure où une partie de notre processus de construction consiste à combiner et à minimiser tout le javascript personnalisé, nous le faisons via un gestionnaire de script personnalisé qui inclut la version ou les versions de débogage (non minifiées) de ces scripts en fonction de la construction. Puisque Google n'héberge pas le package de validation jQuery, cela peut être un inconvénient. MVC inclut/utilise cela dans leur version 2.0, vous pouvez donc vous fier entièrement au CDN de Microsoft pour tous vos besoins, et tout cela automatiquement via le ScriptManager .
Le seul autre argument à prendre en compte serait les temps DNS, ce qui a un coût en termes de vitesse de chargement des pages. On Average: Tout simplement parce qu'il est utilisé plus souvent (ça fait plus longtemps) ajax.googleapis.com est susceptible d'être renvoyé par DNS plus tôt que ajax.Microsoft.com, simplement parce que le serveur DNS local risquait davantage d’obtenir une requête (il s’agissait du premier utilisateur de la pénalité de zone). Ceci est une chose mineure very et ne doit être considérée que si les performances sont extrêmement importantes, jusqu’à la milliseconde.
(Oui: je réalise que ce point est contraire à l’utilisation des deux CDN, mais dans notre cas, le temps DNS est largement occulté par le temps d’attente du javascript/blocage qui se produit)
Enfin, si vous ne l’avez pas regardée, l’un des meilleurs outils disponibles 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ête de cache, il vous manque 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 vous proposer 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).
C'est des statistiques simples. Ceux qui envisageraient d'utiliser MS CDN pour jQuery seront toujours une minorité. Il y a trop de développeurs non-MS utilisant jQuery qui utiliseront ceux de Google et qui n'envisageraient pas d'utiliser ceux de Microsoft. Depuis l'un des gros gains avec un CDN public est la mise en cache améliorée , le fractionnement de l'utilisation entre plusieurs CDN réduit le potentiel de cet avantage.
Google vous enverra une version jQuery minifiée avec son propre logiciel. Cette version est plus légère de 6 Ko par rapport à la version minifiée standard fournie par MS. Allez pour Google.
Une chose mineure à considérer est que les deux sociétés offrent des bibliothèques "extra" légèrement différentes:
- Microsoft propose la bibliothèque de validation de JQuery sur leur CDN, alors que Google ne le fait pas ( http://www.asp.net/ajaxlibrary/ cdn.ashx )
- Google propose la bibliothèque de l'interface utilisateur JQuery sur leur CDN, alors que Microsoft ne le fait pas ( http://code.google.com/apis/ ajaxlibs/documentation / )
Selon vos besoins, cela peut être pertinent.
Il convient également de noter que ajax.Microsoft.com étant un sous-domaine des demandes de Microsoft.com, tous les cookies de Microsoft.com sont envoyés, ce qui ajoute au temps total 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 les 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
En outre, comme d'autres l'ont mentionné, Google CDN est bien 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 certains tests A/B. Envoyez la moitié de votre trafic à un CDN et l'autre moitié, et configurez un profilage pour mesurer la réponse. Je pense qu'il est plus important de pouvoir basculer facilement au cas où l'un ou l'autre aurait de sérieux problèmes d'indisponibilité.
Il s’agit de statistiques: jquery.com charge jQuery depuis Google. Il en va de même pour Twitter, Stackoverflow et beaucoup d'autres. Donc, il y a de grandes chances que votre utilisateur de site Web l'ait déjà mis en cache = pas de téléchargement du tout .
Oubliez validator, bande passante et rapidité car c’est le principal avantage. Sinon, toute autre option CDN fonctionnera essentiellement au même niveau.
Je sais que je suis arrivé un peu tard, mais voici le code que j'ai utilisé dans la production. Je n'ai jamais eu de problèmes avec, 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>
L'un est-il potentiellement plus rapide que l'autre?
En fait, j’étais curieux de cela moi-même, j’ai donc créé une page de test jsbin à l’aide de chacun des éléments suivants, puis j’ai examiné l’outil de comparaison visuelle de webpagetest.org. J'ai testé:
- ajax.googleapis.com
- code.jquery.com
- ajax.aspnetcdn.com
- cdnjs.cloudflare.com
Qui était 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_16c5e25eff2937f63cc1714ed1eac814794e62b
Voici le 2nd test (3 autres chacun):
Vidéo: http://www.webpagetest.org/video/view.php?id=121019_a7b351f706cad2c25664fee7ef349371f17c4e74
Comme indiqué par Pingdom :
Lorsque quelqu'un visite votre site, s'il a déjà visité un autre site utilisant le même fichier jQuery sur le même CDN, le fichier a été mis en cache et n'a pas besoin d'être téléchargé du tout. Ça ne peut pas être plus rapide que ça.
Cela signifie que le CDN le plus largement utilisé aura la cote, ce qui peut rapporter de l'argent à votre site.
Quelques observations sur les performances: le CDN de Google est systématiquement le plus lent des trois, tant en Amérique du Nord qu’en Europe. En Europe, le CDN de Microsoft est le plus rapide.
Je pense que cela dépend de votre public cible. Vous pouvez utiliser alertra.com pour vérifier la vitesse du CDN à partir de nombreux endroits dans le monde.
Autre considération - si votre site est SSL et que vous devez prendre en charge Android 2.1 (ou une version antérieure), le certificat SSL de la version HTTPS du CDN de Microsoft plantera ces versions du Android navigateur, d'après ce problème: http://code.google.com/p/Android/issues/detail?id=5001 . Ce n'est pas la "faute" de Microsoft, le certificat SSL est techniquement valide et le défaut est dans l'implémentation SSL d'Android ... mais il plantera néanmoins votre site.
Le certificat SSL figurant sur le CDN de Google ne contrevient pas à ce problème particulier (relatif au "Nom alternatif du sujet du certificat").
Ainsi, pour SSL + Android 2.1, utilisez le CDN de Google.
Ma réponse est légèrement différente de celle des autres. J'irai avec Microsoft si vous avez besoin du validateur JQuery dont presque tout le monde a besoin si vous utilisez JQuery.
La connexion HTTP CDN Microsoft est Keep-Alive, ce qui est un avantage considérable lorsque vous demandez plusieurs éléments.
Donc, si vous avez besoin de la validation de jquery, utilisez Microsoft CDN, même si vous avez besoin de jquery ui, car Microsoft ne garde pas vivante, chaque requête est donc autonome. Donc, mélanger de cette façon est un plus. Si vous utilisez Microsoft uniquement pour Validator, vous établissez une connexion séparée avec Google Server pour chaque demande.
En résumé, il est indiqué 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 .
Je vous conseillerais de baser votre utilisation sur l'emplacement général des utilisateurs que vous ciblez.
Si votre site est destiné au grand public, alors utiliser le CDN de Google serait un bon choix.
Si votre site cible également la Chine, le CDN de Microsoft serait un meilleur choix. D'après mon expérience, les serveurs de Google étaient de plus en plus bloqués par le gouvernement chinois, ce qui rend les sites Web qui les utilisent non téléchargeables.
* Notez que vous pouvez bien sûr 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 compte.
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 du pare-feu.
Selon l’industrie ciblée par l’application, il se peut que vous ne souhaitiez pas utiliser un CDN géré par d’autres organisations. Cela soulève souvent des problèmes de conformité, de confidentialité et de confidentialité.
Par exemple, lorsque vous incluez Google Analytics dans une application sécurisée, le navigateur envoie toujours l'URL actuelle comme en-tête "référent". Tous les identifiants, par exemple un identifiant de session ou un jeton secret, peuvent figurer dans leurs journaux. Par exemple, si une adresse IP client de 192.0.2.5 est référencée https: //healthsystem.example/condition/impotence , vous pouvez en déduire des informations considérées comme plutôt confidentielles.
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 Finance, Legal and Health Care, vous pouvez créer votre propre CDN avec l’aide d’un fournisseur (Akamai, par exemple) avec lequel vous pouvez signer un BAA.
Lorsque vous utilisez Google CDN, prenez également en compte le fait que certaines personnes font des fautes de frappe telles que ajax.googelapis.com. Cela pourrait potentiellement créer une très mauvaise attaque xss (cross site scripting). En fait, j’ai testé cela en enregistrant une faute de frappe sur googlapis.com et je me suis très vite retrouvé au service de requêtes en javascript, maps, css, etc.
J'ai envoyé un e-mail à Google pour lui demander d'enregistrer des URL de frappe CDN similaires, mais je n'ai pas eu de réponse. Cela pourrait être une véritable raison de ne pas compter sur les CDN car il existe des attaquants potentiellement dangereux qui attendent les requêtes de typo et qui peuvent facilement servir de retour jquery etc. avec une charge xss.
Merci