Questo può essere ovvio per alcuni, ma mi chiedevo: perché dovrei dipendere dal server di Google per ospitare jQuery per il mio sito?
È solo perché si carica più velocemente in questo modo?
Questo può essere ovvio per alcuni, ma mi chiedevo: perché dovrei dipendere dal server di Google per ospitare jQuery per il mio sito?
È solo perché si carica più velocemente in questo modo?
Risposte:
Questo è perché:
Esistono diversi scenari in cui potresti non voler utilizzare jQuery dal CDN di Google:
Quando si crea un'applicazione intranet in cui il server Web è ospitato sulla stessa rete dei client. Se si utilizza jQuery di CDN di Google, si effettuerà una chiamata a Internet anziché a un server Web sulla rete locale. Ciò aumenta la larghezza di banda per l'organizzazione ed è più lento.
Quando si desidera eseguire l'applicazione offline . (Abbastanza collegato al primo problema) Se devi lavorare su un ambiente di sviluppo (gestito ad esempio con Bower ), potresti dover essere in grado di far funzionare la tua applicazione senza alcuna connessione a Internet (es .: in un treno :)
Quando è necessario personalizzarlo . Ad esempio se si utilizza Grunt per creare la libreria al fine di utilizzare solo determinati moduli o impostare il nome AMD
Quando offri pagine su SSL che richiedono jQuery. Dovresti pubblicare JavaScript su SSL e la tua pagina per evitare problemi di sicurezza e avvisi.
Inoltre, Microsoft ospita jQuery sul proprio CDN. Questa è un'altra scelta paragonabile all'utilizzo di jQuery ospitato da Google.
src="//ajax.googleapis.com/..."
, funzionano.
Questo studio di TJ VanToll mi ha convinto che è meglio concatenare jQuery con altri script piuttosto che caricarlo da un CDN.
Il motivo è la latenza coinvolta nel recupero di jQuery su dispositivi mobili:
"Nel 2012 il tempo medio di RTT su una rete mobile negli Stati Uniti era di 344 ms. E quel 344 ms si applica non solo a tutte le richieste HTTP - di cui la pagina Web media fa ora 93 - ma anche a tutte le ricerche DNS e connessioni TCP ... Mentre i RTT medi stanno migliorando, ci sono solo piccoli guadagni aggiuntivi da ottenere, poiché le reti attuali rientrano in un piccolo fattore del limite teorico dettato dalla fisica ".
Cita anche questo post di Steve Souders che mostra perché è improbabile che tu possa ottenere i benefici della cache dall'uso di una CDN:
"A causa della frammentazione dei provider CDN, delle versioni jQuery e dell'utilizzo del protocollo (http vs. https), le possibilità di ottenere un hit della cache CDN sono sorprendentemente basse - e il download da un dominio esterno ha il potenziale per eseguire non uno, ma tre round trip (una ricerca DNS, una connessione TCP e un HTTP GET). "
Il più grande vantaggio è dalla memorizzazione nella cache. La teoria è che se un visitatore ha visitato un sito che stava caricando le proprie librerie JavaScript, ad esempio jQuery dalla CDN di Google, quindi quando visitano il tuo sito Web, la libreria si trova già nella cache del browser dell'utente e non dovrà essere nuovamente scaricata . Suona benissimo in teoria.
I vantaggi condivisi qui e altrove sono tutti teorici. Ho appena riscontrato un'analisi approfondita dell'utilizzo di una CDN e se fornisce i benefici prestazionali previsti. http://www.root777.com/appdev/does-using-google-libraries-api-cdn-give-you-performance-benefits
Uno dei motivi principali per NON consentire a Google di ospitare il tuo jQuery, uno a cui molte persone non pensano, è che non verrà scaricato se ti trovi in Cina. È bloccato insieme a molti altri script, caratteri ecc ... ospitati da Google CDN. Se devi raggiungere un pubblico cinese, ti consigliamo di utilizzare sempre un fallback ospitato sul tuo server. Google APIS bloccato in Cina
Alcune buone risposte qui a "Perché dovresti ..." e "Perché non dovresti ..."
Voglio semplicemente aggiungere un elenco di alternative a Google se volessi caricare jQuery da una CDN.
Riassumendo, stai sostanzialmente migliorando le prestazioni complessive del tuo sito Web / applicazione.
Usando la CDN con un addetto all'assistenza, è possibile scaricare la CDN una volta nella vita del client e non ogni volta che si aggiorna il codice.