Reti CDN (Content Delivery Network)

Migliora il rendimento utilizzando una rete CDN (Content Delivery Network).

Le reti CDN (Content Delivery Network) migliorano le prestazioni del sito utilizzando una rete distribuita di server per fornire risorse agli utenti. Poiché le reti CDN riducono il carico del server, riducono i costi del server e sono adatte a gestire picchi di traffico. Questo articolo illustra il funzionamento delle reti CDN e fornisce indicazioni indipendenti dalla piattaforma per scegliere, configurare e ottimizzare una configurazione CDN.

Panoramica

Una rete CDN (Content Delivery Network) è formata da una rete di server ottimizzati per la distribuzione rapida di contenuti agli utenti. Sebbene le reti CDN siano probabilmente più note per la pubblicazione di contenuti memorizzati nella cache, possono anche migliorare la distribuzione di contenuti non memorizzabili nella cache. In linea di massima, maggiore è la quantità di un sito pubblicato dalla rete CDN, migliori saranno i risultati.

A livello generale, i vantaggi in termini di prestazioni delle reti CDN derivano da alcuni principi: i server CDN si trovano più vicini agli utenti rispetto ai server di origine e, di conseguenza, hanno una latenza più breve del tempo di round trip (RTT); le ottimizzazioni di rete consentono alle CDN di fornire contenuti più rapidamente rispetto a se i contenuti vengano caricati "direttamente" dal server di origine; infine, le cache CDN eliminano la necessità di una richiesta di viaggiare al server di origine.

Distribuzione delle risorse

Sebbene possa sembrare non intuitivo, l'utilizzo di una CDN per distribuire le risorse (anche quelle non memorizzabili nella cache) sarà in genere più rapido rispetto al caricamento della risorsa "direttamente" dai tuoi server.

Quando viene utilizzata una CDN per distribuire risorse dall'origine, viene stabilita una nuova connessione tra il client e un server CDN nelle vicinanze. Il resto del percorso (in altre parole, il trasferimento di dati tra il server CDN e l'origine) avviene sulla rete CDN, che spesso include connessioni permanenti esistenti con l'origine. I vantaggi di ciò sono duplice: l'interruzione della nuova connessione il più vicino possibile all'utente elimina i costi superflui di configurazione della connessione (stabilire una nuova connessione è costosa e richiede diversi round trip); utilizzare una connessione preriscaldata consente di trasferire immediatamente i dati alla velocità effettiva massima possibile.

Alcune reti CDN migliorano ulteriormente questo aspetto instradando il traffico all'origine attraverso più server CDN distribuiti su internet. Le connessioni tra i server CDN avvengono su route affidabili e altamente ottimizzate, piuttosto che su route determinate dal Border Gateway Protocol (BGP). Sebbene BGP sia il protocollo di routing di fatto di internet, le sue decisioni di routing non sono sempre orientate alle prestazioni. Di conseguenza, è probabile che le route determinate da BGP siano meno performanti di quelle ottimizzate tra i server CDN.

Memorizzazione nella cache

La memorizzazione delle risorse nella cache sui server di una rete CDN elimina la necessità di una richiesta che si reca fino all'origine per essere fornita. Di conseguenza, la risorsa viene erogata più rapidamente e questo riduce anche il carico sul server di origine.

Aggiunta di risorse alla cache

Il metodo più usato per compilare le cache CDN consiste nell'offrire le risorse CDN "pull" in base alle loro esigenze, un processo noto come "origin pull". La prima volta che una determinata risorsa viene richiesta dalla cache, la CDN la richiederà al server di origine e memorizzerà la risposta nella cache. In questo modo, i contenuti della cache vengono creati nel tempo man mano che vengono richieste ulteriori risorse non memorizzate nella cache.

Rimozione delle risorse dalla cache

Le CDN utilizzano l'eliminazione dalla cache per rimuovere periodicamente le risorse non utili. Inoltre, i proprietari dei siti possono utilizzare l'eliminazione definitiva per rimuovere esplicitamente le risorse.

