Negli ultimi anni, sempre più piattaforme per l’ottimizzazione dei progetti front-end offrono opportunità di self-hosting o proxy di risorse di terze parti. Akamai ti consente di impostare per gli URL autogenerati. Cloudflare dispone della tecnologia Edge Workers. Fasterzine può URL sulle pagine in modo che puntino a risorse di terze parti situate nel dominio principale del sito.
Se sai che i servizi di terze parti utilizzati nel tuo progetto non cambiano molto spesso e che il processo di fornitura degli stessi ai clienti potrebbe essere migliorato, probabilmente stai pensando di delegare tali servizi. Con questo approccio, puoi benissimo avvicinare queste risorse ai tuoi utenti e ottenere un controllo più completo sulla loro memorizzazione nella cache sul lato client. Ciò, inoltre, consente di proteggere gli utenti dai problemi causati dal “crash” di un servizio di terze parti o dal degrado delle sue prestazioni.
Buono: prestazioni migliorate
L'hosting autonomo delle risorse di qualcun altro migliora le prestazioni in modo molto evidente. Non è necessario che il browser acceda nuovamente al DNS, non sia necessario stabilire una connessione TCP ed eseguire un handshake TLS su un dominio di terze parti. Puoi vedere in che modo l'hosting autonomo delle risorse di qualcun altro influisce sulle prestazioni confrontando le due figure seguenti.
Le risorse di terze parti vengono scaricate da fonti esterne (prese da )
Le risorse di terze parti sono archiviate nello stesso posto del resto dei materiali del sito (preso da )
La situazione è migliorata anche dal fatto che il browser sfrutterà la capacità di multiplexare e dare priorità ai dati dalla connessione HTTP/2 già stabilita con il dominio principale.
Se non ospiti risorse di terze parti, poiché verranno caricate da un dominio diverso da quello principale, non sarà possibile assegnarle la priorità. Ciò li farà competere tra loro per la larghezza di banda del client. Ciò può comportare tempi di caricamento dei contenuti fondamentali per la creazione di una pagina molto più lunghi di quanto sarebbe ottenibile in circostanze ideali. parla della priorità HTTP/2 che spiega tutto questo molto bene.
Si può presumere che l'uso degli attributi nei collegamenti a risorse esterne preconnect aiuterà a risolvere il problema. Tuttavia, se ci sono troppi collegamenti a domini diversi, la linea di comunicazione può sovraccaricarsi nel momento più cruciale.
Se ospiti tu stesso risorse di terze parti, puoi controllare come esattamente queste risorse vengono fornite al client. Vale a dire, stiamo parlando di quanto segue:
- Puoi assicurarti che venga utilizzato l'algoritmo di compressione dei dati più adatto a ciascun browser (Brotli/gzip).
- È possibile aumentare il tempo di memorizzazione nella cache per risorse che di solito non sono particolarmente lunghe, anche con i provider più conosciuti (ad esempio, il valore corrispondente per il tag GA è impostato su 30 minuti).
Puoi anche estendere il TTL di una risorsa, ad esempio, a un anno incorporando contenuti pertinenti nella tua strategia di gestione della cache (hash URL, controllo delle versioni, ecc.). Ne parleremo di seguito.
▍Protezione contro le interruzioni nel funzionamento dei servizi di terze parti o la loro chiusura
Un altro aspetto interessante del self-hosting delle risorse di terze parti è che consente di mitigare i rischi associati alle interruzioni dei servizi di terze parti. Supponiamo che la soluzione di test A/B di terze parti che stai utilizzando sia implementata come uno script di blocco che viene caricato nella sezione head della pagina. Questo script si carica lentamente. Se lo script corrispondente non viene caricato, la pagina sarà vuota. Se il caricamento richiede molto tempo, la pagina verrà visualizzata con un lungo ritardo. Oppure, supponiamo che il progetto utilizzi una libreria scaricata da una risorsa CDN di terze parti. Immaginiamo che questa risorsa abbia subito un guasto o sia stata bloccata in un determinato paese. Tale situazione porterà a una violazione della logica del sito.
Per scoprire come funziona il tuo sito quando qualche servizio esterno non è disponibile, puoi utilizzare la sezione SPOF su .
Sezione SPOF su webpagetest.org
▍Che dire dei problemi con la memorizzazione nella cache dei materiali nei browser? (suggerimento: è un mito)
Potresti pensare che l’utilizzo di CDN pubblici porterebbe automaticamente a migliori prestazioni delle risorse, poiché questi servizi hanno reti di qualità piuttosto elevata e sono distribuiti in tutto il mondo. Ma in realtà tutto è un po’ più complicato.
Diciamo che abbiamo diversi siti diversi: sito web1.com, sito web2.com, sito web3.com. Tutti questi siti utilizzano la libreria jQuery. Lo colleghiamo a loro utilizzando un CDN, ad esempio: googleapis.com. Puoi aspettarti che il browser scarichi e memorizzi nella cache la libreria una volta, quindi la utilizzi su tutti e tre i siti. Ciò potrebbe ridurre il carico sulla rete. Forse questo ti consentirà di risparmiare denaro da qualche parte e di migliorare le prestazioni delle risorse. Da un punto di vista pratico, tutto sembra diverso. Ad esempio, Safari ha una funzionalità chiamata : la cache utilizza doppie chiavi in base all'origine del documento e all'origine della risorsa di terze parti. buon articolo su questo argomento.
vecchi studi и , nonché più recenti Paul Calvano, mostrano che le risorse non vengono conservate nella cache del browser per tutto il tempo che ci si potrebbe aspettare: “C'è un grave divario tra il tempo di memorizzazione nella cache delle risorse proprie di un progetto e di quelle di terzi. Stiamo parlando di CSS e web font. Vale a dire, il 95% dei caratteri nativi ha una durata della cache superiore a una settimana, mentre il 50% dei caratteri di terze parti ha una durata della cache inferiore a una settimana! Ciò offre agli sviluppatori web un motivo convincente per ospitare essi stessi i file dei font!”
Di conseguenza, se ospiti il contenuto di altre persone, non noterai alcun problema di prestazioni causato dalla memorizzazione nella cache del browser.
Ora che abbiamo illustrato i punti di forza dell'hosting autonomo di terze parti, parliamo di come distinguere una buona implementazione di questo approccio da una cattiva.
Il cattivo: il diavolo è nei dettagli
Lo spostamento di risorse di terze parti nel tuo dominio non può essere eseguito automaticamente senza garantire che tali risorse siano memorizzate correttamente nella cache.
Uno dei problemi principali qui è il tempo di memorizzazione nella cache. Ad esempio, le informazioni sulla versione sono incluse nei nomi di script di terze parti come questi: jquery-3.4.1.js. Tale file non cambierà in futuro e di conseguenza ciò non causerà alcun problema con la sua memorizzazione nella cache.
Ma se non viene utilizzato uno schema di controllo delle versioni quando si lavora con i file, gli script memorizzati nella cache, il cui contenuto cambia mentre il nome del file rimane invariato, potrebbero diventare obsoleti. Questo può rappresentare un problema serio poiché, ad esempio, non consente l'aggiunta automatica di patch di sicurezza agli script che i client devono ricevere il più rapidamente possibile. Lo sviluppatore dovrà impegnarsi ad aggiornare tali script nella cache. Inoltre, ciò può causare errori dell'applicazione dovuti al fatto che il codice utilizzato sul client dalla cache differisce dall'ultima versione del codice per cui è progettata la parte server del progetto.
È vero, se parliamo di materiali che vengono aggiornati frequentemente (tag manager, soluzioni per test A/B), memorizzarli nella cache utilizzando gli strumenti CDN è un compito che può essere risolto, ma è molto più complesso. Servizi come Commanders Act, una soluzione di gestione dei tag, utilizzano webhook quando pubblicano nuove versioni. Ciò ti dà la possibilità di forzare uno svuotamento della cache sulla CDN o, meglio ancora, la possibilità di forzare un aggiornamento dell'hash o dell'URL.
▍Consegna adattiva dei materiali ai clienti
Inoltre, quando parliamo di caching, dobbiamo tenere conto del fatto che le impostazioni di caching utilizzate sulla CDN potrebbero non essere adatte per alcune risorse di terze parti. Ad esempio, tali risorse possono utilizzare la tecnologia di sniffing dello user agent (servizio adattivo) per servire browser specifici con versioni di contenuto ottimizzate specificamente per tali browser. Queste tecnologie si basano su espressioni regolari o su un database di informazioni sull'intestazione HTTP per comprendere le funzionalità del browser. User-Agent. Una volta che sanno con quale browser hanno a che fare, gli forniscono i materiali progettati per quello.
Qui puoi ricordare due servizi. Il primo è googlefonts.com. Il secondo è polyfill.io. Il servizio Google Fonts fornisce, per una determinata risorsa, vari codici CSS, a seconda delle capacità del browser (fornendo collegamenti a risorse woff2 utilizzando unicode-range).
Ecco i risultati di un paio di query di Google Fonts effettuate da diversi browser.
Risultato della query di Google Fonts da Chrome
Risultato della query di Google Fonts eseguita da IE10
Polyfill.io fornisce al browser solo i polyfill di cui ha bisogno. Questo viene fatto per motivi di prestazioni.
Ad esempio, diamo un'occhiata a cosa succede se esegui la seguente richiesta da browser diversi:
In risposta a tale richiesta eseguita da IE10, verranno ricevuti 34 KB di dati. E la risposta, eseguita da Chrome, sarà vuota.
Arrabbiato: alcune considerazioni sulla privacy
Questo punto è l’ultimo in ordine, ma non meno importante. Il punto è che l'autohosting di risorse di terze parti sul dominio principale del progetto o sul suo sottodominio può mettere a repentaglio la privacy degli utenti e influenzare negativamente il progetto web principale.
Se il tuo sistema CDN non è configurato correttamente, potresti finire per inviare i cookie del tuo dominio a un servizio di terze parti. Se non viene organizzato un filtraggio adeguato a livello CDN, i cookie di sessione, che normalmente non possono essere utilizzati in JavaScript (con il httponly), possono essere inviati a un host straniero.
Questo è esattamente ciò che può accadere con tracker come Eulerian o Criteo. I tracker di terze parti potrebbero aver impostato un identificatore univoco nel cookie. Se facessero parte dei materiali del sito, potrebbero leggere l'identificatore a loro discrezione mentre l'utente lavora con diverse risorse web.
Al giorno d'oggi, la maggior parte dei browser include una protezione contro questo tipo di comportamento del tracker. Di conseguenza, i tracker ora utilizzano la tecnologia , mascherati da propri script per vari progetti. Vale a dire, i tracker offrono ai proprietari dei siti di aggiungere un CNAME alle loro impostazioni per un determinato dominio, il cui indirizzo di solito assomiglia a un insieme casuale di caratteri.
Sebbene non sia consigliabile rendere disponibili i cookie del sito web a tutti i sottodomini (ad esempio - *.sitoweb.com), molti siti lo fanno. In questo caso, tali cookie vengono automaticamente inviati a un tracker mascherato di terze parti. Di conseguenza, non possiamo più parlare di privacy.
Inoltre, la stessa cosa accade con le intestazioni HTTP , che vengono inviati solo al dominio principale, poiché possono essere utilizzati per creare utente. Assicurati che il servizio CDN che utilizzi filtri correttamente queste intestazioni.
Risultati di
Se hai intenzione di implementare presto il self-hosting di risorse di terze parti, lascia che ti dia qualche consiglio:
- Ospita le librerie JS, i caratteri e i file CSS più importanti. Ciò ridurrà il rischio di guasto del sito o di degrado delle prestazioni dovuto alla non disponibilità di una risorsa vitale per il sito a causa di un servizio di terze parti.
- Prima di memorizzare nella cache risorse di terze parti su una CDN, assicurati che venga utilizzato un qualche tipo di sistema di controllo delle versioni quando si denominano i file o che sia possibile gestire il ciclo di vita di queste risorse reimpostando manualmente o automaticamente la cache della CDN quando si pubblica una nuova versione di il copione.
- Fai molta attenzione alle impostazioni della CDN, del server proxy e della cache. Ciò ti consentirà di impedire l'invio di cookie al tuo progetto o alle tue intestazioni
Client-Hintsservizi di terzi.
Cari lettori! Ospitate sui vostri server materiali di altre persone che sono estremamente importanti per il funzionamento dei vostri progetti?
Fonte: habr.com