javascript - google - jquery ui cdn

¿De dónde se incluye la biblioteca jQuery? Google JSAPI? CDN?

Question

Hay algunas formas de incluir jQuery y jQuery UI y me pregunto qué está usando la gente.

• Google JSAPI
• sitio de jQuery
• tu propio sitio / servidor
• otro CDN

Recientemente he estado usando Google JSAPI, pero he descubierto que se necesita mucho tiempo para configurar una conexión SSL o incluso para resolver google.com. He estado usando lo siguiente para Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load(''jquery'', ''1.3.1'');
</script>

Me gusta la idea de usar Google, por lo que se almacena en caché al visitar otros sitios y para ahorrar ancho de banda desde nuestro servidor, pero si sigue siendo la parte lenta del sitio, puedo cambiar la inclusión.

¿Que usas? ¿Ha tenido algún problema?

Edición: Acabo de visitar el sitio de jQuery y usan el siguiente método:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

Edit2: Así es como he incluido jQuery sin ningún problema durante el último año:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

La diferencia es la eliminación de http: Al eliminar esto, no tiene que preocuparse por cambiar entre http y https.

Answer 1

Además de las personas que recomiendan alojarlo en un servidor propio, propuse mantenerlo en un dominio separado (por ejemplo, static.website.com) para permitir que los navegadores lo carguen en forma separada de otro hilo de contenido. Este consejo también funciona para todas las cosas estáticas, por ejemplo, imágenes y css.

Answer 2

Agregaré esto como una razón para alojar localmente estos archivos.

Recientemente, un nodo en el sur de California en TWC no ha podido resolver el dominio ajax.googleapis.com (para usuarios con IPv4) solo, por lo que no obtenemos los archivos externos. Esto ha sido intermitente hasta ayer (ahora es persistente). Debido a que era intermitente, tuve muchos problemas para solucionar problemas de usuarios de SaaS. Pasaron incontables horas tratando de rastrear por qué algunos usuarios no tenían problemas con el software y otros se estaban hundiendo. En mi proceso de depuración habitual, no tengo la costumbre de preguntar a un usuario si tienen IPv6 apagado.

Me encontré con el problema porque yo mismo estaba usando esta "ruta" particular al archivo y también estoy usando solo IPV4. Descubrí el problema con las herramientas de los desarrolladores que me decían que jquery no se estaba cargando, luego comencé a hacer traceroutes, etc. para encontrar el problema real.

Después de esto, lo más probable es que nunca vuelva a los archivos alojados externamente porque: Google no tiene que bajar para que esto se convierta en un problema, y ​​... cualquiera de estos nodos puede verse comprometido con el secuestro de DNS y la entrega de js maliciosos en lugar del archivo real. Siempre pensé que estaba seguro de que un dominio de Google nunca bajaría, ahora sé que cualquier nodo entre un usuario y el host puede ser un punto de falla.

Answer 3

Aquí un recurso útil, espero que pueda ayudarle a elegir su CDN. MS ha agregado recientemente un nuevo dominio para las bibliotecas de entrega a través de su CDN.

Formato antiguo: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Nuevo formato: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Esto no debería enviar todas las cookies para microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Aquí algunas estadísticas sobre la tecnología más popular utilizada en la web en toda la tecnología. http://trends.builtwith.com/

La esperanza puede ayudarte a elegir.

Answer 4