• Eliminazione della cache

  Le cache hanno una capacità di archiviazione limitata. Quando una cache ha quasi raggiunto la sua capacità, libera spazio per nuove risorse rimuovendo quelle che non sono state usate di recente o che occupano una quantità elevata di spazio. Questa procedura è nota come rimozione della cache. Se una risorsa viene rimossa da una cache, non significa necessariamente che è stata rimossa da tutte le cache di una rete CDN.

• Pulizia

  L'eliminazione definitiva (noto anche come"annullamento della convalida della cache") è un meccanismo per rimuovere una risorsa dalle cache di una rete CDN senza dover aspettare che scada o venga rimossa. In genere viene eseguito tramite un'API. L'eliminazione definitiva è fondamentale nelle situazioni in cui è necessario ritirare i contenuti (ad esempio, correggere errori di battitura, errori di prezzo o articoli di notizie errati). Inoltre, può anche svolgere un ruolo fondamentale nella strategia di memorizzazione nella cache di un sito.

  Se una CDN supporta l'eliminazione definitiva quasi immediata, l'eliminazione definitiva può essere utilizzata come meccanismo per gestire la memorizzazione nella cache dei contenuti dinamici: memorizza nella cache i contenuti dinamici utilizzando un TTL lungo, quindi elimina definitivamente la risorsa ogni volta che viene aggiornata. In questo modo è possibile massimizzare la durata della memorizzazione nella cache di una risorsa dinamica, pur non sapere in anticipo quando la risorsa cambierà. Questa tecnica è a volte definita "memorizzazione nella cache in attesa".

  Quando si usa l'eliminazione definitiva su larga scala, di solito viene usata in combinazione con un concetto noto come "tag cache" o "chiavi cache surrogate". Questo meccanismo consente ai proprietari di siti di associare uno o più identificatori aggiuntivi (a volte indicati come "tag") a una risorsa memorizzata nella cache. Questi tag possono quindi essere utilizzati per eliminare i dati altamente granulari. Ad esempio, potresti aggiungere un tag "footer" a tutte le risorse (ad es. /about, /blog) che contengono il piè di pagina del tuo sito. Quando il piè di pagina viene aggiornato, indica alla rete CDN di eliminare definitivamente tutte le risorse associate al tag "footer".

Risorse memorizzabili nella cache

Il fatto e come una risorsa deve essere memorizzata nella cache dipende dal fatto che sia pubblica o privata, statica o dinamica.

Risorse pubbliche e private

• Risorse private

  Le risorse private contengono dati destinati a un singolo utente, pertanto non devono essere memorizzate nella cache da una rete CDN. Le risorse private sono indicate dall'intestazione Cache-Control: private.

• Risorse pubbliche

  Le risorse pubbliche non contengono informazioni specifiche sull'utente e, di conseguenza, possono essere memorizzate nella cache da una rete CDN. Una risorsa può essere considerata memorizzabile nella cache da una rete CDN se non ha un'intestazione Cache-Control: no-store o Cache-Control: private. Il periodo di tempo in cui una risorsa pubblica può essere memorizzata nella cache dipende dalla frequenza di modifica dell'asset.

Contenuti dinamici e statici

• Contenuti dinamici

  I contenuti dinamici sono contenuti che cambiano spesso. Una risposta API e una home page del negozio sono esempi di questo tipo di contenuti. Tuttavia, il fatto che questi contenuti cambino di frequente non ne impedisce la memorizzazione nella cache. Durante periodi di traffico intenso, memorizzare nella cache queste risposte per periodi molto brevi (ad esempio, 5 secondi) può ridurre notevolmente il carico sul server di origine, con un impatto minimo sull'aggiornamento dei dati.

• Contenuti statici

  I contenuti statici cambiano raramente o mai. Immagini, video e librerie con controllo delle versioni sono generalmente esempi di questo tipo di contenuti. Poiché i contenuti statici non cambiano, devono essere memorizzati nella cache con una durata (TTL) lunga, ad esempio 6 mesi o 1 anno.

Scelta di una rete CDN

Il rendimento è in genere uno degli aspetti più importanti per la scelta di una CDN. Tuttavia, le altre funzionalità offerte da una CDN (ad esempio funzionalità di sicurezza e analisi), nonché i prezzi, l'assistenza e l'onboarding di una CDN, sono tutte importanti da considerare nella scelta di una CDN.

