Microsoft CDN para jQuery o Google CDN? [cerrado]

187

¿Realmente importa qué CDN utilizas para vincular a tu archivo jquery o cualquier archivo javascript para ese asunto? ¿Es uno potencialmente más rápido que el otro? ¿Qué otros factores podrían desempeñar un papel en el CDD que decida utilizar? Sé que Microsoft, Yahoo y Google tienen CDN ahora.

Xaisoft
fuente

Respuestas:

151

Actualización basada en comentarios:

Versión corta: no importa mucho, pero puede depender de lo que alojen. Todos ellos anfitrionas diferentes cosas: Google no aloja jQuery.Validate, Microsoft no hizo anfitrión jQuery-UI, ya que 2.016 lo hacen !!, Microsoft ofrece sus guiones que de otro modo serían atendidos por medio ScriptResource.axdy una integración más fácil (por ejemplo ScriptManager con ASP. Neto 4.0 ).

Nota importante: si está creando una aplicación de intranet, manténgase alejado del enfoque de CDN. No importa quién lo aloje, a menos que esté en un servidor muy sobrecargado internamente, ningún CDN le brindará más rendimiento que el Ethernet local de 100mb / 1GB. Si usa un CDN para una aplicación estrictamente interna, está perjudicando el rendimiento . Configure sus encabezados de caducidad de caché correctamente e ignore que existen CDN en el escenario de solo intranet.

Las posibilidades de ser bloqueado parecen ser casi iguales, casi nulas. He trabajado en contratos donde esto no es cierto, pero parece ser una excepción. Además, desde la publicación original de esta respuesta, el contexto que la rodea ha cambiado mucho, el CDN de Microsoft ha progresado mucho.

El proyecto en el que estoy actualmente utiliza ambos CDN que funcionan mejor para nuestra solución. Varios factores juegan en esto. Es probable que los usuarios con un navegador anterior sigan haciendo 2 solicitudes simultáneas por dominio según lo recomendado por la especificación HTTP . Este no es un problema para cualquiera que ejecute algo decentemente nuevo que admita la canalización (todos los navegadores actuales), pero en base a otro factor, también estamos eliminando esta limitación, al menos en lo que respecta al javascript.

El CDN de Google que estamos usando para:

CDN de Microsoft que estamos usando para:

Nuestro servidor:

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

Dado que parte de nuestro proceso de compilación es combinar y minimizar todos los javascript personalizados, lo hacemos a través de un administrador de scripts personalizado que incluye las versiones de lanzamiento o depuración (no minimizadas) de estos scripts según la compilación. Dado que Google no aloja el paquete de validación jQuery, esto puede ser un inconveniente. MVC incluye / usa esto en su versión 2.0, por lo que puede confiar completamente en el CDN de Microsoft para todas sus necesidades, y todo de forma automática a través del ScriptManager .

El único otro argumento a ser sería tiempos de DNS, hay un costo en términos de velocidad de carga de la página. En promedio:ajax.googleapis.com es probable que el DNS devuelva antes (simplemente porque se ha usado más (ha estado más tiempo)) ajax.microsoft.com, simplemente porque el servidor DNS local tenía más probabilidades de recibir una solicitud (este es el primer usuario en la penalización de área) . Esto es algo muy pequeño y solo debe considerarse si el rendimiento es extremadamente importante, hasta el milisegundo.
(Sí: me doy cuenta de que este punto es contrario a mi uso de ambas CDN, pero en nuestro caso el tiempo de DNS se ve eclipsado por el tiempo de espera en el javascript / bloqueo que ocurre)

Por último, si no lo ha mirado, una de las mejores herramientas es Firebug y algunos complementos: Page Speed e YSlow . Si usa un CDN pero sus páginas solicitan imágenes cada vez debido a que no tienen encabezados de caché, se está perdiendo la fruta baja. El panel Net de Firebug puede proporcionarle rápidamente un desglose rápido del tiempo de carga de su página, y Page Speed ​​/ YSlow puede ofrecer algunas buenas sugerencias para ayudarlo.