En cabeza:

  (function() {
    var jsapi = document.createElement(''script''); jsapi.type = ''text/javascript''; jsapi.async = true;
    jsapi.src = (''https:'' == document.location.protocol ? ''https://'' : ''http://'') + ''www.google.com/jsapi?key=YOUR KEY'';
    (document.getElementsByTagName(''head'')[0] || document.getElementsByTagName(''head'')[0]).appendChild(jsapi);
  })();

Fin del cuerpo:

<script type="text/javascript">
google.load("jquery", "version");
</script>

Answer 5

Hay algunos problemas aquí. En primer lugar, el método de carga asíncrona que especificó:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load(''jquery'', ''1.3.1'');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

tiene un par de problemas Las etiquetas de secuencia de comandos pausan la carga de la página mientras se recuperan (si es necesario). Ahora, si son lentos para cargar esto es malo pero jQuery es pequeño. El problema real con el método anterior es que debido a que la carga de jquery.js ocurre de forma independiente en muchas páginas, terminarán de cargarse y procesarse antes de que se haya cargado jquery, por lo que cualquier estilo de jquery que haga será un cambio visible para el usuario .

La otra forma es:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Pruebe algunos ejemplos simples como, tenga una tabla simple y cambie el fondo de las celdas a amarillo con el método setOnLoadCallback () vs $ (document) .ready () con una carga estática jquery.min.js. El segundo método no tendrá parpadeo notable. La primera voluntad. Personalmente creo que no es una buena experiencia de usuario.

Como ejemplo ejecute esto:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

Usted (debería) ver aparecer la tabla y luego las filas se ponen amarillas.

El segundo problema con el método google.load () es que solo alberga un rango limitado de archivos. Este es un problema para jquery ya que es extremadamente dependiente del complemento. Si intenta incluir un complemento jquery con una etiqueta <script src="..."> y google.load() el complemento probablemente fallará con los mensajes "jQuery no está definido" porque aún no se ha cargado. . Realmente no veo una manera de evitar esto.

El tercer problema (con cualquiera de los métodos) es que son una carga externa. Suponiendo que tenga algunos complementos y su propio código de Javascript, está hasta un mínimo de dos solicitudes externas para cargar su Javascript. Probablemente sea mejor obtener jquery, todos los complementos relevantes y su propio código y colocarlo en un archivo minificado.

¿Debería usar la API de bibliotecas Ajax de Google para hospedar? :

En cuanto a los tiempos de carga, en realidad está cargando dos scripts: el script jsapi y el script mootools (la versión comprimida de arriba). Así que eso es dos conexiones, en lugar de una. En mi experiencia, descubrí que el tiempo de carga era en realidad 2-3 veces más lento que la carga desde mi propio servidor compartido personal, aunque provenía de Google, y mi versión del archivo comprimido era un par de K más grande que la de Google. Esto, incluso después de que el archivo se hubiera cargado y (probablemente) guardado en caché. Así que para mí, ya que el ancho de banda no importa mucho, no va a importar.

Por último, tiene el problema potencial de que un navegador paranoico marque la solicitud como un intento de XSS. No suele ser un problema con la configuración predeterminada, pero en las redes corporativas donde el usuario puede no tener control sobre el navegador que utilizan, por no hablar de la configuración de seguridad, es posible que tenga un problema.

Entonces, al final, realmente no puedo verme usando la API de AJAX de Google para jQuery (las API más "completas" son una historia diferente en algunos aspectos), excepto por publicar ejemplos aquí.

Answer 6

Lo alojo con mis otros archivos js en mi propio servidor, y ese es el punto, los combino y minimizo (con django-compresser, aquí, pero ese no es el punto) para que se sirva como un solo archivo js, ​​con todo lo que el sitio necesidades puestas en ello. De todos modos, tendrá que servir sus propios archivos js, así que no veo ninguna razón para no agregar los bytes de jquery adicionales allí también: algunos kbs más son mucho más baratos de transferir que más solicitudes que realizar. No eres dependiente de nadie, y tan pronto como tu js minificado se almacena en caché, también eres súper rápido.

En la primera carga, puede ganar una solución basada en CDN, ya que debe cargar los kilobytes de jquery adicionales desde su propio servidor (pero, sin una solicitud adicional). Aunque dudo que la diferencia sea notable. Y luego, en una primera carga con caché borrada, su propia solución hospedada probablemente siempre será mucho más rápida, debido a que se necesitan más solicitudes (y búsquedas de DNS), para obtener el jQuery de CDN.

Me pregunto cómo este punto casi nunca se menciona, y cómo los CDN parecen apoderarse del mundo :)

Answer 7

No querría que ningún sitio público que desarrollé dependiera de ningún sitio externo y, por lo tanto, yo mismo alojaría jQuery.

¿Está dispuesto a tener una interrupción en su sitio cuando el otro (Google, jquery.com, etc.) se cae? Menos dependencias es la clave.

Answer 8

Pros: Host en Google tiene ventajas

• Probablemente más rápido (sus servidores están más optimizados)
• Manejan el almacenamiento en caché correctamente: 1 año (luchamos para que se nos permita hacer los cambios para obtener los encabezados en nuestros servidores)
• Los usuarios que ya han tenido un enlace a la versión alojada por Google en otro dominio ya tienen el archivo en su caché

Contras:

• Algunos navegadores pueden verlo como un dominio cruzado XSS y no permitir el archivo.
• Particularmente los usuarios que ejecutan el complemento NoScript para Firefox

Me pregunto si puede INCLUIR de Google, y luego verificar la presencia de alguna variable global, o algo así, y si la ausencia se carga desde su servidor.

Answer 9

Puede que sea de la vieja escuela sobre esto, pero sigo frunciendo el ceño con el ceño fruncido. Tal vez Google sea la excepción, pero en general, son realmente buenos modales para alojar los archivos en su propio servidor.

Answer 10

Si desea utilizar Google, el enlace directo puede ser más sensible. Cada biblioteca tiene la ruta indicada para el archivo directo. Este es el camino de jQuery.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Simplemente vuelva a leer su pregunta, ¿hay alguna razón por la que esté usando https? Esta es la etiqueta de script que Google pone en su ejemplo.

<script src="http://www.google.com/jsapi"></script>
<script>

Answer 11