Esibizione

A livello generale, la strategia di performance di una CDN può essere considerata come il compromesso tra la riduzione della latenza e la massimizzazione del rapporto di successo della cache. Le CDN con molti punti di presenza (PoP) possono offrire una latenza inferiore, ma potrebbero riscontrare rapporti di successo della cache inferiori a causa della suddivisione del traffico tra più cache. Al contrario, le CDN con meno PoP potrebbero trovarsi geograficamente più lontano dagli utenti, ma possono raggiungere rapporti di successo della cache più elevati.

Come risultato di questo compromesso, alcune CDN utilizzano un approccio a più livelli per la memorizzazione nella cache: i PoP situati vicino agli utenti (noti anche come "cache perimetrali") vengono integrati con PoP centrali che hanno rapporti di successo della cache più elevati. Quando una cache perimetrale non riesce a trovare una risorsa, cerca un punto di presenza (POP) centrale per la risorsa. Questo approccio scambia una latenza leggermente maggiore per una maggiore probabilità che la risorsa possa essere fornita da una cache CDN, anche se non necessariamente da una cache perimetrale.

Il compromesso tra la riduzione della latenza e la massimizzazione del rapporto di successo della cache è uno spettro. Nessun approccio particolare è universalmente migliore; tuttavia, a seconda della natura del sito e della base di utenti, potresti scoprire che uno di questi approcci offre un rendimento notevolmente migliore rispetto all'altro.

Vale anche la pena notare che il rendimento della CDN può variare notevolmente a seconda dell'area geografica, dell'ora del giorno e anche degli eventi di attualità. Sebbene sia sempre opportuno effettuare ricerche sulle prestazioni di una rete CDN, può essere difficile prevedere le prestazioni esatte che si ottengono da una rete CDN.

Effetti su Largest Contentful Paint (LCP)

Come descritto in precedenza in questo articolo, lo scopo principale di una rete CDN è ridurre la latenza distribuendo le risorse ai server geograficamente più vicini agli utenti. Per questo motivo, il vantaggio principale di una CDN è che migliora le prestazioni di caricamento. In particolare, il tempo per il primo byte (TTFB) di una risorsa può essere notevolmente migliorato quando si introduce una rete CDN nell'architettura lato server del sito.

Sebbene TTFB non sia una metrica delle prestazioni incentrata sull'utente, è una metrica importante per diagnosticare i problemi con la Largest Contentful Paint (LCP), una metrica incentrata sull'utente.

Le CDN sono particolarmente efficaci nel migliorare l'LCP, in quanto possono migliorare sia la consegna dei documenti (riducendo il TTFB nella configurazione della connessione e nella memorizzazione nella cache del documento) sia nel migliorare la distribuzione di qualsiasi risorsa statica necessaria per eseguire il rendering dell'elemento LCP.

Altre funzionalità

Le CDN in genere offrono un'ampia gamma di funzionalità oltre alla loro offerta CDN principale. Le funzionalità più comuni includono bilanciamento del carico, ottimizzazione delle immagini, streaming video, edge computing e prodotti di sicurezza.

Come impostare e configurare una CDN

Idealmente, dovresti usare una rete CDN per gestire l'intero sito. A livello generale, il processo di configurazione prevede la registrazione presso un provider CDN e l'aggiornamento del record DNS CNAME in modo che punti al provider CDN. Ad esempio, il record CNAME per www.example.com potrebbe puntare a example.my-cdn.com. In seguito a questa modifica al DNS, il traffico al tuo sito verrà instradato attraverso la rete CDN.

Se non è possibile utilizzare una rete CDN per gestire tutte le risorse, puoi configurarla per gestire solo un sottoinsieme di risorse, ad esempio solo risorse statiche. Puoi farlo creando un record CNAME separato che verrà utilizzato solo per le risorse che dovrebbero essere gestite dalla rete CDN. Ad esempio, potresti creare un record CNAME static.example.com che punta a example.my-cdn.com. Devi anche riscrivere gli URL delle risorse gestite dalla rete CDN in modo che rimandino al sottodominio static.example.com che hai creato.