Nick Craver
fuente
26
¿Menos probabilidades de ser bloqueado? Me encantaría saber cómo se te ocurrió esa idea. La red de MS no es de todos modos MS, es akamai que ha estado haciendo servidores de carga equilibrada durante mucho más tiempo que Google, lo que hace que no tenga sentido el "mejor sistema de caída". Realmente, si vas a hacer afirmaciones como esta, alguna evidencia sería buena.
blowdart
16
Algunas compañías, y he trabajado para algunas, bloquean * .microsoft.com directamente como parte de su actualización de bloqueo de Windows. ¿Es esto correcto? No, ¿pasa? Si. Ejemplo: ajax.microsoft.com/...it se incluye en el bloque * .microsoft.com y no en la excepción www, se bloquea cuando una empresa elige bloquear cualquier cosa que no sea www.microsoft.com. No dije que era muy probable, dije que es más probable, ya que nunca he visto google bloqueado pero he visto lo contrario.
Nick Craver
55
Y he visto google bloqueado para detener gmail en sitios gubernamentales. Pero como es tan raro, difícilmente trataría de usarlo como justificación en este caso.
blowdart
19
Desde que esto se escribió, MS ha agregado jQuery-UI a su CDN: asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_UI_from_the_CDN_10
Will Dean el
3
@Nick Microsoft ha movido su CDN de ajax.microsoft.com a ajax.aspnetcdn.com. Por lo tanto, no hay posibilidad de bloquear el CDN de Microsoft como parte del bloqueo de las actualizaciones de Windows.
Sachin Joseph
88

Debería usar absolutamente el CDN de Google para jQuery (y esto proviene de un desarrollador centrado en Microsoft).

Son simples estadísticas. Aquellos que considerarían usar MS CDN para jQuery siempre serán una minoría. Hay demasiados desarrolladores que no son de MS que usan jQuery que usarán Google y no considerarían usar Microsoft. Dado que uno de los grandes triunfos con un CDN público es el almacenamiento en caché mejorado , dividir el uso entre múltiples CDN disminuye el potencial de ese beneficio.

Dave Ward
fuente
77
si seguimos pensando de esa manera, solo los más grandes podrán respirar. No solo use google porque es google y asuma que todos están con ellos (sin duda la mayoría está con ellos). Pero que gane mejor, compare el resultado y vaya con ellos.
mamu
20
No es una suposición. Los sitios en el top 200,000 de Alexa que usan CDN de Google superan en número a los más de 100: 1 de Microsoft. En términos de popularidad para el almacenamiento en caché, el único punto a favor de MS jQuery CDN es que Microsoft.com lo usa, lo que le da mucha exposición solo de esa referencia (pero no tanto como los miles de sitios principales que hacen referencia a Google )
Dave Ward,
@DaveWard, ¿puede verificar que este sigue siendo el caso, o ha cambiado un poco las cosas en los últimos años?
Snumpy
3
@snumpy: El CDN de Google ha ampliado su liderazgo bastante de lo que he visto. No hay nada malo con el CDN de Microsoft. Es rápido y tiene algunos archivos que Google no tiene. Sin embargo, el beneficio de almacenamiento en caché entre sitios depende de la cobertura de toda la red, y Google domina a todos los demás en ese sentido.
Dave Ward el
Debido a que cambié de jQuery CDN a Microeoft's para alojar jQuery Mobile, moví mis otras descargas de jQuery desde Google para reducir la cantidad de viajes de ida y vuelta de DNS. Solo otro factor :)
Rob Grant
20

Google le enviará una versión jQuery minificada con su propio software, esta versión es 6kb más ligera que la versión minificada estándar que ofrece MS. Ve por Google.

Oscar Kilhed
fuente
18

Una cosa menor a considerar es que ambas compañías ofrecen bibliotecas "adicionales" ligeramente diferentes:

Dependiendo de sus necesidades, esto puede ser relevante.

dp.
fuente
23
Desde que esto se escribió, MS ha agregado jQuery-UI a su CDN: asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_UI_from_the_CDN_10
Will Dean el
15

También debe tenerse en cuenta que, como ajax.microsoft.com es un subdominio de solicitudes de microsoft.com, envíe todas las cookies de microsoft.com, lo que se suma al tiempo total que lleva recuperar el archivo.

Además, ajax.microsoft.com está utilizando la compresión IIS7 predeterminada, que es inferior a la compresión estándar que utilizan otros servidores web.

http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js - 33.4K

http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js - 26.5K

Además, como otros han mencionado, Google CDN es mucho más popular, lo que aumenta enormemente la posibilidad de que un archivo se almacene en caché.

Así que recomiendo usar google.

Alistair
fuente
3
Esta fue una buena objeción en ese momento, pero ya no se aplica, ya que el nombre de dominio CDN recomendado ahora es ajax.aspnetcdn.com. El bloqueo de la objeción * .microsoft.com tampoco se aplica.
Stephen Kennedy el
Esto es verdad. contento de que finalmente arreglaron esta parte. Ahora no me siento tan mal por incluir el complemento jquery validate / cycle del ms cdn.
Alistair
Lo de las cookies también ya no se aplica debido al cambio a aspnetcdn.
Rob Grant
11

Probablemente no importe, pero puede validar esto con algunas pruebas A / B. Envíe la mitad de su tráfico a un CDN y la otra mitad al otro, y configure algunos perfiles para medir la respuesta. Creo que es más importante poder cambiar fácilmente en caso de que uno u otro tenga problemas serios de falta de disponibilidad.

