Fornire risorse JS e CSS locali per fallback CDN

Question

Fornire risorse JS e CSS locali per fallback CDN

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

14

Dato che

I CDN sono una buona cosa perché possono servire le risorse più vicine al cliente, il client può memorizzarle nella cache e puoi ridurre il carico sul tuo server.
Nei recenti browser, il caricamento di risorse da server di terze parti non diminuisce la sicurezza grazie a SRI (Subresource Integrity) .
I CDN potrebbero essere bloccati o bloccati in alcuni Paesi e non sono disponibili quando si sviluppa offline ¹.

Penso che sia interessante usare i CDN, ma anche essere pronti a renderli non disponibili. Questo post del blog offre una buona introduzione ai diversi approcci per fornendo fallbacks. Se guardi all'esempio Basic , puoi vedere che contiene già un bel po 'di codice per fornire fallback solo per jQuery e Bootstrap, mentre la soluzione preferita suggerisce di usare Fallback.js , che sembra essere in gran parte non mantenuto per l'anno passato. Allo stesso modo, il più rilevante QUINTA domanda per l'argomento serve solo a fornire un fallback per jQuery.

Tuttavia, nella maggior parte dei progetti del mondo reale, mi aspetterei di avere 5 o più risorse js / css, quindi mi sento come se non dovessi dover ripetere qualche scomodo piano per fornire fallback per tutti loro. Inoltre, ogni volta che aggiungi o aggiorni una risorsa, ora devi

Aggiorna il link CDN
Aggiorna la copia di riserva locale mediante download manuale o modifica della versione in npm / bower config
Aggiorna il link al fallback
Aggiorna l'hash SRI

Mentre nel Ideal World , mi aspetto di aggiungere / aggiornare la risorsa in un unico file di configurazione e di eseguire tutti gli altri passaggi automaticamente (e quindi eseguire test per vedere se l'aggiornamento ha rotto qualcosa ).

Esiste già un flusso di lavoro consolidato per raggiungere questo obiettivo?

O i CDN, e in particolare l'SRI, sono ancora troppo recenti?

O la maggior parte delle persone semplicemente non si cura di fornire fallback per le risorse CDN?

_{1. Anche se potresti avere una build di sviluppo che non si basa su CDN, ma considero anche una forma di fallback, dato che deve anche essere mantenuta.}

javascript css cdn

posta ValarDohaeris 30.03.2016 - 14:15

fonte

3 risposte

Leggi altre domande sui tag javascript css cdn

Perché alcuni siti web mostrano 0 byte negli strumenti di sviluppo di Chrome Qual è l'esempio più semplice là fuori per spiegare la differenza tra Parse Trees e Abstract Syntax Trees?

score 1 · Answer 1

Penso che tu possa fraintendere il modo in cui i siti più grandi che potrebbero richiedere questo tipo di resilienza utilizzano CDN.

non è solo questione di hosting di jQuery o di alcune immagini. La maggior parte del sito sarà ospitata sul CDN, con solo oggetti generati dinamicamente come le pagine di pagamento o i cestini di spesa ospitati sui "webfarm primari"

Anche questi si stanno spostando sempre di più per essere elaborati localmente con JS e i cookie per visualizzare elementi specifici dell'utente senza colpire l'elaborazione lato server.

Se un CDN fallisce e si inizia a ricevere tutto il traffico passato al server web, è probabile che cada, altrimenti non avevi davvero bisogno del CDN.

score 1 · Answer 2

Il sito che lavoro sul nostro CDN è diventato sempre più importante per il sito. All'inizio lo abbiamo semplicemente usato per memorizzare immagini / CSS / JS. In questa fase abbiamo avuto una proprietà di configurazione che ha riscritto il nome host di queste risorse da www.mysite.com/ a www.cdn.com/ quindi se il CDN è andato giù potremmo semplicemente cambiare questo valore host o spegnerlo completamente e lasciare gli URL che puntano al nostro server web.

Tuttavia, ora passiamo alla memorizzazione nella cache di intere pagine con contenuti personalizzati caricati tramite AJAX. Il nostro CDN è diventato essenziale per il nostro sito e potremmo eseguirlo senza di esso come potremmo i nostri server HTTP. Paghiamo in buona parte il nostro CDN in parte a causa della resilienza e delle promesse SLA di uptime, quindi il tempo e gli sforzi per le fallback sembrano una perdita di tempo. Abbiamo un piano di DR in vigore solo in caso di problemi importanti con il nostro provider, ma non si tratta di un semplice processo automatizzato e vedremmo un periodo di interruzione durante la migrazione al nostro CDN di fallback.

Quindi in risposta alla tua domanda dipende da quanto è integrale il tuo sito nel CDN. Se sono solo le tue risorse che stai inserendo nella CDN e supponendo che i tuoi server http possano gestire il carico di distribuzione di questi contenuti, puoi utilizzare un parametro di configurazione per attivare o disattivare essenzialmente la rete CDN. Accoppiato con uno strumento di monitoraggio è possibile automatizzare l'attivazione o la disattivazione di tale interruttore.

score 0 · Answer 3

Vedo 3 motivi molto importanti per l'utilizzo di CDN:

Riduce la latenza di rete per gli utenti in regioni distanti. Quando hai un sito Web per il pubblico globale, il tuo hosting in Nord America non sembra veloce per gli utenti dell'Asia meridionale, specialmente in Cina. La differenza nell'esperienza utente può essere così grande da scoraggiare gli utenti dall'usare il tuo sito. In questo caso la CDN multiregionale sarà essenziale per la tua attività.
Servire il più possibile da risorse altamente disponibili. L'affidabilità è uno dei motivi principali dell'utilizzo dei CDN del cloud: il traffico viene automaticamente reindirizzato ai nodi disponibili ed è possibile aggiungere ulteriori misure per reindirizzare il traffico se l'intera area del cloud è inattiva.
La CDN è più facile da mantenere e più economica dei server di applicazioni che offrono contenuti dinamici. Quando devi affrontare i problemi sopra menzionati, è un modo naturale per risparmiare denaro.

Tutto ciò significa che l'obiettivo di CDN è aumentare la disponibilità dei tuoi contenuti per gli utenti finali. Se CDN fallisce o diventa lento per qualche motivo, il fallback sul lato client aumenterà in modo significativo il carico della pagina, poiché tenterà prima di ottenere la risorsa che non è accessibile. La soluzione migliore è avere la progettazione lato server che eseguirà una sostituzione dell'URL di base in collegamenti come "{CDN} /js/jquery-version-min.js". Ciò consentirà di reindirizzare il traffico al server delle applicazioni anziché CDN se la verifica dello stato di salute del CDN non riesce: i client non eseguiranno richieste non necessarie e andranno direttamente al server delle app, che sarebbe la soluzione alternativa con la soluzione lato client. Ciò risolverà anche il problema delle distribuzioni locali e di gestione temporanea, poiché è possibile implementare la logica di sostituzione per determinare la posizione delle risorse statiche in base all'ambiente e alla configurazione.