Si soy responsable del sitio ''en vivo'', será mejor que esté al tanto de todo lo que está sucediendo en mi sitio. Por ese motivo, yo mismo instalo la versión jquery-min en el mismo servidor o en un servidor estático / externo, pero de cualquier manera, una ubicación donde solo yo (o mi programa / proxy) puedo actualizar la biblioteca después de haber verificado / probado cada cambio.

Answer 12

Sin lugar a dudas, elijo que los servidores de la API de Google sirvan a JQuery. No opté por el método jsapi ya que no aprovecho ninguna otra API de Google, sin embargo, si eso cambiara, lo consideraría ...

Primero: los servidores de Google Api se distribuyen en todo el mundo en lugar de mi única ubicación de servidor: servidores más cercanos generalmente significan tiempos de respuesta más rápidos para el visitante.

Segundo: muchas personas optan por tener JQuery alojado en Google, por lo que cuando un visitante visita mi sitio, es posible que ya tenga el script de JQuery en su caché local. El contenido pre-cacheado generalmente significa tiempos de carga más rápidos para el visitante.

Tercero: mi empresa de alojamiento web me cobra por el ancho de banda utilizado. No tiene sentido consumir 18k por sesión de usuario si el visitante puede obtener el mismo archivo en otro lugar.

Entiendo que confío en Google para que sirva el archivo de script correcto, y que esté en línea y disponible. Hasta este momento no me ha decepcionado el uso de Google y continuaré esta configuración hasta que tenga sentido no hacerlo.

Una cosa que vale la pena señalar ... Si tiene una combinación de páginas seguras e inseguras en su sitio, es posible que desee cambiar dinámicamente la fuente de Google para evitar la advertencia habitual que se ve cuando se carga contenido inseguro en una página segura:

Esto es lo que se me ocurrió:

<script type="text/javascript">
    document.write([
        "/<script src=''",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js'' type=''text/javascript''>/<//script>" 
    ].join(''''));
</script>

ACTUALIZACIÓN 9/8/2010 - Se han hecho algunas sugerencias para reducir la complejidad del código al eliminar HTTP y HTTPS y simplemente usar la siguiente sintaxis:

<script type="text/javascript">
    document.write("/<script src=''//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js'' type=''text/javascript''>/<//script>");
</script>

Además, también puede cambiar la URL para reflejar el número principal de jQuery si desea asegurarse de que se haya cargado la última versión principal de las bibliotecas de jQuery:

<script type="text/javascript">
    document.write("/<script src=''//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'' type=''text/javascript''>/<//script>");
</script>

Finalmente, si no desea usar Google y prefiere jQuery, puede usar la siguiente ruta de origen (tenga en cuenta que jQuery no admite conexiones SSL):

<script type="text/javascript">
    document.write("/<script src=''http://code.jquery.com/jquery-latest.min.js'' type=''text/javascript''>/<//script>");
</script>

Answer 13

Solo incluyo la última versión del sitio jQuery: http://code.jquery.com/jquery-latest.pack.js Se adapta a mis necesidades y nunca tengo que preocuparme por la actualización.

EDITAR: Para una aplicación web importante, ciertamente controlarla; Descárgalo y sírvelo tú mismo. Pero para mi sitio personal, no podría importarme menos. Las cosas no desaparecen por arte de magia, por lo general son despreciadas primero. Me mantengo al día lo suficiente como para saber qué cambiar para futuros lanzamientos.

Answer 14

Tengo que votar -1 para las bibliotecas alojadas en Google. Están recolectando datos, al estilo de Google Analytics, con sus envoltorios alrededor de estas bibliotecas. Como mínimo, no quiero que el navegador del cliente haga más de lo que le pido que haga, y mucho menos nada más en la página. En el peor de los casos, esta es la "nueva versión" de Google de no ser malo: usar javascript discreto para recopilar más datos de uso.

Nota: si han cambiado esta práctica, super. Pero la última vez que consideré usar sus bibliotecas alojadas, monitoreé el tráfico http saliente en mi sitio, y las llamadas periódicas a los servidores de Google no eran algo que esperaba ver.

Answer 15

Una razón por la que quizás desee alojar en un servidor externo es evitar las limitaciones del navegador de las conexiones concurrentes a un servidor en particular.

Sin embargo, dado que el archivo jQuery que está utilizando probablemente no cambiará muy a menudo, la memoria caché del navegador se activará y hará que ese punto sea discutible en su mayor parte.

La segunda razón para alojarlo en un servidor externo es reducir el tráfico a su propio servidor.

Sin embargo, dado el tamaño de jQuery, es probable que sea una pequeña parte de su tráfico. Probablemente deberías intentar optimizar tu contenido real.

Answer 16

jQuery 1.3.1 min solo tiene 18k de tamaño. No creo que sea demasiado para preguntar en la carga de la página inicial. Será almacenado en caché después de eso. Como resultado, lo recibo yo mismo.