Negli ultimi anni, sempre più piattaforme per l'ottimizzazione dei progetti frontend offrono funzionalità di self-hosting o di proxying per risorse di terze parti. Akamai permette di definire per URL creati autonomamente. Cloudflare dispone della tecnologia Edge Workers. Fasterzine può URL sulle pagine in modo che puntino a risorse di terze parti situate sul dominio principale del sito.
Se è noto che i servizi di terze parti utilizzati nel vostro progetto non cambiano troppo spesso e che il processo di consegna ai clienti può essere migliorato, è probabile che stiate considerando il proxying di tali servizi. Con questo approccio, potete avvicinare queste risorse agli utenti e ottenere un controllo più completo sulla loro memorizzazione nella cache lato client. Inoltre, questo aiuta a proteggere gli utenti da problemi causati dal 'down' di un servizio esterno o dalla degradazione delle sue prestazioni.
Buono: aumento delle prestazioni
L'hosting autonomo di risorse esterne migliora le prestazioni in modo tutto sommato evidente. Il browser non deve effettuare ulteriori richieste DNS, non è necessario stabilire una connessione TCP e non è richiesta la handshake TLS su un dominio esterno. L'impatto dell'hosting autonomo delle risorse esterne sulle prestazioni è visibile confrontando le due immagini seguenti.
Le risorse esterne vengono caricate da fonti esterne (prelevate )
Le risorse esterne sono memorizzate insieme ad altri materiali del sito (prelevate )
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, poiché verranno caricate da un dominio diverso da quello principale, non sarà possibile priorizzarle. Ciò porterà a una competizione tra di esse per la larghezza di banda del cliente. Questo può comportare che il tempo di caricamento dei materiali critici per la creazione della pagina sia significativamente più lungo rispetto al tempo raggiungibile in circostanze ideali. una presentazione sulla prioritizzazione di HTTP/2, in cui tutto ciò viene spiegato molto bene.
Si può supporre che l'uso degli attributi nei link a risorse esterne preconnect aiuti a risolvere il problema. Tuttavia, se ci sono troppi link a diversi domini, questo potrebbe effettivamente sovraccaricare la connessione nel momento più critico.
Se si ospitano risorse esterne in modo autonomo, è possibile controllare come queste vengono fornite al cliente. In particolare, si tratta di quanto segue:
- Si può garantire l'applicazione di un algoritmo di compressione dei dati più adatto per ciascun browser (Brotli/gzip).
- È possibile aumentare il tempo di caching delle risorse, che solitamente, anche dai provider più noti, non è particolarmente elevato (ad esempio, il valore corrispondente per il tag GA è impostato a 30 minuti).
Si può persino estendere l'indicatore TTL per una risorsa, ad esempio fino a un anno, includendo i materiali corrispondenti nella propria strategia di gestione del caching (hash degli URL, versioning e così via). Ne parleremo più avanti.
▍Protezione contro le interruzioni dei servizi di terze parti o la loro disattivazione
Un altro aspetto interessante dell'autosufficienza nell'hosting di risorse di terzi è che consente di ridurre i rischi associati ai downtime dei servizi esterni. Supponiamo che la soluzione di terze parti utilizzata per condurre i test A/B sia implementata come uno script bloccante caricato nell'intestazione della pagina. Questo script può essere lento da caricare. Se lo script non viene caricato correttamente, la pagina sarà vuota. Se ci vorrà molto tempo per caricarlo, 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 determinato paese. Questa situazione porterà a una violazione della logica di funzionamento del sito.
Per sapere come funziona il tuo sito in caso di indisponibilità di un servizio esterno, puoi utilizzare la sezione SPOF su .
La sezione SPOF su webpagetest.org
▍Che dire dei problemi di caching dei materiali nei browser? (suggerimento: è un mito)
Potrebbe sembrare che utilizzare CDN pubblici migliori automaticamente le prestazioni delle risorse, dato che questi servizi dispongono di reti di alta qualità e sono distribuiti in tutto il mondo. Ma in realtà, la questione è un po' più complessa.
Supponiamo di avere diversi siti web: website1.com, website2.com, website3.com. Su tutti questi siti utilizziamo la libreria jQuery. La colleghiamo tramite un CDN, ad esempio — googleapis.com. Ci si aspetterebbe che il browser carichi e memorizzi in cache la libreria una sola volta, per poi utilizzarla su tutti e tre i siti. Questo potrebbe ridurre il carico sulla rete. Forse permetterebbe anche un risparmio e aiuterebbe a migliorare le prestazioni delle risorse. Tuttavia, dalla prospettiva pratica, la situazione è diversa. Ad esempio, in Safari è stata implementata una funzionalità chiamata : nella cache vengono utilizzate doppie chiavi, basate sulla fonte del documento e sulla fonte della risorsa esterna. ottimo articolo su questo tema.
Studi precedenti e , così come più recenti. Paola Calvano dimostra che le risorse non vengono memorizzate nella cache del browser così a lungo come potremmo aspettarci: «C'è un significativo divario tra i tempi di caching delle risorse interne ed esterne del progetto. Si tratta di CSS e font web. In particolare, il periodo di caching del 95% dei font interni supera una settimana, mentre il periodo di caching del 50% dei font esterni è inferiore a una settimana! Questo offre ai web developer valide ragioni per ospitare i file dei font in modo autonomo!»
Di conseguenza, se ospiti materiali di terze parti, non noterai problemi di prestazioni causati dalla memorizzazione nella cache del browser.
Ora che abbiamo esaminato i punti di forza dell'hosting autonomo delle risorse esterne, parliamo di come distinguere una buona implementazione di questo approccio da una cattiva.
Cattivo: il diavolo si nasconde nei dettagli
Spostare le risorse esterne sul proprio dominio non può essere fatto automaticamente senza occuparsi della corretta memorizzazione nella cache di tali risorse.
Uno dei principali problemi qui è il tempo di caching. Ad esempio, le informazioni sulle versioni vengono incluse nei nomi degli script di terze parti in questo modo: jquery-3.4.1.js. Un file di questo tipo non cambierà in futuro, quindi non causerà alcun problema con il suo caching.
Ma se non viene applicato un qualche schema di versioning per la gestione dei file, gli script cached, il cui contenuto cambia con lo stesso nome del file, possono diventare obsoleti. Questo può diventare un problema serio, poiché ad esempio non consente di introdurre automaticamente le correzioni di sicurezza negli script che i clienti devono ricevere il prima possibile. Lo sviluppatore dovrà fare uno sforzo per aggiornare tali script nella cache. Inoltre, questo può causare malfunzionamenti nell'applicazione, poiché il codice utilizzato dal client dalla cache differisce dalla nuova versione del codice per cui è progettata la parte server del progetto.
È vero che, parlando di materiali che vengono aggiornati frequentemente (gestori di tag, soluzioni per test A/B), la loro memorizzazione nella cache tramite un CDN è un compito che, sebbene affrontabile, diventa notevolmente più complesso. Servizi come Commanders Act, soluzioni per la gestione dei tag, utilizzano webhook al momento della pubblicazione di nuove versioni. Questo consente di organizzare il ripristino della cache sul CDN o, meglio ancora, di attivare l'aggiornamento dell'hash o della versione dell'URL.
▍Distribuzione adattativa dei materiali ai clienti
Inoltre, quando parliamo di caching, è necessario tenere conto del fatto che le impostazioni di caching utilizzate sul CDN potrebbero non essere adatte per alcune risorse esterne. Ad esempio, tali risorse potrebbero utilizzare la tecnologia di sniffing dell'agente utente (user agent sniffing, adaptive serving) per fornire versioni dei materiali ottimizzate per specifici browser. Queste tecnologie si basano su espressioni regolari o su un database contenente informazioni sugli header HTTP per determinare le capacità del browser. User-Agent. Scoprendo quali browser stanno utilizzando, forniscono materiali specifici per ciascuno di essi.
Qui possiamo citare due servizi. Il primo è googlefonts.com. Il secondo è polyfill.io. Il servizio Google Fonts fornisce, per una certa risorsa, diverse righe di codice CSS in base alle capacità del browser (includendo link a risorse woff2) unicode-range).
Ecco i risultati di alcune richieste a Google Fonts effettuate da diversi browser.
Risultato della richiesta a Google Fonts effettuata da Chrome
Risultato della richiesta a Google Fonts effettuata da IE10
Polyfill.io restituisce al browser solo i polyfill di cui ha bisogno. Questo è fatto per motivi di prestazioni.
Ad esempio, vediamo cosa succede se effettuamo la seguente richiesta da diversi browser:
In risposta a tale richiesta, effettuata da IE10, verranno restituiti 34 KB di dati. Mentre la risposta effettuata da Chrome sarà vuota.
Critico: alcune considerazioni sulla privacy
Questo punto è l'ultimo per ordine, ma non per importanza. Si tratta del fatto che l'hosting indipendente di risorse di terzi sul dominio principale del progetto o sui suoi sottodomini può compromettere la privacy degli utenti e avere un impatto negativo sul progetto web principale.
Se il vostro sistema CDN non è configurato correttamente, tutto può finire con l'invio dei cookie del vostro dominio a un servizio esterno. Se a livello di CDN non è prevista una filtrazione adeguata, i vostri cookie di sessione, che normalmente non possono essere utilizzati in JavaScript (con l'attributo httponly), possono essere inviati a un host esterno.
Questo potrebbe verificarsi con tracker come Eulerian o Criteo. I tracker di terze parti potrebbero impostare un identificatore unico nei cookie. Se facevano parte dei materiali dei siti, potevano leggere l'identificatore a loro piacimento mentre l'utente interagiva con diverse risorse web.
Ogni giorno, la maggior parte dei browser include protezioni contro questo comportamento dei tracker. Di conseguenza, ora i tracker utilizzano la tecnologia , mascherandosi come script propri di vari progetti. In particolare, i tracker invitano i proprietari dei siti a aggiungere nelle loro impostazioni un CNAME per un certo dominio, il cui indirizzo di solito appare come un insieme casuale di caratteri.
Sebbene non sia consigliabile rendere i cookie del sito web accessibili a tutti i sottodomini (ad esempio — *.website.com), ciò avviene su molti siti. In tal caso, questi cookie vengono inviati automaticamente al tracker di terze parti mascherato. Di conseguenza, non si può più parlare di privacy.
Inoltre, lo stesso accade con le intestazioni HTTP , che vengono inviati solo al dominio principale, poiché possono essere utilizzati per creare dell'utente. Assicurati che il servizio CDN che utilizzi filtri correttamente tali intestazioni.
Risultati
Se prevedi di implementare a breve un hosting autonomo di risorse di terze parti, permettimi di darti qualche consiglio:
- Ospita le tue librerie JS, font e file CSS più importanti sui tuoi server. Questo ridurrà il rischio di inattività del sito o di prestazioni ridotte a causa dell'indisponibilità di risorse essenziali per il funzionamento del sito a causa di un servizio di terze parti.
- Prima di memorizzare in cache le risorse di terze parti su un CDN, assicurati di utilizzare un sistema di versioning per la denominazione dei file, o che tu possa gestire il ciclo di vita di queste risorse, svuotando manualmente o automaticamente la cache del CDN quando pubblichi 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 le intestazioni
Client-Hintsa servizi di terze parti.
Gentili lettori! Carichi sul tuo server materiali di terzi che sono estremamente importanti per il funzionamento dei tuoi progetti?
Fonte: habr.com
