Pro e contro degli script ospitati [chiuso]


12

Ho visto alcuni sviluppatori usare script ospitati per collegare le loro librerie.

cdn.jquerytools.org è un esempio.

Ho anche visto persone lamentarsi che un link di script ospitato è stato dirottato.

Quanto è sicuro l'utilizzo degli script ospitati nella realtà? Gli script vengono aggiornati automaticamente? Ad esempio, se jQuery 5 va a 6 ottengo automaticamente la versione 6 o devo aggiornare il mio link?

Vedo anche che Google ha una grande serie di questi script impostati per l'hosting.

Quali sono i pro e i contro?

Risposte:


11

Professionisti

  • Gli script vengono caricati più velocemente . Se disponi di molte risorse che devono essere caricate da un singolo dominio, il tuo browser in genere lo strozzerà in modo da avere solo una manciata di richieste parallele allo stesso host. Quindi, se stai caricando sedici script separati, più immagini e più documenti CSS, ci sarà una coda mentre ogni risorsa attende il suo turno per essere caricata. (Cerca sicuramente di concatenare i tuoi file CSS e Javascript: caricare solo due risorse di script sarà significativamente più veloce).
  • Se si trasformano tali risorse in un dominio separato, tuttavia, il browser non avrà problemi ad aprire connessioni aggiuntive a quel server, il che significa che vengono caricate più risorse contemporaneamente con conseguente esecuzione più veloce della pagina. Stai anche lasciando che un altro server gestisca parte del caricamento della tua pagina, il che è positivo per il tuo server che probabilmente sta lavorando su diverse richieste di esecuzione degli script così come sono.
  • Inoltre, questi server CDN (reti di deviazione del contenuto) sono configurati per funzionare come CDN. Sono in genere senza cucina (per pacchetti di dimensioni inferiori) e sono configurati con un server estremamente leggero che si occupa interamente di servire le risorse e memorizzare nella cache le risorse di uso comune e non tanto con il sollevamento quotidiano che qualcosa di simile a uno standard palustre Si esibirà il server Apache.
  • L'uso di una CDN come Google o Akami ha anche altri vantaggi: Google ha server in tutto il mondo in particolare e i suoi sistemi di routing sono abbastanza intelligenti da accoppiare una richiesta per una risorsa con la copia geografica più vicina esistente. Il tuo server potrebbe tentare di servire jQuery.js a Vladimir in Russia - Google probabilmente ha la stessa risorsa in fondo a Vladimir, riducendo la latenza.
  • Inoltre, poiché molti siti Web utilizzano già queste CDN, è molto probabile che la risorsa che stai servendo sia già stata memorizzata nella cache dall'utente. jQuery.js dal tuo server e jQuery.js dal server di Google non sono trattati come lo stesso file, indipendentemente dal fatto che siano esattamente gli stessi: se carichi da Google, sarà in grado di utilizzare la copia cache dal sito precedente che l'utente ha visitato.
  • I file stessi non cambieranno, specialmente per le risorse di script come i framework Javascript. Se esce una nuova versione, Google continuerà a ospitare la vecchia versione (non importa quanto atroci i bug) in modo specifico in modo che la CDN continui a funzionare normalmente e non serva alcuna cattiva richiesta. Questo è il motivo per cui qualsiasi file CDN è pieno con il numero di versione appropriato.

Contro

  1. È possibile che la tua CDN non sia disponibile. Le probabilità, tuttavia, sono più scarse rispetto alla caduta del tuo sito, probabilmente. I CDN più grandi come Google e Akami hanno più livelli di fail-over.
  2. La creazione di una nuova connessione potrebbe non valerne la pena se hai solo una o due risorse da caricare dal tuo server.
  3. Non hai alcun tipo di controllo sul file che viene pubblicato, quindi l'utilizzo della tua versione personalizzata di jQuery o di qualsiasi altra cosa tu stia tentando di caricare è fuori, a meno che tu non stia pagando la tua CDN.

Sicurezza

Consiglierei questo post di El Stack più una buona quantità di googling sull'argomento. Ogni CDN sarà diverso, anche se in poche parole penso che questa sarebbe una preoccupazione minore.


1

