Da dove includi la libreria jQuery? Google JSAPI? CDN?


242

Ci sono alcuni modi per includere l'interfaccia utente di jQuery e jQuery e mi chiedo cosa stiano usando le persone?

  • Google JSAPI
  • sito di jQuery
  • il tuo sito / server
  • un altro CDN

Recentemente sto usando Google JSAPI, ma ho scoperto che ci vuole molto tempo per impostare una connessione SSL o anche solo per risolvere google.com. Ho usato il seguente per Google:

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

Mi piace l'idea di utilizzare Google, quindi è memorizzato nella cache quando si visitano altri siti e per risparmiare larghezza di banda dal nostro server, ma se continua a essere la parte lenta del sito, posso cambiare l'inclusione.

Cosa usi? Hai avuto problemi?

Modifica: appena visitato il sito di jQuery e usano il seguente metodo:

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

Edit2: Ecco come ho incluso jQuery senza problemi nell'ultimo anno:

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

La differenza è la rimozione di http:. Rimuovendolo, non devi preoccuparti di passare da http a https.


8
Darryl, ottima modifica. Potrei suggerire di spostare la modifica nella parte superiore della pagina e cambiare la srcsintassi più semplice / più sicura / più veloce che usi ora? La tua risposta è diventata sostanzialmente canonica ed entrambi i cambiamenti aiuterebbero le persone a ottenere rapidamente ciò per cui sono venute.
Josh Smith,

Risposte:


153

Senza dubbio ho scelto di far funzionare JQuery dai server API di Google. Non sono andato con il metodo jsapi poiché non faccio leva su altre API di Google, tuttavia se fosse mai cambiato, lo prenderei in considerazione ...

Primo: i server API di Google sono distribuiti in tutto il mondo anziché nella posizione del mio singolo server: server più vicini di solito significano tempi di risposta più rapidi per il visitatore.

Secondo: molte persone scelgono di ospitare JQuery su Google, quindi quando un visitatore arriva sul mio sito potrebbe già avere lo script JQuery nella propria cache locale. Il contenuto pre-memorizzato nella cache di solito significa tempi di caricamento più rapidi per il visitatore.

Terzo: la mia società di web hosting mi addebita la larghezza di banda utilizzata. Non ha senso consumare 18k per sessione utente se il visitatore può ottenere lo stesso file altrove.

Comprendo di affidare una parte di fiducia a Google per pubblicare il file di script corretto ed essere online e disponibile. Fino a questo punto non sono rimasto deluso dall'utilizzo di Google e continuerò questa configurazione fino a quando non ha senso non farlo.

Una cosa degna di nota ... Se hai un insieme di pagine sicure e insicure sul tuo sito, potresti voler cambiare dinamicamente la fonte di Google per evitare il solito avviso che vedi quando carichi contenuti non sicuri in una pagina sicura:

Ecco cosa mi è venuto in mente:

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

AGGIORNAMENTO 9/8/2010 - Alcuni suggerimenti sono stati fatti per ridurre la complessità del codice rimuovendo HTTP e HTTPS e semplicemente usando la sintassi seguente:

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

Inoltre, è possibile modificare l'URL per riflettere il numero maggiore di jQuery se si desidera assicurarsi che sia stata caricata l'ultima versione principale delle librerie jQuery:

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

Infine, se non si desidera utilizzare Google e si preferisce jQuery, è possibile utilizzare il seguente percorso di origine (tenere presente che jQuery non supporta le connessioni SSL):

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

26
Sono d'accordo con tutti e tre i tuoi motivi, motivo per cui includo jquery di Google sui miei siti di produzione. Invece dell'iniezione dinamica js per le pagine SSL ho appena fatto riferimento all'URL in un tag di script senza il protocollo specificato. Sembra funzionare bene per me. <script src = "// ajax.google ..."> </script>
Aaron Wagner,

1
Idea interessante ... Ma se hai intenzione di utilizzare l'avvelenamento DNS per dirottare il carico di JQuery, perché non dirottare l'intera richiesta del sito? O per quanto riguarda lo script di Google Analytics?
Dscoduc,

9
Concordo anche con tutto, tranne che per semplificare le cose, utilizzo questo formato: <script src = "// ajax.google ..."> </script>. Quindi non devo preoccuparmi di http o https. Grazie Aaron Wagner per questo.
Darryl Hein,