Anche se la rete CDN sarà configurata in questa fase, è probabile che la configurazione presenti delle inefficienze. Le due sezioni successive di questo articolo spiegano come ottenere il massimo dalla rete CDN aumentando il tasso di successo della cache e abilitando le funzionalità per le prestazioni.

Miglioramento del rapporto di successo della cache

Una configurazione CDN efficace pubblicherà il maggior numero possibile di risorse dalla cache. In genere, questo valore viene misurato in base al tasso di successo della cache (CHR). Il rapporto di hit della cache è definito come il numero di hit della cache diviso per il numero di richieste totali in un determinato intervallo di tempo.

Una cache appena inizializzata avrà un CHR pari a 0, ma questo aumenta man mano che la cache viene compilata con le risorse. Un CHR del 90% è un buon obiettivo per la maggior parte dei siti. Il tuo fornitore CDN dovrebbe fornirti dati e analisi relativi al tuo CHR.

Quando si ottimizza il CHR, la prima cosa da verificare è che tutte le risorse memorizzabili nella cache siano memorizzate nella cache e memorizzate nella cache per il periodo di tempo corretto. Si tratta di una semplice valutazione che deve essere eseguita da tutti i siti.

Il livello successivo di ottimizzazione del CHR, in linea di massima, consiste nel perfezionare le impostazioni CDN per assicurarti che le risposte del server logicamente equivalenti non vengano memorizzate nella cache separatamente. Si tratta di un'inefficienza comune dovuta all'impatto di fattori come parametri di query, cookie e intestazioni delle richieste sulla memorizzazione nella cache.

Controllo iniziale

La maggior parte delle CDN fornirà l'analisi della cache. Inoltre, strumenti come WebPageTest e Lighthouse possono essere utilizzati per verificare rapidamente che tutte le risorse statiche di una pagina vengano memorizzate nella cache per il periodo di tempo corretto. A questo scopo, controlla le intestazioni Cache HTTP di ogni risorsa. La memorizzazione di una risorsa nella cache utilizzando il valore TTL (Time To Live) massimo appropriato consente di evitare recuperi dell'origine non necessari in futuro e, di conseguenza, di aumentare il CHR.

Affinché una risorsa venga memorizzata nella cache da una rete CDN, generalmente è necessario impostare almeno una di queste intestazioni:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Inoltre, anche se non influisce sulla memorizzazione o sulle modalità di memorizzazione nella cache di una risorsa da una CDN, è buona norma impostare anche l'istruzione Cache-Control: immutable.Cache-Control: immutable indica che una risorsa "non verrà aggiornata durante il periodo di aggiornamento". Di conseguenza, il browser non riconvaliderà la risorsa quando la fornisce dalla cache del browser, eliminando così una richiesta del server non necessaria. Purtroppo questa istruzione è supportata solo da Firefox e Safari e non è supportata dai browser basati su Chromium. Questo problema monitora l'assistenza di Chromium per Cache-Control: immutable. Aggiungere questo problema a Speciali può contribuire a incoraggiare il supporto di questa funzionalità.

Per una spiegazione più dettagliata della memorizzazione nella cache HTTP, consulta l'articolo Prevenire richieste di rete non necessarie con la cache HTTP.

Messa a punto

Una spiegazione leggermente semplificata del funzionamento delle cache CDN è che l'URL di una risorsa viene utilizzato come chiave per la memorizzazione nella cache e il recupero della risorsa dalla cache. In pratica, ciò è ancora prevalentemente vero, ma è leggermente complicato dall'impatto di elementi come le intestazioni delle richieste e i parametri di query. Di conseguenza, la riscrittura degli URL delle richieste è una tecnica importante sia per massimizzare il valore CHR sia per garantire che agli utenti vengano mostrati i contenuti corretti. Un'istanza CDN configurata correttamente raggiunge il giusto equilibrio tra una memorizzazione nella cache troppo granulare (che danneggia la CHR) e una memorizzazione nella cache sufficientemente granulare (che comporta la pubblicazione di risposte errate agli utenti).