Qualcosa che nessuno ha menzionato è l'ennesima opzione di monitoraggio per Google. Non offrono tutti questi servizi senza alcun costo e senza motivo. AdSense e Analytics sono abbastanza e almeno quelli possono essere filtrati. Questo è un grosso problema nel mio libro.


0

Professionisti:

  • Non è necessario pagare per la larghezza di banda relativa alla pubblicazione dei file e in generale

Contro:

  • Sei soggetto alle disponibilità del provider di hosting che stai utilizzando (se scendono per qualsiasi motivo, anche il tuo down).
  • Sei stato costretto a qualsiasi versione degli script dei provider di hosting

Ci sono altri vantaggi dell'utilizzo di una CDN ma non sono direttamente correlati all'utilizzo di un terzo servizio di hosting di script.


0

Per quanto riguarda le migliori pratiche, l'approccio comune per ottimizzare il caricamento della pagina è raggruppare tutte le risorse JS, a causa del numero limitato di connessioni verso un singolo dominio, come menzionato Jarrod, e l'impostazione di un futuro molto lontano scade l'intestazione nella risposta.

Ciò che i CDN portano a un tale mix, in particolare quelli popolari, come ha anche sottolineato Jarrod, è che l'utente avrebbe già avuto accesso in precedenza all'URL e può recuperare immediatamente la risorsa JS dalla cache del suo client senza nemmeno dover stabilire una connessione.

A tal fine, se tutti usassimo CDN e impiegassimo le migliori pratiche, possiamo salvare l'utente dal recupero di ~ 10-50 KB aggiuntivi quando accedono inizialmente ai nostri URL e consentono loro di caricare le loro pagine più velocemente.

Consiglio vivamente di usare i CDN per due motivi: i contro citati da Jarrod sono lì, veri, ma completamente insignificanti e se stai già raggruppando le tue fonti in un unico documento, costringerai tutti a recuperare, diciamo, la parte statica jQuery di il documento (~ 33 KB) ogni volta che aggiorni una delle risorse raggruppate.

Non so quanto sia importante per te, ma con enormi basi di utenti questo porta a un significativo taglio della larghezza di banda e risparmi significativi, bot dei quali possiamo passare a questioni più urgenti, come lo streaming di porno e l'acquisto di birre.


-2

Non farlo

Personalmente, non farei affidamento su script ospitati da terze parti. Se fai leva sugli script di altre persone, sei alla loro mercé. Ci sono diverse cose da considerare:

  1. Se il loro sito si arresta, la tua pagina potrebbe scadere o scadere.
  2. Se falliscono e disattivano l'hosting, hai perso tutta quella funzionalità
  3. Se vengono hackerati, potresti anche essere hackerato.
  4. Gli script tra siti possono causare danni con i certificati SSL
  5. I tempi di caricamento della pagina possono aumentare notevolmente
  6. Se l'interfaccia cambia, è necessario modificare tutte le chiamate di funzione

Ospitare il codice sul tuo sito è più sicuro, fidati di me. Devi solo bruciarti una volta e avere 250 siti Web che hai creato e l'hosting iniziano a comportarsi in modo divertente perché hai fatto affidamento su uno script ospitato di terza parte che ha smesso di funzionare.


1
Penso che se usi un CDN grande e affidabile probabilmente non dovrai affrontare molte delle tue preoccupazioni. 1.) Mi aspetto che la CDN di Google avrà un ottimo tempo di attività, 2.) Non vedo Google uscire presto dal mercato, 3.) È plausibile, ma mi aspetto di nuovo patch / fix molto veloci, 4 .) Non ho riscontrato alcun problema, 5.) Se si tratta di una CDN rispettabile, i caricamenti di pagine dovrebbero effettivamente essere più veloci di quelli che è possibile servire (tra pipeline, cache multi-sito e domini senza cookie), 6.) Per librerie con versione core come jQuery non dovrebbero esserci problemi.
scunliffe,

1
... inoltre, non c'è nulla che ti impedisca di implementare i tuoi script di fallback in caso di errore di quelli della CDN remota.
scunliffe,

Nessuno di questi motivi elencati nella lista di Cape Cod Gunny sono validi dubbi per i moderni CDN come Google o per i molti altri grandi fornitori di CDN.
Jarrod Nettles,
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.