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


242

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.


8
Darryl, gran edición. ¿Puedo sugerirle que mueva su edición a la parte superior de la página y cambie la srcsintaxis más simple / segura / rápida que usa ahora? Su respuesta se ha vuelto básicamente canónica y ambos cambios ayudarían a las personas a obtener lo que vinieron rápidamente.
Josh Smith el

Respuestas:


153

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>

26
Estoy de acuerdo con las tres razones por las cuales incluyo jquery de Google en mis sitios de producción. En lugar de la inyección dinámica js para páginas SSL, solo hago referencia a la URL en una etiqueta de script sin el protocolo especificado. Parece funcionar bien para mi. <script src = "// ajax.google ..."> </script>
Aaron Wagner

1
Idea interesante ... Pero si vas a usar el envenenamiento de DNS para secuestrar la carga de JQuery, ¿por qué no simplemente secuestrar toda la solicitud del sitio? ¿O qué tal el script de Google Analytics?
Dscoduc

99
También estoy de acuerdo con todo, excepto para simplificar las cosas, utilizo este formato: <script src = "// ajax.google ..."> </script>. Entonces no necesito preocuparme por http o https. Gracias Aaron Wagner por eso.
Darryl Hein

11
¿No veo lo que document.write()se usa? un simple <script src="..."></script>está bien para colocar en el encabezado. → @ Dscoduc: ← no va a ser más rápido, solo va a quitar ese mensaje de advertencia. Si su sitio usa https seguros y está extrayendo contenido no codificado (por ejemplo http://googleapis), recibirá ese mensaje de advertencia. Lo que será un poco más rápido si solo está utilizando http pero está vinculando https://googleapis, hay un poco de sobrecarga con la codificación "segura". Por lo tanto, vincular a http://googleapissería un poco más rápido.
vol7ron

55
También tenga en cuenta que Google lo usará para rastrear los sitios web a los que van los usuarios. Entonces, si está creando un sitio web que necesita ser consciente de la privacidad, entonces alojar un par de archivos pequeños es un pequeño precio a pagar por la privacidad.
Hans-Christoph Steiner

19

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.


1
Otra razón es que los usuarios ya tienen jquery de google en su caché, por lo que es posible que ni siquiera necesiten descargarlo la primera vez que visiten su sitio.
Kip

14

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.


77
Respetuosamente no estoy de acuerdo, en base a su razón declarada. Si obtiene mucho tráfico, los 18k por sesión pueden sumar rápidamente una cantidad considerable de tráfico. Especialmente si su alojamiento web cargos por el ancho de banda utilizado ...
Dscoduc

1
Mi opinión es que solo es una preocupación si sus visitantes solo miran una página. Si su perfil tiene menos visitantes y múltiples visitas a la página, entonces una sobrecarga mínima cuando se distribuye entre las visitas a la página por visitante. Lo mismo para los visitantes que regresan.
Kristen

2
a menos que su sitio web sea absolutamente pequeño, 18k siempre será una pequeña fracción de su tráfico.
Hans-Christoph Steiner

14

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>

3
Usando HTTPS porque el sitio es HTTPS, por lo que tengo que hacerlo.
Darryl Hein

1
¿Todo su contenido está basado en https, o solo parte de él?
Dscoduc

2
Los enlaces http en los sitios https son molestos porque IE (al menos de manera predeterminada) lo molesta con el molesto "Este sitio contiene una mezcla de contenido seguro e inseguro". cajas de confirmación
cletus

1
El sitio de donde proviene el código es completamente SSL: información de contacto extremadamente segura.
Darryl Hein

1
Si le preocupa la seguridad de sus usuarios, use siempre HTTPS para javascript. Sin HTTPS, es bastante fácil hacer man-in-the-middle (MITM) esas solicitudes y servir exploits junto con el javascript que pretendes enviar a las personas. Piense en wifi público, enrutadores domésticos pirateados, etc. como posibles ubicaciones de MITM. Mira todas esas competiciones pwn-to-own: siempre explotan el navegador para entrar.
Hans-Christoph Steiner

8

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.


2
Puse la experiencia del usuario (tiempos de carga rápidos) a la altura con menos dependencias.
Dscoduc

1
@slacy oye tu sitio está caído! jk realidad, pero me di cuenta que está utilizando Google Analytics y tienen su guión al principio en vez de al final - lo que retrasará su sitio abajo fraccionada si Google está siendo lenta
Simon_Weaver

3
hmm ... Slacy está utilizando Google Analytics? ¿No dijo simplemente que no querría que ningún sitio público que desarrollara dependiera de un sitio externo? ;-)
Dscoduc