Parametri di query

Per impostazione predefinita, le CDN prendono in considerazione i parametri di query quando memorizzano nella cache una risorsa. Tuttavia, piccoli aggiustamenti alla gestione dei parametri di query possono avere un impatto significativo sulla CHR. Ad esempio:

• Parametri di query non necessari

  Per impostazione predefinita, una rete CDN memorizza nella cache example.com/blog e example.com/blog?referral_id=2zjk separatamente, anche se probabilmente sono la stessa risorsa sottostante. Il problema viene risolto modificando la configurazione di una CDN in modo da ignorare il parametro di query referral\_id.

• Ordine parametri di query

  Una rete CDN memorizzerà nella cache example.com/blog?id=123&query=dogs separatamente da example.com/blog?query=dogs&id=123. Per la maggior parte dei siti, l'ordine dei parametri di query non è importante, quindi la configurazione della rete CDN per ordinare i parametri di query (normalizzando quindi l'URL utilizzato per memorizzare nella cache la risposta del server) aumenterà il CHR.

Varia

L'intestazione della risposta Vary indica alle cache che la risposta del server corrispondente a un particolare URL può variare a seconda delle intestazioni impostate nella richiesta (ad esempio, le intestazioni della richiesta Accept-Language o Accetta-Encoding). Di conseguenza, comunica a una CDN di memorizzare le risposte separatamente nella cache. L'intestazione Vary non è ampiamente supportata dalle reti CDN e potrebbe causare la mancata pubblicazione di una risorsa memorizzabile nella cache.

Sebbene l'intestazione Vary possa essere uno strumento utile, un utilizzo inappropriato danneggia il CHR. Inoltre, se usi Vary, la normalizzazione delle intestazioni delle richieste contribuirà a migliorare la CHR. Ad esempio, senza normalizzazione le intestazioni della richiesta Accept-Language: en-US e Accept-Language: en-US,en;q=0.9 comporterebbero due voci di cache separate, anche se i loro contenuti sarebbero probabilmente identici.

Biscotti

I cookie vengono impostati per le richieste tramite l'intestazione Cookie e per le risposte tramite l'intestazione Set-Cookie. Evita un uso non necessario dell'intestazione Set-Cookie, dato che in genere le cache non memorizzano nella cache le risposte del server contenenti questa intestazione.

Funzionalità per le prestazioni

Questa sezione illustra le funzionalità per il rendimento comunemente offerte dalle reti CDN come parte dell'offerta di prodotto principale. Molti siti dimenticano di abilitare queste funzioni, perdendo così potenziali opportunità di rendimento.

Compressione

Tutte le risposte basate su testo devono essere compresse con gzip o Brotli. Se puoi scegliere, scegli Brotli anziché gzip. Brotli è un algoritmo di compressione più recente e, rispetto a gzip, può raggiungere rapporti di compressione più elevati.

Esistono due tipi di supporto CDN per la compressione Brotli: "Brotli dall'origine" e "compressione Brotli automatica".

Brotli dall'origine

Brotli dall'origine si verifica quando una CDN gestisce le risorse che sono state compresse da Brotli dall'origine. Sebbene questa possa sembrare una funzionalità che tutte le reti CDN dovrebbero essere in grado di supportare immediatamente, richiede che una CDN sia in grado di memorizzare nella cache più versioni (in altre parole, le versioni gzip-compresse e Brotli-compresse) della risorsa corrispondente a un dato URL.

Compressione Brotli automatica

La compressione automatica Brotli si verifica quando le risorse sono compresse da Brotli dalla rete CDN. Le reti CDN possono comprimere le risorse sia memorizzabili che non memorizzabili nella cache.

La prima volta che una risorsa viene richiesta, viene fornita utilizzando una compressione "sufficientemente buona", ad esempio Brotli-5. Questo tipo di compressione è applicabile alle risorse memorizzabili e non memorizzabili nella cache.

Nel frattempo, se una risorsa può essere memorizzata nella cache, la rete CDN utilizzerà l'elaborazione offline per comprimerla a un livello di compressione più potente, ma molto più lento, ad esempio Brotli-11. Una volta completata la compressione, la versione più compressa verrà memorizzata nella cache e utilizzata per le richieste successive.

