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

Hay algunas formas de incluir jQuery y jQuery UI y me pregunto qué están usando las personas.

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

Recientemente he estado usando Google JSAPI, pero descubrí que lleva mucho tiempo configurar una conexión SSL o incluso solo 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 de nuestro servidor, pero si sigue siendo la parte lenta del sitio, puedo cambiar la inclusión.

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

Editar: Acabo de visitar el sitio de jQuery y utilizan 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 estado incluyendo 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 necesita preocuparse por cambiar entre http y https.

Sin duda, elijo que JQuery sea atendido por los servidores API de Google. No utilicé 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 API de Google se distribuyen en todo el mundo en lugar de la ubicación de mi único servidor: servidores más cercanos generalmente significa 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 tengan el script JQuery en su caché local. El contenido almacenado en caché 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 una parte de la confianza en Google para servir el archivo de script correcto y estar 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 aparece al cargar 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 8/9/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 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>

Una razón por la que puede querer hospedar en un servidor externo es evitar las limitaciones del navegador de conexiones precisas 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.

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

Si desea utilizar Google, el enlace directo puede ser más receptivo. Cada biblioteca tiene la ruta listada para el archivo directo. Este es el camino 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 enumera en su ejemplo

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

No quisiera que ningún sitio público que desarrolle dependa de un sitio externo, y por lo tanto, alojaría yo mismo jQuery.

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

Pros: Host en Google tiene beneficios

• 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 directamente 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.
• En particular, los usuarios que ejecutan el complemento NoScript para Firefox

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

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 script detienen la carga de la página mientras se recuperan (si es necesario). Ahora, si tardan en cargar, esto es malo, pero jQuery es pequeño. El verdadero problema con el método anterior es que debido a que la carga de jquery.js ocurre de forma independiente para muchas páginas, terminarán de cargarse y renderizarse antes de que jquery se haya cargado, por lo que cualquier estilo de jquery que realice será 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, tener una tabla simple y cambiar 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á un 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 vuelven amarillas.

El segundo problema con el método google.load () es que solo aloja 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 <script src="...">etiqueta ygoogle.load() el complemento probablemente fallará con mensajes de "jQuery no está definido" porque aún no se ha cargado. Realmente no veo una forma de evitar esto.

El tercer problema (con cualquiera de los métodos) es que son una carga externa. Suponiendo que tiene algunos complementos y su propio código Javascript, tiene 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 ponerlo en un archivo minificado.

De API Ajax de Bibliotecas debe usted utilizar Google para alojar? :

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). Entonces eso son 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 el de mi servidor compartido personal, a pesar de que 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 haya cargado y (presumiblemente) en caché. Entonces, para mí, dado que el ancho de banda no importa mucho, no va a importar.

Por último, tiene el posible problema de que un navegador paranoico marque la solicitud como una especie de intento de XSS. Por lo general, no es un problema con la configuración predeterminada, pero en las redes corporativas donde el usuario puede no tener control sobre qué navegador usa, y mucho menos la configuración de seguridad, puede tener un problema.

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

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

Tengo que votar -1 por las bibliotecas alojadas en Google. Están recopilando datos, al estilo de Google Analytics, con sus contenedores alrededor de estas bibliotecas. Como mínimo, no quiero que un navegador cliente haga más de lo que le pido, y mucho menos cualquier otra cosa en la página. En el peor de los casos, esta es la "nueva versión" de Google de no ser malvado: 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, supervisé el tráfico http saliente en mi sitio, y las llamadas periódicas a los servidores de Google no eran algo que esperaba ver.

Puede que sea de la vieja escuela sobre esto, pero todavía frunzo el ceño ante el hotlinking. Quizás Google es la excepción, pero en general, es realmente una buena manera de alojar los archivos en su propio servidor.

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 estamos obteniendo los archivos externos. Esto ha sido intermitente hasta ayer (ahora es persistente). Debido a que era intermitente, tenía muchos problemas para solucionar problemas de usuarios de SaaS. Pasé innumerables 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 preguntarle a un usuario si tiene IPv6 desactivado.

Me topé con el problema porque yo mismo estaba usando esta "ruta" particular para el 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 entregar js maliciosos en lugar del archivo real. Siempre pensé que estaba a salvo porque un dominio de Google nunca se caería, ahora sé que cualquier nodo entre un usuario y el host puede ser un punto de falla.

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, sin duda 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 se desaconsejan primero. Lo sigo lo suficiente como para saber qué cambiar para futuras versiones.

Aquí algunos recursos útiles, espero que puedan ayudarlo a elegir su CDN. MS ha agregado recientemente un nuevo dominio para bibliotecas de entrega a través de su CDN.

Formato anterior: 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.

Si soy responsable del sitio "en vivo", será mejor que esté al tanto de todo lo que está sucediendo en mi sitio. Por esa razón, alojo 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

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>

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

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

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