Negli ultimi anni, sempre più piattaforme per l'ottimizzazione di progetti frontend offrono la possibilità di auto-hosting o di proxy di risorse esterne. Akamai consente di impostare per URL creati autonomamente. Cloudflare ha la tecnologia Edge Workers. Fasterzine può URL sulle pagine in modo che puntino a risorse esterne situate sul dominio principale del sito.
Se si sa che i servizi esterni utilizzati nel proprio progetto non cambiano frequentemente e che il processo di consegna agli utenti può essere migliorato, sicuramente si starà pensando di fare proxy a tali servizi. Con questo approccio è possibile 'avvicinare' queste risorse agli utenti e ottenere un controllo maggiore sulla loro memorizzazione nella cache lato client. Inoltre, ciò protegge gli utenti da inconvenienti causati dal 'crollo' di un servizio esterno o dalla degradazione delle sue prestazioni.
Buono: aumento delle prestazioni
L'auto-hosting di risorse esterne migliora le prestazioni in maniera piuttosto ovvia. Il browser non deve effettuare ulteriori richieste DNS, non deve stabilire una connessione TCP e non deve eseguire un handshake TLS su un dominio esterno. L'effetto dell'auto-hosting delle risorse esterne sulle prestazioni può essere osservato confrontando i due seguenti grafici.
Risorse esterne caricate da fonti esterne (presa da )
Risorse esterne memorizzate insieme ai restanti materiali del sito (presa da )
La situazione è ulteriormente migliorata dal fatto che il browser sfrutterà le capacità di multiplexing e prioritizzazione dei dati della connessione HTTP/2, già stabilita con il dominio principale.
Se non si ospitano risorse esterne, esse verranno caricate da un dominio diverso da quello principale, e non potranno essere prioritarie. Ciò comporterà che le risorse competono tra loro per la larghezza di banda del client. Questo potrebbe causare tempi di caricamento per materiali critici per la formazione della pagina molto superiori ai tempi raggiungibili in condizioni ideali. presentazione sulla prioritizzazione HTTP/2, in cui tutto ciò viene spiegato molto bene.
Si può supporre che l'uso degli attributi nei collegamenti a risorse esterne preconnect aiuterà a risolvere il problema. Tuttavia, se ci sono troppi collegamenti a vari domini, questo potrebbe, in effetti, sovraccaricare la linea di comunicazione nel momento critico.
Se si ospitano risorse esterne autonomamente, si può controllare come queste risorse vengono restituite al cliente. In particolare, si tratta di quanto segue:
- È possibile garantire l'applicazione dell'algoritmo di compressione dei dati più adatto per ogni browser (Brotli/gzip).
- Si può aumentare il tempo di caching delle risorse, che di solito, anche presso i provider più noti, non è particolarmente lungo (ad esempio, il valore corrispondente per il tag GA è impostato a 30 minuti).
Si può persino estendere il parametro TTL per una risorsa, ad esempio a un anno, includendo i materiali appropriati nella propria strategia di gestione del caching (hash URL, versioning e così via). Di questo parleremo più avanti.
▍Protezione da interruzioni nei servizi esterni o dalla loro disattivazione
Un altro aspetto interessante dell'autonomo hosting di risorse esterne è che consente di attenuare i rischi legati alle interruzioni nei servizi esterni. Supponiamo che la soluzione esterna che utilizzate per eseguire test A/B sia implementata come uno script bloccante, caricato nella sezione head della pagina. Questo script viene caricato lentamente. Se non riesce a caricare lo script corrispondente, la pagina resterà vuota. Se richiede molto tempo per il caricamento, la pagina apparirà con un grande ritardo. Oppure, supponiamo che nel progetto venga utilizzata una libreria caricata da una risorsa CDN esterna. Immaginiamo che questa risorsa abbia subito un guasto o sia stata bloccata in un certo paese. Una tale situazione porterà a violazioni della logica di funzionamento del sito.
Per scoprire come il vostro sito funziona in caso di indisponibilità di un certo servizio esterno, potete utilizzare la sezione SPOF su .
La sezione SPOF su webpagetest.org
▍Che dire dei problemi di caching dei materiali nei browser? (suggerimento: è un mito)
Si può pensare che l'uso di CDN pubblici porti automaticamente a una migliore performance delle risorse, dal momento che questi servizi dispongono di reti di alta qualità e sono distribuiti in tutto il mondo. Ma in realtà, la situazione è un po' più complessa.
Supponiamo di avere diversi siti web: website1.com, website2.com, website3.com. Su tutti questi siti viene utilizzata la libreria jQuery. La colleghiamo a loro utilizzando un CDN, ad esempio - googleapis.com. Ci si potrebbe aspettare che il browser carichi e memorizzi nella cache la libreria una sola volta e poi la utilizzi per lavorare con tutti e tre i siti. Questo potrebbe ridurre il carico sulla rete. Forse questo consentirebbe di risparmiare da qualche parte e aiuterebbe a migliorare la performance delle risorse. Tuttavia, da un punto di vista pratico, tutto appare diverso. Ad esempio, Safari ha implementato una funzionalità chiamata : nella cache si utilizzano chiavi doppie, basate sulla fonte del documento e sulla fonte della risorsa esterna. ottimo articolo su questo tema.
Ricerche precedenti e , così come più recenti Paola Calvano, mostrano che le risorse non rimangono nella cache del browser così a lungo come potremmo aspettarci: "C'è un gap significativo tra il tempo di caching delle risorse interne e di quelle esterne progetto. Parliamo di CSS e font web. Nello specifico, il tempo di caching del 95% dei font interni supera la settimana, mentre il tempo di caching del 50% dei font esterni è inferiore a una settimana! Questo fornisce ai web developer motivi validi per effettuare l'auto-hosting dei file dei font!".
Di conseguenza, se hosti contenuti di terzi, potresti non notare problemi di performance causati dalla memorizzazione nella cache del browser.
Ora che abbiamo esaminato i punti di forza dell'auto-hosting delle risorse esterne, parliamo di come distinguere una buona implementazione di questo approccio da una cattiva.
Cattiva: il diavolo si nasconde nei dettagli
Spostare risorse esterne sul proprio dominio non può essere fatto automaticamente, senza garantire un corretto caching di tali risorse.
Uno dei principali problemi qui è il tempo di caching. Ad esempio, le informazioni sulle versioni vengono incluse nei nomi degli script esterni più o meno così: jquery-3.4.1.js. Questo file non cambierà in futuro, di conseguenza non causerà alcun problema con la sua memorizzazione nella cache.
Ma se non viene applicato un certo schema di versioning durante il lavoro con i file, gli script memorizzati nella cache, il cui contenuto cambia mantenendo lo stesso nome del file, possono diventare obsoleti. Questo può diventare un problema serio poiché, ad esempio, non consente di applicare automaticamente correzioni di sicurezza agli script, che i clienti devono ricevere il prima possibile. Lo sviluppatore dovrà impegnarsi per aggiornare tali script nella cache. Inoltre, questo può provocare malfunzionamenti dell'applicazione, causati dal fatto che il codice usato dal client nella cache è diverso dalla versione aggiornata del codice su cui si basa la parte server del progetto.
Infatti, quando si parla di materiali che vengono aggiornati frequentemente (gestori di tag, soluzioni per il test A/B), la loro memorizzazione nella cache tramite CDN è un compito, sebbene risolvibile, già molto più complesso. Servizi come Commanders Act, soluzioni per la gestione dei tag, utilizzano webhook per pubblicare nuove versioni. Questo consente di organizzare il ripristino della cache su CDN, o, meglio ancora, la possibilità di chiamare un aggiornamento dell'hash o della versione dell'URL.
▍Visualizzazione adattiva dei materiali ai clienti
Inoltre, quando parliamo di memorizzazione nella cache, è necessario considerare anche il fatto che le impostazioni di caching utilizzate su CDN potrebbero non essere adatte per alcune risorse di terze parti. Ad esempio, tali risorse potrebbero utilizzare la tecnologia di sniffer dell'agente utente (user agent sniffing, adaptive serving) per fornire a specifici browser versioni dei materiali ottimizzate appositamente per quei browser. Queste tecnologie, per determinare le capacità del browser, si affidano a espressioni regolari o a un database contenente informazioni sugli header HTTP. User-Agent. Una volta che sanno con quale browser hanno a che fare, forniscono materiali ottimizzati per quello specifico browser.
Qui si possono menzionare due servizi. Il primo è googlefonts.com. Il secondo è polyfill.io. Il servizio Google Fonts fornisce, per una certa risorsa, diverso codice CSS a seconda delle capacità del browser (fornendo link a risorse woff2, utilizzando unicode-range).
Questi sono i risultati di alcune richieste a Google Fonts effettuate da diversi browser.
Risultato della richiesta a Google Fonts, eseguita da Chrome
Risultato della richiesta a Google Fonts, eseguita da IE10
Polyfill.io fornisce al browser solo i polyfill necessari. Questo è fatto per motivi di prestazioni.
Ad esempio, vediamo cosa succede se eseguiamo la seguente richiesta da diversi browser:
In risposta a tale richiesta, eseguita da IE10, arriveranno 34 KB di dati. La risposta a esa richiesta, eseguita da Chrome, sarà vuota.
Malevolo: alcune considerazioni sulla privacy
Questo punto è l'ultimo in ordine ma non per importanza. Si tratta del fatto che l'hosting indipendente di risorse di terze parti sul dominio principale del progetto o sul suo sottodominio può mettere in pericolo la privacy degli utenti e avere un impatto negativo sul progetto web principale.
Se il tuo sistema CDN è configurato in modo errato, tutto può finire con l'invio dei cookie del tuo dominio a un servizio di terze parti. Se a livello di CDN non viene effettuato un corretto filtraggio, i tuoi cookie di sessione, che normalmente non possono essere utilizzati in JavaScript (con l'attributo httponly), possono essere inviati a un host esterno.
È proprio questo che può accadere con tracciatori come Eulerian o Criteo. I tracciatori di terze parti potrebbero aver impostato un identificatore unico nei cookie. Se facevano parte dei materiali dei siti, potevano leggere l'identificatore a loro discrezione durante l'interazione dell'utente con diverse risorse web.
Oggigiorno, la maggior parte dei browser include una protezione contro tali comportamenti dei tracciatori. Di conseguenza, ora i tracciatori utilizzano la tecnologia , camuffandosi come script propri di vari progetti. In particolare, i tracciatori offrono ai proprietari dei siti di aggiungere nelle loro impostazioni un CNAME per un certo dominio, il cui indirizzo di solito appare come una serie casuale di caratteri.
Anche se non è consigliato rendere i cookie del sito web accessibili a tutti i sottodomini (ad esempio - *.website.com), molti siti lo fanno. In questo caso, i cookie vengono automaticamente inviati a un tracciatore di terze parti camuffato. Come risultato, non si può più parlare di privacy.
Inoltre, lo stesso avviene con le intestazioni HTTP , che vengono inviate solo al dominio principale, poiché possono essere utilizzate per creare dell'utente. Assicurati che il servizio CDN che utilizzi filtri correttamente tali intestazioni.
Conclusioni
Se hai intenzione di implementare a breve un'auto-ospitante per risorse esterne, ti diamo alcuni consigli:
- Ospita localmente le tue più importanti librerie JS, font e file CSS. Ciò ridurrà il rischio di downtime del sito o di una diminuzione delle sue prestazioni a causa dell'indisponibilità di una risorsa vitale per il funzionamento del sito a causa di un servizio esterno.
- Prima di memorizzare nella cache le risorse esterne su un CDN, assicurati che ci sia un sistema di versioning nei nomi dei file o che tu possa gestire il ciclo di vita di queste risorse, svuotando manualmente o automaticamente la cache del CDN al momento della pubblicazione di una nuova versione dello script.
- Fai attenzione alle impostazioni del CDN, del server proxy e della cache. Questo ti aiuterà a evitare di inviare i cookie del tuo progetto o intestazioni
Client-Hintsa servizi esterni.
Gentili lettori! Stai ospitando sui tuoi server materiali di terzi che sono estremamente importanti per il funzionamento dei tuoi progetti?
Fonte: habr.com