lod3n
fuente
7

Sé que estoy llegando un poco tarde aquí, pero aquí está el código que he estado usando en producción. Nunca he tenido problemas con él, pero su kilometraje puede variar. Asegúrese de probarlo en su propio entorno.

<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
fuente
1
Desafortunadamente, algunos navegadores (IE6) no retrasarán el procesamiento de esa secuencia de comandos en línea hasta que se cargue la secuencia de comandos src =, por lo que esto no funcionará como se esperaba. ¡Ojalá lo hiciera!
Walden Leverich
2
Entonces, sus usuarios de IE6 experimentan una experiencia un poco lenta. Buena compensación si me preguntas. IE6 está en declive ... incluso en las intranets corporativas.
Armstrongest
7

Se trata de estadísticas: jquery.com carga jQuery de Google. Y también Twitter, Stackoverflow y muchos otros. Por lo tanto, hay posibilidades bastante altas de que el usuario de su sitio web ya lo tenga en caché = sin descarga .

Olvide el validador, el ancho de banda y la velocidad porque este es el principal beneficio. De lo contrario, cualquier otra opción de CDN funcionará esencialmente al mismo nivel.

achairapart
fuente
1
Sí, pero Twitter (según encosia.com/2010/09/15/… de Dave Ward ) usa jQuery 1.3.0 (en Twitter "antiguo") por lo que realmente no importan ... todavía ...
veggerby
Bueno, los sitios que hice hace algún tiempo todavía usan jQuery 1.3.0, como el (antiguo) Twitter. Siempre importa
achairapart el
6

¿Es uno potencialmente más rápido que el otro?

De hecho, tenía curiosidad por esto, así que configuré una página de prueba jsbin usando cada uno de los siguientes y luego la ejecuté a través de la herramienta de comparación visual de webpagetest.org. Probé:

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

Quién fue el más rápido: code.jquery.com por 0.1 segundos en ambas pruebas

Quién fue el más lento: ajax.aspnetcdn.com por 0.7 segundos en la primera prueba y ajax.googleapis.com por 1 segundo en la segunda prueba

Aquí está la primera prueba (cada una fue probada 3 veces):

Video: http://www.webpagetest.org/video/view.php?id=121019_16c5e25eff2937f63cc1714ed1eac814794e62b3

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

Aquí está la segunda prueba (otras 3 cada una):

Video: http://www.webpagetest.org/video/view.php?id=121019_a7b351f706cad2c25664fee7ef349371f17c4e74

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

Anthony Hatzopoulos
fuente
4

Según lo declarado por Pingdom :

Cuando alguien visita su sitio, si ya ha visitado otro sitio que usa el mismo archivo jQuery en el mismo CDN, el archivo habrá sido almacenado en caché y no necesita descargarse en absoluto. No puede ser más rápido que eso.

Esto significa que el CDN más utilizado tendrá las probabilidades de su lado, lo que puede ser rentable para su sitio.

Algunas observaciones sobre el rendimiento: el CDN de Google es consistentemente el más lento de los tres, tanto en Norteamérica como en Europa. En Europa, el CDN de Microsoft es el más rápido.

mayank
fuente
3

Creo que depende de dónde esté tu público objetivo. Puede usar alertra.com para verificar la velocidad de CDN desde muchos lugares del mundo.

silencio
fuente
Esto no proporciona una respuesta a la pregunta. Para criticar o solicitar una aclaración de un autor, deje un comentario debajo de su publicación.
Fiona - myaccessible.website
1
Para Fiona, es mi respuesta a la pregunta. La pregunta es "¿Importa?", Mi respuesta es "depende de dónde se encuentre su público objetivo", y le proporcioné un sitio para probar la velocidad desde diferentes lugares del mundo para permitirle decidir qué CDN utilizar. No es un comentario, es una respuesta.
silencioso
3

Una consideración adicional: si su sitio es SSL y necesita ser compatible con Android 2.1 (o anterior), el certificado SSL en la versión HTTPS de Microsoft CDN bloqueará esas versiones del navegador Android, según este problema: http: // code .google.com / p / android / issues / detail? id = 5001 . No es "culpa" de Microsoft, ya que el certificado SSL es técnicamente válido y el defecto está en la implementación SSL de Android ... pero, no obstante, bloqueará su sitio.

El certificado SSL en el CDN de Google no entra en conflicto con este problema en particular (relacionado con el "Nombre alternativo del sujeto del certificado").

Entonces, para el soporte SSL + Android 2.1, use el CDN de Google.

Kent McNeill
fuente
2

Mi respuesta es un poco diferente a la de otros, iré con microsoft si necesita jquery validator que casi todos necesitan si está usando jquery.

