Fare riferimento a javascript esterno anziché ospitare la mia copia


42

Supponiamo di avere un'app Web che utilizza jQuery. È buona prassi ospitare i file javascript necessari sui miei server insieme ai file del mio sito Web o fare riferimento a loro sul CDN di jQuery (esempio: http://code.jquery.com/jquery-1.7.1.min.js ) ?

Vedo i professionisti di entrambe le parti:

  • Se è sui miei server, questa è una dipendenza esterna in meno; se jQuery fallisce o cambia la loro struttura di hosting o qualcosa del genere, la mia app si rompe. Ma sento che non accadrà spesso; ci devono essere molti siti di piccole dimensioni che lo fanno e il team di jQuery vorrà evitare di romperli.
  • Se è sui miei server, questo è un riferimento esterno in meno che qualcuno potrebbe chiamare un problema di sicurezza
  • Se è referenziato esternamente, non devo preoccuparmi della larghezza di banda per servire i file (anche se so che non è molto).
  • Se è referenziato esternamente e sto distribuendo questo sito Web a molti server che devono avere le proprie copie di tutti i file, allora è un file in meno che devo ricordare di copiare / aggiornare.

I primi due punti si applicano solo se sei preoccupato che Google vada giù o venga violato.
user16764

1
@ user16764 - o prendono la loro copia di jQuery per qualche motivo (politica, chi lo sa).
Mr. Jefferson,

2
Un altro motivo per non farlo è la privacy. L'uso di contenuti ospitati da terze parti offre a tali terze parti un modo per tracciare gli utenti a cui non possono facilmente rinunciare.
Ian Newson,

anche alcuni CDN, specialmente gli host google, a volte tendono a limitare i file da determinati paesi
azerafati,

Risposte:


58

Dovresti fare entrambe le cose:

Inizia con l'hosting da una CDN come quella di Google perché probabilmente avrà un tempo di attività superiore rispetto al tuo sito e sarà configurato per il tempo di risposta più veloce. Inoltre, chiunque abbia visitato una pagina collegata al CDN utilizzerà la propria copia memorizzata nella cache del file, quindi non dovrà nemmeno scaricare nuovamente una copia, rendendo il caricamento iniziale ancora più veloce.

Quindi aggiungere un riferimento di fallback al proprio server nel caso in cui il CDN sia inattivo (non probabile, ma sicuro è sicuro). I fallback sono relativamente facili da capire, ma devono essere personalizzati per adattarsi allo script utilizzato:

<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"></script>
<script>
    if (!window.jQuery) document.write('<script src="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

Assicurati di non scrivere da </script>nessuna parte all'interno di un <script>elemento, poiché chiuderà l'elemento HTML e causerà il fallimento dello script. La soluzione semplice è quella di utilizzare una barra rovesciata come una via di fuga: <\/script>.


Un motivo in più per fare entrambe le cose:

Se scegli un CDN popolare è altamente improbabile che abbia mai dei tempi di inattività, tuttavia in un futuro molto lontano (~ 18 mesi da adesso data la legge di Moore ) quando il formato di hosting cambia, o l'indirizzo viene modificato, o il la rete è posizionata dietro un paywall o qualsiasi altra cosa, è possibile che il tuo link non funzionerà più così com'è. Se utilizzi un fallback, ti ​​darà un po 'di tempo per adattarti a qualsiasi nuovo formato per l'hosting prima di dover tornare indietro attraverso tutti i siti Web che hai mai creato e modificare i collegamenti CDN.


un altro motivo per fare entrambe le cose:

Di recente sono stato colpito da una serie di interruzioni di Internet. Sono stato in grado di continuare a lavorare localmente su progetti in cui avevo collegato copie locali di risorse di script e ho rapidamente scoperto che c'erano diversi progetti che dovevano essere collegati copie locali.


+1 Ti offre i vantaggi della CDN e copre anche le potenziali insidie.
Quentin-starin,

5
Quale rilevanza è il tempo di attività? Se il suo sito non è attivo, avere il js online non è certo un vantaggio :)
Boris Yankov

3
@BorisYankov, se la CDN è inattiva e il tuo sito è attivo e non hai utilizzato un fallback locale, il tuo sito non funzionerà. Questa è la rilevanza del tempo di attività. Se il tuo sito è inattivo, il tuo sito è inattivo e la copia locale non avrà importanza.
zzzzBov,

CDN avrà anche server in tutto il luogo, quindi otterrai la risorsa dal nodo più vicino.
hanzolo,

35

Ho avuto la stessa domanda, poi ho letto questo articolo e mi è stato venduto l'idea di lasciare che Google ospitasse la mia libreria jQuery.