11
Non vedo cosa document.write()viene utilizzato? <script src="..."></script>va bene inserire un semplice nell'intestazione. → @ Dscoduc: ← non sarà più veloce, porterà semplicemente via quel messaggio di avviso. Se il tuo sito utilizza https sicuro e stai estraendo un contenuto non codificato (ad esempio http://googleapis), riceverai quel messaggio di avviso. Cosa sarà un po 'più veloce se stai usando solo http ma stai collegando https://googleapis, c'è un po' di sovraccarico con la codifica "sicura". Pertanto, il collegamento a http://googleapissarebbe un po 'più veloce.
vol7ron,

5
Inoltre, tieni presente che Google lo utilizzerà quindi per tracciare i siti Web visitati dagli utenti. Quindi, se stai creando un sito Web che deve essere consapevole della privacy, l'hosting di un paio di file di piccole dimensioni è un piccolo prezzo da pagare per la privacy.
Hans-Christoph Steiner,

19

Un motivo per cui potresti voler ospitare su un server esterno è aggirare le limitazioni del browser di connessioni simultanee a un determinato server.

Tuttavia, dato che il file jQuery che stai utilizzando probabilmente non cambierà molto spesso, la cache del browser si avvierà e farà sì che quel punto venga ignorato per la maggior parte.

Il secondo motivo per ospitarlo su un server esterno è quello di ridurre il traffico verso il proprio server.

Tuttavia, data la dimensione di jQuery, è probabile che sarà una piccola parte del tuo traffico. Probabilmente dovresti provare a ottimizzare il tuo contenuto reale.


1
un altro motivo: le probabilità sono che gli utenti abbiano già jquery da google nella loro cache, quindi potrebbe non essere nemmeno necessario scaricarlo la prima volta che visitano il tuo sito.
Salta il

14

jQuery 1.3.1 min ha una dimensione di soli 18k. Non penso che sia un grande successo da chiedere al caricamento della pagina iniziale. Successivamente verrà memorizzato nella cache. Di conseguenza, lo ospito io stesso.


7
Sono in disaccordo con il rispetto, in base al motivo dichiarato. Se ricevi molto traffico, i 18.000 per sessione possono rapidamente aggiungere una notevole quantità di traffico. Soprattutto se il tuo hosting web viene addebitato dalla larghezza di banda utilizzata ...
Dscoduc,

1
La mia opinione è che ciò preoccupa solo se i tuoi visitatori guardano solo una pagina. Se il tuo profilo è composto da un minor numero di visitatori e più visualizzazioni di pagina, quindi un sovraccarico minimo se distribuito su visualizzazioni di pagina per visitatore. Idem per i visitatori di ritorno.
Kristen

2
a meno che il tuo sito web non sia assolutamente minuscolo, 18k sarà sempre una piccola parte del tuo traffico.
Hans-Christoph Steiner,

14

Se si desidera utilizzare Google, il collegamento diretto potrebbe essere più reattivo. Ogni libreria ha il percorso elencato per il file diretto. Questo è il percorso jQuery

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

Rileggi la tua domanda, c'è un motivo per cui stai usando https? Questo è il tag di script che Google elenca nel loro esempio

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

3
Utilizzando HTTPS perché il sito è HTTPS, quindi è necessario.
Darryl Hein,

1
Tutti i tuoi contenuti sono basati su https o solo in parte?
Dscoduc,

2
I collegamenti http su siti https sono fastidiosi perché IE (almeno per impostazione predefinita) ti infastidisce con fastidiosi "Questo sito contiene una miscela di contenuti sicuri e insicuri". caselle di conferma.
cletus,

1
Il sito da cui proviene il codice è completamente SSL - informazioni di contatto estremamente sicure.
Darryl Hein,

1
Se ti preoccupi della sicurezza dei tuoi utenti, usa sempre HTTPS per javascript. Senza HTTPS, è abbastanza facile gestire le richieste e gestire gli exploit insieme al javascript che si intende inviare alle persone. Pensa al wifi pubblico, ai router domestici hackerati, ecc. Come possibili posizioni MITM. Guarda tutte quelle competizioni pwn-to-own: sfruttano sempre il browser per entrare.
Hans-Christoph Steiner

8

Non vorrei che nessun sito pubblico che sviluppassi dipendesse da alcun sito esterno e quindi ospiterei jQuery da solo.

Sei disposto ad avere un'interruzione sul tuo sito quando l'altro (Google, jquery.com, ecc.) Si interrompe? Meno dipendenze è la chiave.