La conexión http de Microsoft CDN es Keep-Alive, lo cual es una gran ventaja cuando solicita varios elementos.

Entonces, si necesita la validación de jquery, use Microsoft CDN, incluso si necesita jquery ui use microsoft porque google no mantiene el mantenimiento, por lo que cada solicitud es independiente. así que mezclar de esa manera es más. Si está utilizando Microsoft solo para el validador, entonces está haciendo una conexión separada con el servidor de Google para cada solicitud.

mamu
fuente
1

También considere al usar Google CDN que algunas veces las personas hacen errores tipográficos como ajax.googelapis.com. Esto podría crear un ataque realmente desagradable xss (cross site scripting). De hecho, he probado esto al registrar un error tipográfico de googlapis.com y rápidamente me encontré sirviendo solicitudes de JavaScript, mapas, CSS, etc.

Envié un correo electrónico a Google y les pedí que registraran URL de error tipográficos de CDN similares, pero no he recibido respuesta. Esta podría ser una razón real para no confiar en los CDN porque hay atacantes potencialmente peligrosos en espera de las solicitudes de error tipográfico y pueden servir fácilmente jquery, etc. con una carga útil xss.

Gracias


fuente
1
un poco fuera de tema quizás, pero punto interesante.
achairapart
1

Según la industria a la que se dirija la aplicación, es posible que no desee utilizar un CDN administrado por otras organizaciones. A menudo plantea problemas relacionados con el cumplimiento, la privacidad y la confidencialidad.

Por ejemplo, cuando incluye Google Analytics en una aplicación segura, el navegador aún envía la URL actual como el encabezado "referente". Cualquier identificador, por ejemplo, una identificación de sesión o token secreto puede aparecer en sus registros. Por ejemplo, si una IP de cliente de 192.0.2.5 referencias https: //healthsystem.example/condition/impotence , entonces bien, puede inferir información que se considera bastante privada.

Otros casos incluyen información de consecuencia, como un número de cuenta, número de seguro social o información de sesión en la URL. Ese tipo de datos nunca debe estar en la URL, ya que se puede usar fuera de la aplicación.

Si bien puede confiar en Google, Microsoft o Yahoo, sus usuarios pueden no hacerlo.

Para industrias como Finanzas, Legal y Atención de la Salud, es posible que desee establecer su propia CDN con la ayuda de un proveedor (por ejemplo, Akamai) con el que pueda firmar un BAA.

bloudraak
fuente
1

Le aconsejaría que base su uso en la ubicación general de los usuarios a los que se dirige.

Si su sitio está dirigido al público en general, utilizar la CDN de Google sería una buena opción.

Si su sitio también está dirigido a China, utilizar la CDN de Microsoft sería una mejor opción. Sé por mi experiencia, ya que los servidores de Google seguían siendo bloqueados por el gobierno chino, lo que hacía que los sitios web que los usan no se puedan cargar.

* Tenga en cuenta que puede crear sitios específicos de cada región, por ejemplo, cn.mysite.com para atender específicamente a China, pero si tiene pocos recursos y tiempo, vale la pena considerarlo.

Lista completa de Microsoft CDN aquí. http://www.asp.net/ajaxlibrary/cdn.ashx

Desde entonces han cambiado el nombre a ajax.aspnetcdn.com , lo que reduce la probabilidad de bloqueo por las reglas del firewall.

KnaveT
fuente
-3

¡Yo usaría ambos!

Como el alojamiento de Google Jquery ha existido por mucho más tiempo, hay muchas más posibilidades de que la gente ya lo tenga en caché en comparación con el de Microsoft, por lo que lo tendría primero.

Personalmente, usaría algo como esto:

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
}

(No estoy seguro de que esto funcione al 100%, pero solo iba a escribir la idea y no el ejemplo: esto hace referencia al Google alojado Jquery y no al Microsoft ya que no pude encontrar el enlace)

Wil
fuente
66
jQuery nunca se definirá a menos que lo traigas a tu página. ¡El almacenamiento en caché del archivo .js no lo hace disponible para todas las páginas del navegador de forma predeterminada!
Falkayn el
1
Esto funciona: S Re lea el script: si no está definido, escribe esto y se carga.
Wil
12
Nunca he entendido por qué la gente hace "<scr" + "ipt ..."
cobarde anónimo
3
"Dependiendo del navegador, la cantidad de otros javascript anteriores y qué tan bien formado esté el código general, esto se hace para evitar que el analizador interprete las etiquetas <script> y </script> como código ejecutable en lugar de como una cadena para ser escrito."
SeanJA
2
El problema es que jQuerynunca se definirá a menos que lo haya cargado activamente. En su script, la primera rama siempre se ejecutará (a menos que tenga otra inclusión de jQuery arriba), lo que hace que el script sea superfluo.
jensgram