L'articolo afferma i principali vantaggi di consentire alle librerie di essere ospitate da Content Delivery Network (CDN) di Google:

  • Diminuzione della latenza : gli utenti che non si trovano fisicamente vicino al tuo server saranno in grado di scaricare jQuery più velocemente da Google che se li forzassi a scaricarlo dal tuo server posizionato arbitrariamente.
  • Parallelismo aumentato : i browser limitano il numero di connessioni che è possibile effettuare contemporaneamente. A seconda del browser, questo limite può essere inferiore a due connessioni per nome host. L'uso delle librerie AJAX di Google CDN elimina una richiesta al tuo sito, consentendo di scaricare più contenuti locali in parallelo.
  • Migliore memorizzazione nella cache : utilizzando le librerie AJAX di Google, i tuoi utenti potrebbero non dover scaricare affatto jQuery. D'altra parte, se stai ospitando jQuery localmente, i tuoi utenti devono scaricarlo almeno una volta. Ognuno dei tuoi utenti probabilmente ha già dozzine di copie identiche di jQuery nella cache del browser, ma quelle copie di jQuery vengono ignorate quando visitano il tuo sito.

Per quanto riguarda i due punti elenco che hai elencato come professionisti per l'hosting della tua libreria, ricorda che è Google che ospita la versione cloud e Google sa cosa sta facendo e può essere considerato attendibile per quanto riguarda disponibilità e sicurezza. Tuttavia, @zzzzBov fa un ottimo punto nella sua risposta a questa domanda, dove raccomanda anche di archiviare una copia locale della libreria e di default a quella nel caso improbabile che la versione CDN non sia accessibile per nessun motivo.


4
Ah, sono sicuro di poter fare un lavoro migliore ospitando risorse statiche di Google. ;)
Xeoncross

Non utilizzare entrambi (CDN + fallback locale) è semplicemente sciatto. Peccato che questa sia la risposta principale imho.
Quentin-starin,

@qes Abbastanza giusto, ho aggiunto una nuova frase alla fine della mia risposta.
CFL_Jeff

17

Personalmente, prendo spunto da http://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
<script>!window.jQuery && document.write(unescape('%3Cscript src="includes/js/libs/jquery-1.6.1.min.js"%3E%3C/script%3E'))</script>

Questo estrae il file jQuery principale da Google, ma se non viene caricato per qualche motivo, la riga successiva lo carica dal proprio server.


5
Questo ha l'ulteriore vantaggio di farti sviluppare offline.
RSG

L'uso di un URL relativo al protocollo non è più così utile come una volta (vedere paulirish.com/2010/the-protocol-relative-url ). È ragionevole qui solo digitare https://.
GKFX

5

È una pratica migliore usare una CDN, e se quella CDN è Google, tanto meglio - come hanno notato sia @CFL_Jeff che @Morons.

Sto aggiungendo questa risposta per evidenziare qualcosa che spesso viene trascurato quando si punta altrove, che sta evitando l'avvertimento di contenuto misto . Prendi in considerazione l'utilizzo di URL senza protocollo, ad esempio:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript">
</script>

Ci sono ancora alcuni problemi di supporto nell'uso di URL senza protocollo, quindi dai un'occhiata alle risposte su Posso cambiare tutti i miei link http: // in solo //? su SO, ma almeno prova a gestire i potenziali avvisi di contenuto misto in qualche modo.


4

Dovresti fare riferimento alla Biblioteca di API di Google .

Il motivo principale è accelerare il caricamento della pagina . Se l'utente ha già visitato un altro sito che fa riferimento alla stessa libreria, sarà già archiviato nella cache del browser e non dovrà essere scaricato affatto .


0

Potrei sbagliarmi, ma l'implementazione di document.write sovrascrive qualsiasi cosa abbia il DOM. Poiché è buona norma inserire i file JavaScript alla fine del corpo,

Propongo il seguente metodo basato sulle risposte precedenti:

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

if(!window.jQuery)
{
    //Creates the script element
    var script = document.createElement('script'); 
    //Adds the type attribute with "text/javascript" value
        script.setAttribute('type', 'text/javascript'); 
    //Adds the source attribute and populates it
        script.setAttribute('src', 'Put_The_Relative_Path_To_Your_JavaScript_File_Here'); 
    //Adds it to the end of the body, as it is good practice, to prevent render-blocking.  
    document.body.appendChild(script);

}

//Note that there's no need for you to verify with an onload function, since all scripts
//must be loaded before going to the next one! 

</script>

0

Vorrei aggiungere che l'hosting di una copia locale è una buona pratica perché nessuno dei precedenti afferma qualcosa di correlato a una postura sicura in base alla quale Geo Location e una rigorosa lista bianca sono indispensabili. Non ospitare quel file a livello locale presume di inviare una postura di sicurezza ridotta ai client.


Una politica di sicurezza che mette in blacklist o limita in altro modo la CDN di Google di jQuery sta andando a violare molti siti web, non solo quello del richiedente. In altre parole, ci sono problemi più grandi di cui preoccuparsi.

2
@Snowman ... come il Great Firewall in Cina (che rompe regolarmente i siti Stack Exchange che utilizza un CDN per i suoi script)?
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.