link bootstrap javascript jquery performance httprequest cdn

javascript - bootstrap - jquery link href



Microsoft CDN para jQuery o Google CDN? (18)

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

En realidad, tenía curiosidad de esto, así que configuré una página de prueba jsbin usando cada una de las 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 segundo en ambas pruebas

Quién fue 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 se probó 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 2da 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

¿Importa realmente qué CDN usar para vincular a su 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 que cdn decidir utilizar? Sé que Microsoft, Yahoo y Google tienen ahora CDN.

¡Utilizaría ambos!

Dado que el alojamiento de Google Jquery ha existido por mucho más tiempo, las posibilidades son mucho mayores de que la gente ya lo tenga en caché en comparación con el de Microsoft, así 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 Jquery alojado en Google y no al Microsoft ya que no pude encontrar el enlace)

Aconsejo que basas tu uso en la ubicación general de los usuarios a los que te diriges.

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

Si su sitio también está dirigido a China, entonces usar CDN de Microsoft sería una mejor opción. Sé por experiencia que los servidores de Google siguieron bloqueados por el gobierno chino, por lo que los sitios web que los usan no son cargables.

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

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

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

Como lo dijo Pingdom :

Cuando alguien visita su sitio, si ya han visitado otro sitio que usa el mismo archivo jQuery en el mismo CDN, el archivo se almacenará 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 redituar en su sitio.

Algunas observaciones sobre el rendimiento: el CDN de Google es consistentemente el más lento de los tres en Norteamérica y 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.

Debes usar absolutamente Google CDN para jQuery (y esto viene de un desarrollador centrado en Microsoft).

Son simples estadísticas. Quienes consideren utilizar MS CDN para jQuery siempre serán una minoría. Hay demasiados desarrolladores que no son MS que usan jQuery y que usarán el de Google y no considerarían usar Microsoft. Dado que una de las grandes ganancias 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 minimizada con su propio software, esta versión es 6 kb más liviana que la versión estándar minimizada servida por MS. Ir por Google.

Mi respuesta es un poco diferente que otras. Iré con Microsoft si necesitas el validador de jquery que casi todo el mundo necesita si estás usando jquery.

La conexión http de Microsoft CDN es Keep-Alive, que es una gran ventaja cuando se solicitan varios elementos.

Por lo tanto, si necesita la validación de jquery, utilice Microsoft CDN, incluso si necesita jquery ui use microsoft porque google no mantiene keep-alive así que cada solicitud es por su cuenta. así que mezclar de esa manera es más. si está utilizando microsoft solo para validador, entonces está haciendo una conexión separada con el servidor de google para cada solicitud.

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 mitad a la otra, 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 tuvieran problemas graves de falta de disponibilidad.

Sé que estoy sonando un poco tarde aquí, pero aquí está el código que he estado usando en producción. Nunca he tenido problemas con eso, pero su millaje puede variar. Asegúrate de probarlo en tu 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, y muchos otros. Por lo tanto, existen posibilidades bastante altas de que el usuario de su sitio web ya lo haya almacenado en caché = sin descarga alguna .

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

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 encabezado "referer". Cualquier identificador, por ejemplo, una identificación de sesión o token secreto puede aparecer en sus registros. Por ejemplo, si una IP del cliente de 192.0.2.5referencias 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, un número de seguro social o información de sesión en la URL. Ese tipo de datos nunca debería 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 no pueden.

Para industrias como Finanzas, Legal y Cuidado de la Salud, es posible que desee establecer su propio CDN con la ayuda de un proveedor (por ejemplo, Akamai) con el que puede firmar un BAA.

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 xss realmente desagradable (cross site scripting). De hecho, lo probé registrando un error tipográfico de googlapis.com y rápidamente me encontré atendiendo solicitudes de javascript, mapas, css, etc.

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

Gracias

También se debe tener en cuenta que, como ajax.microsoft.com es un subdominio de las solicitudes de microsoft.com, envíe todas las cookies de microsoft.com agregando al tiempo general necesario para recuperar el archivo.

Además, ajax.microsoft.com usa compresión IIS7 predeterminada que es inferior a la compresión estándar que usan 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 las posibilidades de que un archivo se guarde en caché.

Por lo tanto, recomiendo usar Google.

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

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

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

Actualización basada en comentarios:

Versión corta: no importa mucho, pero puede depender de lo que aloja. Todos ellos alojan cosas diferentes: Google no aloja jQuery.Validate, Microsoft no alojó jQuery-UI, ¡desde 2016 lo hacen ScriptResource.axd Microsoft ofrece sus scripts que, de lo contrario, se ScriptResource.axd través de ScriptResource.axd y una integración más sencilla (por ejemplo, ScriptManager). con ASP.Net 4.0 ).

Nota importante: si está creando una aplicación de intranet, aléjese del enfoque de CDN. No importa quién lo esté alojando, a menos que esté en un servidor muy sobrecargado internamente, ningún CDN le ofrecerá más rendimiento que el de la red local de 100mb / 1GB. Si usa un CDN para una aplicación estrictamente interna, está perjudicando el rendimiento . Establezca correctamente los encabezados de caducidad de caché e ignore que existen CDN en el escenario de solo intranet.

Las posibilidades de que se bloqueen parece ser casi igual, casi cero. 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, Microsoft CDN ha progresado mucho.

El proyecto en el que estoy actualmente utiliza ambos CDN que funciona mejor para nuestra solución. Varios factores juegan en esto. Los usuarios con un navegador más antiguo probablemente sigan realizando 2 solicitudes simultáneas por dominio, tal como lo recomienda la especificación HTTP . Este no es un problema para cualquiera que ejecute algo decentemente nuevo que admita pipelining (todos los navegadores actuales), pero basado en otro factor también estamos eliminando esta limitación, al menos en cuanto al javascript.

El CDN de Google que estamos utilizando para:

El CDN de Microsoft que estamos utilizando para:

Nuestro servidor:

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

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

El único otro argumento que se debe hacer es DNS veces, hay un costo en términos de velocidad de carga de la página. Promedio: simplemente porque se usa más (ha ajax.googleapis.com más) es probable que DNS ajax.microsoft.com antes que ajax.microsoft.com , simplemente porque es más probable que el servidor DNS local lo solicite ( este es un primer usuario en el área de penalización). Esto es algo muy leve 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 ambos CDN, pero en nuestro caso, el tiempo del DNS se ve ensombrecido por el tiempo de espera en el javascript / bloqueo que ocurre)

Por último, si no lo has mirado, una de las mejores herramientas es Firebug , y algunos complementos para ello: Firebug e YSlow . Si usa un CDN pero sus páginas están solicitando imágenes cada vez debido a que no hay encabezados de caché, le falta la fruta que está a la altura. El panel Firebug''s Net puede proporcionarle rápidamente un desglose rápido del tiempo de carga de su página, y Page Speed ​​/ YSlow puede ofrecerle algunas buenas sugerencias para ayudarlo.