1
Vaya, muchachos, algunos comentarios duros allí. :) Sí, uso Analytics en mi blog personal, pero ese no es un sitio de producción que genera ingresos, por lo que creo que está realmente bien. Estoy seguro de que mi sitio está inactivo durante muchos días al año. Recuerde, lo que hace para los sitios personales y para el trabajo no es lo mismo
Slacy

66
Hay otras buenas razones para usar la copia local: Google está bloqueado con frecuencia en muchos países como Irán, China, etc. Esto significa que más de mil millones de personas no tendrán acceso.
Hans-Christoph Steiner

6

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.


3
Es contras de Firefox, y no Google,).
Nakilon

6

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í.


No he experimentado ninguno de los problemas que mencionas. Solo cargar cosas en el orden correcto resolverá casi todo hasta donde yo entiendo.
Darryl Hein

4

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.


4

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.


¿Pero ya está ejecutando Google Analytics en su sitio? Puesto que soy supongo que no hace mucha diferencia si el jQuery viene de Google o no, que probablemente ya saben que yo estoy corriendo en mi sitio ...
Dscoduc

Pero está almacenado en caché durante 1 año. ¿Mientras tanto estamos enviando un 304 "Archivo modificado" a Google?
Kristen

Sí, también he visto esas llamadas periódicas a Google (el administrador de actividades de Safari tiene una buena lista).
Darryl Hein

Dscoduc - sí, usando Analytics. Al menos con esa implementación, entendí de antemano que estaba renunciando a los datos de uso. No es así con las bibliotecas JS.
jro

3

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.


3
¿Qué quieres decir con "buenos modales"? Google lo alienta a vincular a su servidor. Es bombeado por la increíble infraestructura de Google.
Nosredna

2
definitivamente hay una confusión al principio cuando escuchas sobre el uso de google. pero, como nosredna dijo, es alentador "Nos quitamos el dolor de alojar las bibliotecas, configuramos correctamente los encabezados de caché, nos mantenemos actualizados con las correcciones de errores más recientes, etc." - code.google.com/apis/ajaxlibs
Simon_Weaver

3

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.


2

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.


1
se encontró que ese método es un poco peligroso, ¿qué pasa si un cambio de código en la biblioteca rompe su sitio? o el sitio jquery se cae? Prefiero tener un control completo sobre el archivo.
Jason Miesionczek

1
Además, odio llegar al ancho de banda de la gente jQuery como este. Ya proporcionan una herramienta gratuita realmente genial, y odiaría que bajaran debido a los costos de ancho de banda. Es mejor usar Google como su fuente externa si no desea alojarlo usted mismo, ya que lo están proporcionando para ese propósito.
nezroy

Recomendaría cambiar para usar Google en lugar de JQuery. La razón principal es que Google probablemente tendría muchos más servidores en todo el mundo que JQuery y, según mi experiencia, más personas usan el alojamiento de Google, lo que aumenta las posibilidades de que ya lo tengan en caché.
Dscoduc

Estoy de acuerdo con Jason, cambiar automáticamente a una versión más nueva es muy peligroso. Quizás no tanto si solo usa jquery, pero con complementos definitivamente no lo recomiendo. Por mi parte, uso un complemento en un sitio que funciona con 1.2.6 pero no 1.3.x (todavía ...)
jeroen

2

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.


1

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


Espero que Google nunca cambie el archivo; para corregir errores, alojarán un nuevo archivo, con un número de versión diferente en el nombre del archivo. ¿O estoy siendo ingenuo? ¿lanzarán "arreglos menores" con el mismo nombre de archivo?
Kristen

Google nunca debería cambiar el archivo si solicita una versión específica.
Darryl Hein

1

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>

0

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 :)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.