Best practice per la compressione

I siti che vogliono massimizzare le prestazioni devono applicare la compressione Brotli sia al server di origine sia alla rete CDN. La compressione Brotli all'origine riduce al minimo la dimensione di trasferimento delle risorse che non possono essere fornite dalla cache. Per evitare ritardi nella pubblicazione delle richieste, l'origine deve comprimere le risorse dinamiche utilizzando un livello di compressione abbastanza prudente, ad esempio Brotli-4. Le risorse statiche possono essere compresse utilizzando Brotli-11. Se un'origine non supporta Brotli, è possibile usare gzip-6 per comprimere le risorse dinamiche; gzip-9 può essere usato per comprimere le risorse statiche.

TLS 1.3

TLS 1.3 è la versione più recente di Transport Layer Security (TLS), il protocollo crittografico utilizzato da HTTPS. TLS 1.3 offre privacy e prestazioni migliori rispetto a TLS 1.2.

TLS 1.3 abbrevia l'handshake TLS da due round trip a uno. Per le connessioni che utilizzano HTTP/1 o HTTP/2, abbreviare l'handshake TLS a un round trip riduce effettivamente il tempo di configurazione della connessione del 33%.

HTTP/2 e HTTP/3

HTTP/2 e HTTP/3 offrono entrambi vantaggi in termini di prestazioni rispetto a HTTP/1. HTTP/3 offre maggiori potenziali vantaggi in termini di prestazioni. HTTP/3 non è ancora completamente standardizzato, ma sarà ampiamente supportato una volta che si verificherà.

HTTP/2

Se la tua CDN non ha già abilitato HTTP/2 per impostazione predefinita, ti consigliamo di attivarlo. HTTP/2 offre diversi vantaggi in termini di prestazioni rispetto a HTTP/1 ed è supportato da tutti i principali browser. Le caratteristiche prestazionali di HTTP/2 includono: multiplexing, assegnazione della priorità dei flussi e compressione delle intestazioni.

• multiplexing

  Il multiplexing è probabilmente la funzionalità più importante di HTTP/2. Il multiplexing consente a una singola connessione TCP di gestire contemporaneamente più coppie richiesta-risposta. In questo modo si elimina l'overhead delle configurazioni di connessione non necessarie; dato che il numero di connessioni che un browser può avere aperto in un determinato momento è limitato, ciò ha anche l'implicazione che il browser è ora in grado di richiedere più risorse di una pagina in parallelo. Il multiplexing elimina in teoria la necessità di ottimizzazioni HTTP/1 come la concatenazione e i fogli sprite. Tuttavia, in pratica, queste tecniche rimarranno pertinenti poiché i file più grandi si comprimono meglio.

• Assegnazione della priorità ai flussi

  Il multiplexing consente più flussi simultanei. L'assegnazione della priorità dei flussi fornisce un'interfaccia per la comunicazione della priorità relativa di ciascuno di questi flussi. In questo modo il server può inviare per prime le risorse più importanti, anche se non sono state richieste prima.

L'assegnazione della priorità dei flussi viene espressa dal browser tramite un albero delle dipendenze ed è semplicemente un'istruzione di preference (preferenza): in altre parole, il server non è obbligato a soddisfare (o persino a considerare) le priorità fornite dal browser. L'assegnazione della priorità dei flussi diventa più efficace quando un sito viene pubblicato di più tramite una rete CDN.

Le implementazioni CDN dell'assegnazione della priorità alle risorse HTTP/2 variano notevolmente. Per capire se la tua rete CDN supporta completamente e correttamente la priorità delle risorse HTTP/2, consulta la pagina Is HTTP/2 Fast Yet? (È già veloce HTTP/2?).