2
Ho messo l'esperienza utente (tempi di caricamento rapidi) proprio lì con meno dipendenze.
Dscoduc,

1
@slacy hey il tuo sito non funziona! in realtà jk, ma ho notato che stai usando google analytics e hai il loro script all'inizio invece della fine - che rallenterà il tuo sito in modo frazionario se google è lento
Simon_Weaver

3
hmm ... slacy sta usando Google Analytics? Non ha semplicemente detto che non vorrebbe che un sito pubblico da lui sviluppato dipendesse da un sito esterno? ;-)
Dscoduc,

1
Wow, ragazzi, alcuni commenti aspri lì. :) Sì, utilizzo Analytics sul mio blog personale, ma non è un sito di produzione che genera entrate, quindi penso che vada davvero bene. Sono sicuro che il mio sito è inattivo da molti giorni all'anno. Ricorda, quello che fai per i siti personali e per il lavoro non è lo stesso
slacy

6
Ci sono altri buoni motivi per usare la copia locale: Google è spesso bloccato in molti paesi come l'Iran, la Cina, ecc. Ciò significa che ben oltre un miliardo di persone non avranno accesso.
Hans-Christoph Steiner,

6

Pro: Host su Google ha dei vantaggi

  • Probabilmente più veloce (i loro server sono più ottimizzati)
  • Gestiscono correttamente la memorizzazione nella cache - 1 anno (facciamo fatica a fare le modifiche per ottenere le intestazioni direttamente sui nostri server)
  • Gli utenti che hanno già avuto un collegamento alla versione ospitata da Google su un altro dominio hanno già il file nella loro cache

Contro:

  • Alcuni browser potrebbero vederlo come XSS tra domini e non consentire il file.
  • In particolare gli utenti che eseguono il plug-in NoScript per Firefox

Mi chiedo se puoi INCLUDERE da Google e quindi verificare la presenza di alcune variabili globali, o qualcosa del genere, e se l'assenza si carica dal tuo server?


3
Sono i contro di Firefox, non quelli di Google.)
Nakilon

6

Ci sono alcuni problemi qui. Innanzitutto, il metodo di caricamento asincrono specificato:

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

ha un paio di problemi. I tag di script sospendono il caricamento della pagina mentre vengono recuperati (se necessario). Ora, se sono lenti a caricare questo è male, ma jQuery è piccolo. Il vero problema con il metodo sopra è che poiché il caricamento di jquery.js avviene in modo indipendente per molte pagine, finiranno di caricarsi e renderizzarsi prima che jquery sia caricato, quindi qualsiasi stile jquery che fai sarà una modifica visibile per l'utente .

L'altro modo è:

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

Prova alcuni semplici esempi come, avere una tabella semplice e cambiare lo sfondo delle celle in giallo con il metodo setOnLoadCallback () vs $ (document) .ready () con un carico statico jquery.min.js. Il secondo metodo non avrà sfarfallio evidente. La prima volontà. Personalmente penso che non sia una buona esperienza utente.

Ad esempio, esegui questo:

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

Dovresti (vedere) apparire la tabella e poi le righe diventano gialle.

Il secondo problema con il metodo google.load () è che ospita solo un intervallo limitato di file. Questo è un problema per jquery poiché è estremamente dipendente dal plug-in. Se si tenta di includere un plug-in jquery con un <script src="...">tag e google.load()il plug-in probabilmente non funzionerà con i messaggi di "jQuery non definito" perché non è stato ancora caricato. Non vedo davvero un modo per aggirare questo.

Il terzo problema (con entrambi i metodi) è che si tratta di un carico esterno. Supponendo che tu abbia alcuni plugin e il tuo codice Javascript, puoi caricare fino a due richieste esterne per caricare il tuo Javascript. Probabilmente stai meglio ottenere jquery, tutti i plug-in rilevanti e il tuo codice e metterlo in un file minimizzato.

Da dove dovresti usare l'API delle librerie Ajax di Google per l'hosting? :

