La compressione dinamica comprime automaticamente le risposte fornite da Cloud CDN. Le dimensioni dei dati inviati attraverso la rete si riducono dal 60% all'85% nei casi tipici.
La riduzione delle dimensioni riduce il tempo necessario per scaricare i contenuti. Per asset importanti come i fogli di stile (CSS), gli script (JavaScript) e i manifest video (HLS/DASH), è possibile ridurre il caricamento della pagina e i tempi di avvio del video.
Per ulteriori informazioni sui vantaggi della compressione delle risposte, consulta la guida Web Fundamentals.
Puoi abilitare la compressione su un servizio di backend o un bucket di backend.
Esempi di casi d'uso
La compressione dinamica riduce direttamente le dimensioni dei dati inviati dall'edge di Cloud CDN al client. Con questa operazione puoi eseguire direttamente le seguenti operazioni:
- Riduci le dimensioni di CSS e JavaScript, per velocizzare il rendering delle pagine web e ridurre i tempi di passaggio per First Contentful Paint, un'importante metrica delle prestazioni web.
Hanno un grande impatto positivo quando memorizzano nella cache le risposte delle API REST, come i payload JSON. Questi payload si comprimono bene a causa della ripetizione di chiavi, spazi vuoti e parentesi graffe. La memorizzazione nella cache delle API pubbliche per 5-10 secondi è un approccio diffuso per ridurre il carico dall'origine, mantenendo al contempo l'aggiornamento dei dati.
Anche senza memorizzazione nella cache, la compressione di queste risposte può ridurre il numero totale di byte inviati fino al 90%.
Migliora l'ora di inizio della riproduzione per la distribuzione del video e la latenza di join per il live streaming. Le playlist dal vivo di grandi dimensioni (manifest) contengono una quantità significativa di dati ripetuti, inclusi il prefisso host + percorso di ogni segmento, nonché i metadati delle playlist HLS o DASH. Più velocemente è possibile caricare la playlist o scaricare gli aggiornamenti della playlist, minore è il tempo di attesa del cliente per l'analisi e il download dei segmenti video di riferimento. Le playlist HLS e DASH spesso registrano una riduzione delle dimensioni totali di oltre il 90%.
Prima di iniziare
Assicurati di disporre di quanto segue:
- Un backend abilitato per Cloud CDN configurato. Se non hai ancora configurato Cloud CDN, puoi seguire una delle guide alla configurazione.
- Il tuo backend ha contenuti comprimibili pronti per la pubblicazione, ad esempio asset web o manifest video compresi tra 1 KiB e 10 MiB (inclusi).
- I client non fanno affidamento sul recupero di contenuti parziali con richieste di intervallo o con ETag efficaci. Questi elementi non sono compatibili con la compressione dinamica.
- I client possono gestire le risposte senza intestazioni
Content-Length
. Ad esempio, i fallimenti della cache che vengono compressi da Cloud CDN non hanno intestazioniContent-Length
. - Il ruolo Amministratore bilanciatore del carico Compute
(
roles/compute.loadBalancerAdmin
), necessario per apportare modifiche alla configurazione del backend.
Abilita la compressione su un servizio di backend o un bucket di backend
Per attivare la compressione, procedi nel seguente modo.
Console
Aggiungi una nuova origine
Per aggiungere e configurare una nuova origine, segui le istruzioni in Panoramica della configurazione per il tipo di backend appropriato. Quando crei l'origine, utilizza la sezione Opzioni avanzate per configurare la compressione dinamica selezionando Automatica nell'elenco Modalità di compressione.
Modificare un'origine esistente
Per modificare un'origine Cloud CDN esistente:
Nella console Google Cloud, vai alla pagina Origini di Cloud CDN.
Fai clic sul nome dell'origine che vuoi modificare, quindi su Modifica.
Nella sezione Nozioni di base sull'origine, fai clic su Avanti.
Nella sezione Regole host e percorso, fai clic su Avanti.
Nella sezione Prestazioni della cache, vai a Opzioni avanzate.
Nell'elenco Modalità di compressione, seleziona Automatica.
Per applicare le modifiche, fai clic su Fine.
gcloud
Per i servizi di backend, utilizza il comando gcloud compute backend-services
create
o il comando gcloud compute backend-services
update
con il flag --compression-mode
.
Per i bucket di backend, utilizza il comando gcloud compute backend-buckets create
o il comando gcloud compute backend-buckets update
con il flag --compression-mode
.
Per un nuovo servizio di backend, utilizza il comando create
:
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --compression-mode=AUTOMATIC
Per un servizio di backend esistente, usa il comando update
:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --compression-mode=AUTOMATIC
Per un nuovo bucket di backend, utilizza il comando create
:
gcloud compute backend-buckets create BACKEND_BUCKET_NAME --compression-mode=AUTOMATIC
Per un bucket di backend esistente, utilizza il comando update
:
gcloud compute backend-buckets update BACKEND_BUCKET_NAME --compression-mode=AUTOMATIC
compression-mode
può essere uno dei seguenti:
AUTOMATIC
: utilizza automaticamente la compressione migliore in base all'intestazioneAccept-Encoding
inviata dal client. Nella maggior parte dei casi, questo si traduce in una compressione di Brotli.DISABLED
(predefinito): disattiva la compressione.
API
Per i servizi di backend, utilizza il metodo backendServices.insert
o il metodo backendServices.update
.
Per i bucket di backend, utilizza il metodo backendBuckets.insert
o il metodo backendBuckets.update
.
Utilizza uno dei seguenti comandi:
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
Aggiungi il seguente snippet al corpo della richiesta JSON:
"compressionMode": AUTOMATIC
compression-mode
può essere uno dei seguenti:
AUTOMATIC
(consigliato): utilizza automaticamente la compressione migliore in base all'intestazioneAccept-Encoding
inviata dal client. Nella maggior parte dei casi, questo si traduce in una compressione di Brotli.DISABLED
(predefinito): disattiva la compressione.
Entro pochi minuti, la configurazione si propaga a tutte le località perimetrali. I contenuti comprimibili forniti dal backend vengono compressi prima di essere pubblicati sul client.
Modalità di compressione
La modalità di compressione predefinita è DISABLED
.
La modalità AUTOMATIC
consente a Cloud CDN di scegliere il metodo di compressione migliore in base a quanto segue:
- La codifica accettata dal client
- Il rapporto di compressione previsto della risposta
- Velocità di compressione (velocità effettiva) di Cloud CDN
Brotli può produrre un'ulteriore riduzione del 10-20% delle dimensioni di download per la maggior parte dei tipi di contenuti su gzip, con prestazioni di decompressione simili, rendendola più veloce nel complesso se si considerano il tempo di download e la velocità di decompressione sul client.
Cloud CDN indica il metodo di compressione scelto come gzip
o brotli
nell'intestazione Content-Encoding
della risposta.
Cloud CDN determina il livello di compressione per bilanciare le dimensioni totali di download e il costo della CPU sul client. Livelli di compressione più elevati non sempre migliorano le prestazioni, soprattutto sui dispositivi mobili con prestazioni inferiori.
Quando Cloud CDN comprime inizialmente i contenuti, rimuove l'intestazione Content-Length
dalla risposta. Ciò è necessario per consentire la pubblicazione della risposta il più rapidamente possibile perché la lunghezza completa del contenuto è sconosciuta fino a quando l'intera risposta non viene compressa.
Dopo che una risposta è stata compressa e memorizzata nella cache, Cloud CDN potrebbe includere l'intestazione Content-Length
nelle risposte successive.
(per HTTP/1.1 e versioni precedenti, Cloud CDN utilizza Transfer-Encoding:
chunked
nella risposta quando non utilizza Content-Length
.)
Quando viene compressa una risposta?
Se una richiesta ha un'intestazione Accept-Encoding
che elenca esplicitamente il supporto
per gli algoritmi gzip o Brotli, le risposte non compresse fornite dal
backend (origine) con un'intestazione Content-Type
che corrisponde ai
tipi di contenuti comprimibili vengono compresse con gzip o
Brotli, di conseguenza. Se una richiesta non ha un'intestazione Accept-Encoding
o ha
Accept-Encoding: *
, la risposta non viene compressa.
Ad esempio, se viene specificata un'intestazione Accept-Encoding
in una richiesta del client, la risposta
viene compressa (o meno) in base alle informazioni nella seguente tabella:
Intestazione della richiesta Accept-Encoding | Codifica della risposta |
---|---|
gzip, compress, br |
Brotli |
deflate |
Non compresso |
deflate, gzip |
gzip |
identity |
Non compresso |
* |
Non compresso |
Tipi di contenuti comprimibili
La compressione dinamica si applica ai seguenti tipi MIME, in base all'intestazione della risposta HTTP Content-Type
. Le risposte che non hanno un'intestazione Content-Type
non vengono compresse.
I tipi di contenuti più comuni e i relativi tipi MIME includono:
- Contenuti HTML:
text/html
- Fogli di stile:
text/css
- JavaScript:
application/javascript
- JSON:
application/json
- Playlist HLS:
application/x-mpegURL
oapplication/vnd.apple.mpegURL
- Manifest DASH:
application/dash+xml
La tabella seguente riassume il modo in cui il tipo MIME influisce sulla comprimibilità.
Tipi MIME comprimibili | |
---|---|
Corrispondenza esatta | application/x-JavaScript application/x-sdch-dictionary application/JavaScript application/xml application/csv application/json application/json+protobuf application/Signed-Exchange application/vnd.apple.mpegurl application/wasm application/x-plist application/x-protobuffertobufxml application/x-cl |
Corrispondenza di schema | application/*+json application/*+xml application/*mpegURL text/* |
I formati di immagini e video (ad esempio image/jpeg
, image/png
e video/mpeg4
)
sono quasi sempre già compressi, per cui Cloud CDN non li
comprime. La ricompressione di una risposta già compressa raramente riduce le dimensioni del file e i client potrebbero presentare comportamenti imprevisti quando ricevono risposte di questo tipo.
Quando una risposta non viene compressa?
La compressione dinamica non comprime una risposta con una o più delle seguenti caratteristiche:
- La risposta non ha un'intestazione
Content-Type
corrispondente a un tipo di contenuto comprimibile. - Non ha un'intestazione
Content-Length
. - Ha un'intestazione
Content-Encoding
. È inferiore a 1 KiB.
Il tempo impiegato per comprimere e decomprimere spesso i vantaggi. Inoltre, ci sono meno contenuti da comprimere, il che può ridurre l'efficacia della compressione e portare a un rapporto di compressione più basso.
È più grande di 10 MiB.
Ha un'intestazione
Cache-Control: no-transform
.Ha un'intestazione
Vary: Accept-Encoding
.
Richieste di intervallo
Quando Cloud CDN comprime una risposta, Cloud CDN
aggiunge un'intestazione Accept-Ranges: none
e sostituisce qualsiasi intestazione
Accept-Ranges
esistente. Gli hit della cache per queste risposte ignorano le intestazioni Range
.
In questo modo si impedisce di fornire ai client contenuti parziali non corretti, perché non è possibile assicurarsi se un client si aspetti un intervallo di byte dalla forma compressa o non compressa di una risorsa.
ETags
Quando la compressione dinamica comprime una risposta, qualsiasi intestazione ETag efficace viene indebolita, come richiesto dalla sezione 2.3 di RFC 7232.
Ad esempio, ETag: "xyzzy"
viene sostituito con ETag: W/"xyzzy"
.
Intestazione Varia
Quando si esegue una risposta che potrebbe essere compressa (a seconda della richiesta), Cloud CDN aggiunge l'intestazione Vary: Accept-Encoding
alla risposta.
Riepilogo delle modifiche alle risposte
La tabella seguente riassume le modifiche apportate da Cloud CDN alle intestazioni di una risposta quando si è verificata la compressione:
Intestazione della risposta | Valore intestazione dopo la compressione |
---|---|
Codifica dei contenuti | Impostalo su gzip o brotli. |
ETag | Qualsiasi tag entità forte viene sostituito con una versione indebolita, indicata dal prefisso W/. |
Intervalli di accettazione | Imposta il valore none. |
Content-Length | Potrebbe essere rimosso completamente o, se presente, impostato sulla lunghezza dei contenuti del corpo compresso. |
Codifica-trasferimento | Per HTTP/1.1 e protocolli precedenti, se Cloud CDN rimuove Content-Length, aggiunge questa intestazione, con il valore impostato su chunked, e suddivide il corpo della risposta. |
Logging
I log di Cloud CDN includono un campo compressionStatus
in jsonPayload
che indica se la risposta è stata compressa dal bilanciatore del carico e il tipo di compressione.
{ insertId: "1c02hw9g3gjay67" jsonPayload: { @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" statusDetails: "response_sent_by_backend" cacheId: "IAD-862d661f" compressionStatus: "br" } }
Fatturazione
Quando una risposta viene compressa da Cloud CDN o Cloud Load Balancing, il trasferimento di dati dalla cache in uscita pertinente o il trasferimento di dati internet in uscita (rispettivamente) viene misurato in base ai byte compressi finali inviati al client.
Se esegui una grande quantità di risposte comprimibili, ciò può comportare una riduzione delle tariffe mensili per il trasferimento di dati in uscita, nonché un aumento delle prestazioni per gli utenti finali.
Metriche
Quando la compressione è abilitata, la metrica https/response_bytes_count
esistente in loadbalancing.googleapis.com
indica le dimensioni della risposta compresse.
È probabile che si verifichi un calo dei byte di risposta totali (e della velocità effettiva di trasferimento dei dati in uscita).
Se pubblichi una grande quantità di contenuti basati su testo che vengono compressi bene, ad esempio HTML, CSS, JavaScript o JSON, potresti notare un calo significativo dei byte di risposta.
Per ulteriori informazioni, consulta Monitoring.
Passaggi successivi
- Per capire in che modo le modalità cache semplificano la memorizzazione dei contenuti nella cache, consulta Cambiare le modalità cache.
- Per abilitare Cloud CDN per le tue istanze con bilanciamento del carico HTTP(S) e i bucket di archiviazione, consulta Panoramica della configurazione.
- Per informazioni sull'annullamento della convalida delle cache, consulta Panoramica dell'annullamento della convalida delle cache.
- Per trovare i punti di presenza GFE, consulta Posizioni della cache.