Sebbene il passaggio dell'istanza CDN a HTTP/2 sia in gran parte una questione di attivazione di un interruttore, è importante testare accuratamente questa modifica prima di abilitarla in produzione. HTTP/1 e HTTP/2 utilizzano le stesse convenzioni per le intestazioni di richiesta e risposta, ma HTTP/2 è molto meno tollerante quando queste convenzioni non vengono rispettate. Di conseguenza, pratiche non specifiche come l'inclusione di caratteri non ASCII o maiuscoli nelle intestazioni potrebbero iniziare a causare errori una volta abilitato HTTP/2. In questo caso, i tentativi di download della risorsa da parte del browser non andranno a buon fine. Il tentativo di download non riuscito è visibile nella scheda "Rete" di DevTools. Inoltre, nella console verrà visualizzato il messaggio di errore "ERR_HTTP2_PROTOCOL_ERROR".

HTTP/3

HTTP/3 è il successore di HTTP/2. A partire da settembre 2020, tutti i principali browser prevedono il supporto sperimentale per HTTP/3, mentre alcune CDN lo supportano. Le prestazioni sono il vantaggio principale di HTTP/3 rispetto a HTTP/2. In particolare, HTTP/3 elimina il blocco head-of-line a livello di connessione e riduce i tempi di configurazione della connessione.

• Eliminazione del blocco head-of-line

  HTTP/2 ha introdotto il multiplexing, una funzione che consente di utilizzare una singola connessione per trasmettere più flussi di dati contemporaneamente. Tuttavia, con HTTP/2, un singolo pacchetto ignorato blocca tutti i flussi su una connessione (fenomeno noto come blocco head-of-line). Con HTTP/3, un pacchetto ignorato blocca solo un singolo flusso. Questo miglioramento è in gran parte il risultato dell'utilizzo di HTTP/3 che utilizza UDP (HTTP/3 utilizza UDP tramite QUIC) anziché TCP. Questo rende HTTP/3 particolarmente utile per il trasferimento di dati su reti congestionate o con perdita di dati.

• Tempi di configurazione della connessione ridotti

  HTTP/3 utilizza TLS 1.3 e, di conseguenza, condivide i suoi vantaggi in termini di prestazioni: stabilire una nuova connessione richiede solo un singolo round trip, mentre il ripristino di una connessione esistente non richiede round trip.

HTTP/3 avrà il maggiore impatto sugli utenti con connessioni di rete di scarsa qualità: non solo perché HTTP/3 gestisce la perdita di pacchetti meglio rispetto ai predecessori, ma anche perché il risparmio di tempo assoluto derivante da una configurazione di connessione 0-RTT o 1-RTT sarà maggiore sulle reti con latenza elevata.

Ottimizzazione delle immagini

I servizi di ottimizzazione delle immagini CDN in genere si concentrano su ottimizzazioni delle immagini che possono essere applicate automaticamente per ridurre le dimensioni di trasferimento delle immagini. Ad esempio, l'eliminazione dei dati EXIF, l'applicazione di compressione senza perdita e la conversione delle immagini in formati file più recenti (ad esempio, WebP). Le immagini rappresentano circa il 50% dei byte di trasferimento sulla pagina web mediana, quindi l'ottimizzazione delle immagini può ridurre notevolmente le dimensioni della pagina.

Minimizzazione

La minimizzazione rimuove i caratteri non necessari da JavaScript, CSS e HTML. È preferibile eseguire la minimizzazione sul server di origine, anziché sulla rete CDN. I proprietari dei siti hanno più contesto riguardo al codice da minimizzare, pertanto possono spesso utilizzare tecniche di minimizzazione più aggressive rispetto a quelle impiegate dalle reti CDN. Tuttavia, se la minimizzazione del codice nell'origine non è un'opzione, la minimizzazione da parte della CDN è una buona alternativa.

Conclusione

• Utilizza una rete CDN: le CDN forniscono risorse rapidamente, riducono il carico sul server di origine e sono utili per gestire i picchi di traffico.
• Memorizza nella cache i contenuti con la maggiore rapidità possibile: i contenuti statici e dinamici possono e devono essere memorizzati nella cache, anche se di durata diversa. Controlla periodicamente il tuo sito per assicurarti che i contenuti vengano memorizzati nella cache in modo ottimale.
• Abilita le funzionalità di prestazioni della CDN: funzionalità come Brotli, TLS 1.3, HTTP/2 e HTTP/3 migliorano ulteriormente le prestazioni.