Per quanto riguarda i tempi di caricamento, in realtà stai caricando due script: lo script jsapi e lo script mootools (la versione compressa dall'alto). Quindi sono due connessioni, anziché una. Nella mia esperienza, ho scoperto che il tempo di caricamento era in realtà 2-3 volte più lento rispetto al caricamento dal mio server condiviso personale, anche se proveniva da Google, e la mia versione del file compresso era un paio di K più grande di quella di Google. Questo, anche dopo che il file è stato caricato e (presumibilmente) memorizzato nella cache. Quindi per me, dal momento che la larghezza di banda non conta molto, non importa.

Infine hai il potenziale problema di un browser paranoico che contrassegna la richiesta come una sorta di tentativo XSS. In genere non si tratta di un problema con le impostazioni predefinite, ma su reti aziendali in cui l'utente potrebbe non avere il controllo su quale browser utilizzano, per non parlare delle impostazioni di sicurezza che potresti avere un problema.

Quindi alla fine non riesco davvero a vedermi usare l'API AJAX di Google per jQuery (le API più "complete" sono in qualche modo una storia diversa) se non per pubblicare esempi qui.


Non ho riscontrato nessuno dei problemi menzionati. Caricare le cose nell'ordine giusto risolverà praticamente tutto ciò che ho capito.
Darryl Hein,

4

Oltre alle persone che consigliano di ospitarlo sul proprio server, avevo proposto di tenerlo su un dominio separato (ad esempio static.website.com) per consentire ai browser di caricarlo in un thread separato da altri contenuti. Questo suggerimento funziona anche con tutte le cose statiche, ad esempio immagini e CSS.


4

Devo votare -1 per le biblioteche ospitate su Google. Stanno raccogliendo dati, in stile Google Analytics, con i loro wrapper attorno a queste librerie. Come minimo, non voglio che un browser client faccia più di quello che gli sto chiedendo di fare, tanto meno qualsiasi altra cosa sulla pagina. Nel peggiore dei casi, questa è la "nuova versione" di Google per non essere malvagi - utilizzando JavaScript non invadente per raccogliere più dati di utilizzo.

Nota: se hanno cambiato questa pratica, super. Ma l'ultima volta che ho pensato di utilizzare le loro librerie ospitate, ho monitorato il traffico http in uscita sul mio sito e le chiamate periodiche ai server di Google non erano qualcosa che mi aspettavo di vedere.


Ma stai già eseguendo Google Analytics sul tuo sito? Dal momento che non credo che faccia molta differenza se JQuery provenga da Google o meno, probabilmente sanno già che lo sto eseguendo sul mio sito ...
Dscoduc,

Ma è memorizzato nella cache per 1 anno - nel frattempo stiamo anche inviando un 304 "File modificato" a Google?
Kristen,

Sì, ho visto anche quelle periodiche chiamate a Google (il gestore delle attività di Safari ha una bella lista).
Darryl Hein,

Dscoduc - sì, usando Analytics. Almeno con quella implementazione, ho capito in anticipo che stavo rinunciando ai dati di utilizzo. Non così con le librerie JS.
jro,

3

Potrei essere di vecchia scuola su questo, ma ancora aggrotto le sopracciglia su hotlinking. Forse Google è l'eccezione, ma in generale è davvero solo una buona educazione ospitare i file sul proprio server.


3
Cosa intendi con "buone maniere?" Google ti incoraggia a collegarti al suo server. È pompato dall'incredibile infrastruttura di Google.
Nosredna,

2
c'è sicuramente una confusione all'inizio quando si sente parlare dell'utilizzo di google. ma come ha detto nosredna è incoraggiato "Facciamo in modo di ospitare le librerie, impostare correttamente le intestazioni della cache, rimanere aggiornati con le più recenti correzioni di bug, ecc." - code.google.com/apis/ajaxlibs
Simon_Weaver,

3

Aggiungerò questo come motivo per ospitare localmente questi file.

Recentemente un nodo nel sud della California su TWC non è stato in grado di risolvere il dominio ajax.googleapis.com (per utenti con IPv4) solo quindi non stiamo ottenendo i file esterni. Questo è stato intermittente fino a ieri (ora è persistente.) Dato che era intermittente, avevo molti problemi a risolvere i problemi degli utenti SaaS. Trascorse innumerevoli ore nel tentativo di rintracciare il motivo per cui alcuni utenti non avevano problemi con il software e altri erano in carreggiata. Nel mio solito processo di debug non ho l'abitudine di chiedere a un utente se IPv6 è disattivato.

Mi sono imbattuto in questo problema perché io stesso stavo usando questo particolare "percorso" per il file e sto usando solo IPV4. Ho scoperto il problema con gli strumenti per sviluppatori che mi dicevano che jquery non si stava caricando, quindi ho iniziato a fare traceroute ecc ... per trovare il vero problema.

Dopo questo, molto probabilmente non tornerò mai più ai file ospitati esternamente perché: google non deve scendere perché questo diventi un problema e ... nessuno di questi nodi può essere compromesso dal dirottamento DNS e fornire js dannosi invece del file effettivo. Ho sempre pensato di essere al sicuro in quanto un dominio google non sarebbe mai andato giù, ora so che qualsiasi nodo tra un utente e l'host può essere un punto di errore.


2

Includo solo l'ultima versione dal sito jQuery: http://code.jquery.com/jquery-latest.pack.js Si adatta alle mie esigenze e non devo mai preoccuparmi dell'aggiornamento.

EDIT: per un'importante app Web, certamente controllala; scaricalo e servilo tu stesso. Ma per il mio sito personale, non me ne può fregare di meno. Le cose non scompaiono magicamente, di solito sono prima deprecate. Lo tengo abbastanza per sapere cosa cambiare per le versioni future.


1
ho scoperto che quel metodo è un po 'pericoloso, e se un cambio di codice nella libreria rompe il tuo sito? o il sito jquery non funziona? preferirei avere il controllo completo sul file.
Jason Miesionczek,

1
Inoltre, odio colpire la larghezza di banda della gente di jQuery in questo modo. Forniscono già uno strumento gratuito davvero interessante e non sopporterei il loro calo a causa dei costi della larghezza di banda. Meglio usare Google come fonte esterna se non si desidera ospitarlo da soli, poiché lo stanno fornendo a tale scopo.
Nezroy,

Consiglierei di passare a utilizzare Google invece di JQuery. Il motivo principale è che Google avrebbe probabilmente molti più server in tutto il mondo rispetto a JQuery e dalla mia esperienza più persone usano l'hosting di Google, il che aumenta le tue possibilità di averlo già memorizzato nella cache.
Dscoduc,

Sono d'accordo con Jason, il passaggio automatico a una versione più recente è molto pericoloso. Forse non tanto se usi solo jquery, ma con i plugin non lo consiglio vivamente. Io per primo uso un plugin su un sito che funziona con 1.2.6 ma non 1.3.x (ancora ...)
jeroen,

2

Ecco qualche risorsa utile, la speranza può aiutarti a scegliere il tuo CDN. MS ha recentemente aggiunto un nuovo dominio per le biblioteche di consegna tramite la loro CDN.

Vecchio formato: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Nuovo formato: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Questo non dovrebbe inviare tutti i cookie per microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Ecco alcune statistiche sulla tecnologia più popolare utilizzata sul web in tutta la tecnologia. http://trends.builtwith.com/

La speranza può aiutarti a scegliere.


1

Se sono responsabile del sito "live", è meglio essere consapevoli di tutto ciò che sta accadendo e nel mio sito. Per tale motivo, ospito personalmente la versione jquery-min sullo stesso server o su un server statico / esterno ma in entrambi i casi un percorso in cui solo io (o il mio programma / proxy) posso aggiornare la libreria dopo aver verificato / testato ogni modifica


Spero che Google non cambierà mai il file - per le correzioni di errori ospiterà un nuovo file, con un numero di versione diverso nel nome del file. O sono ingenuo? lanceranno "Correzioni minori" usando lo stesso nome di file ??
Kristen,

Google non dovrebbe mai modificare il file se si richiede una versione specifica.
Darryl Hein,

1

In testa:

  (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);
  })();

Fine del corpo:

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

0

Lo ospito con gli altri miei file js sul mio server e, a quel punto, li combino e li minimizzo (con django-compresser, qui, ma non è questo il punto) per essere serviti come un solo file js, con tutto il sito ha bisogno di metterci dentro. Dovrai comunque servire i tuoi file js, quindi non vedo alcun motivo per non aggiungere anche i byte jquery extra lì - alcuni kb in più sono molto più economici da trasferire, di più richieste da fare. Non sei dipendente da nessuno e non appena la tua js minimizzata viene memorizzata nella cache, sei anche super veloce.

Al primo caricamento, potrebbe vincere una soluzione basata su CDN, poiché è necessario caricare i kilobyte jquery aggiuntivi dal proprio server (ma, senza una richiesta aggiuntiva). Dubito che la differenza sia evidente, però. E quindi, al primo caricamento con cache svuotata, la tua soluzione ospitata sarà probabilmente sempre molto più veloce, a causa delle ulteriori richieste (e ricerche DNS) necessarie, per recuperare il jquery CDN.

Mi chiedo come questo punto non sia quasi mai menzionato e come i CDN sembrano prendere il controllo del mondo :)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.