¿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.
Respuestas:
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:
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.
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.
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.
Una cosa menor a considerar es que ambas compañías ofrecen bibliotecas "adicionales" ligeramente diferentes:
Dependiendo de sus necesidades, esto puede ser relevante.
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.
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.
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> 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.
¿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é:
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
Aquí está la segunda prueba (otras 3 cada una):
Video: http://www.webpagetest.org/video/view.php?id=121019_a7b351f706cad2c25664fee7ef349371f17c4e74
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.
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.
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.
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.
En resumen, dice que Microsoft no ofrece IU, eso no es correcto (más). Se puede descargar en http://www.asp.net/ajaxlibrary/cdn.ashx .
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
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.
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.
¡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)
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.