Abilita compressione dinamica

La compressione dinamica comprime automaticamente le risposte pubblicate da Cloud CDN. Le dimensioni dei dati inviati sulla rete vengono ridotte dal 60% all'85% nei casi tipici.

La riduzione delle dimensioni riduce il tempo necessario per scaricare i contenuti. Per asset importanti come fogli di stile (CSS), script (JavaScript) e manifest video (HLS/DASH), questa operazione può ridurre i tempi di caricamento della pagina e di inizio del video.

Scopri di più sui vantaggi della compressione delle risposte nella guida Elementi fondamentali del web.

Puoi attivare la compressione su un servizio di backend o su un bucket di backend.

Esempi di casi d'uso

La compressione dinamica riduce direttamente le dimensioni dei dati inviati dall'edge Cloud CDN al client. In questo modo puoi:

• Riduci le dimensioni di CSS e JavaScript, contribuendo a velocizzare il rendering delle pagine web e a ridurre il tempo necessario per il primo visibile, un'importante metrica del rendimento web.

• Hanno un impatto positivo significativo sulla memorizzazione nella cache delle risposte dell'API REST, ad esempio i payload JSON. Questi payload si comprimono bene a causa delle chiavi ripetute, degli spazi e delle parentesi graffe. La memorizzazione nella cache delle API pubbliche per 5-10 secondi è un approccio molto utilizzato per ridurre il carico dell'origine mantenendo la freschezza dei dati.

  Anche senza la memorizzazione nella cache, la compressione di queste risposte può ridurre i byte inviati fino al 90%.

• Migliorare l'ora di inizio della riproduzione per il caricamento dei video e la latenza di accesso per lo streaming live. Le playlist live di grandi dimensioni (manifest) contengono una quantità significativa di dati ripetuti, tra cui l'host + il prefisso del percorso di ogni segmento, nonché i metadati della playlist HLS o DASH. Più velocemente si carica la playlist o si possono scaricare gli aggiornamenti della playlist, meno tempo deve attendere un client per analizzare e iniziare a scaricare i segmenti video a cui si fa riferimento. Le playlist HLS e DASH spesso registrano una riduzione totale delle dimensioni di oltre il 90%.

Prima di iniziare

Assicurati di disporre di quanto segue:

• Un backend compatibile con Cloud CDN configurato. Se non hai configurato Cloud CDN, puoi seguire una delle guide alla configurazione.
• Il tuo backend ha contenuti comprimibili pronti per essere pubblicati, ad esempio asset web o manifest video compresi tra 1 KiB e 10 MiB.
• I client non si basano sul recupero di contenuti parziali con richieste di intervallo o con ETag forti. Questi formati non sono compatibili con la compressione dinamica.
• I client possono gestire le risposte senza intestazioni Content-Length. Ad esempio, le mancate corrispondenze della cache che Cloud CDN comprime non hanno intestazioni Content-Length.
• Il ruolo Amministratore bilanciatore del carico Compute IAM (roles/compute.loadBalancerAdmin), necessario per apportare modifiche alla configurazione di backend.

Attivare la compressione su un servizio di backend o un bucket di backend

Per attivare la compressione:

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

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

"compressionMode": AUTOMATIC

Entro pochi minuti, la configurazione viene propagata a tutte le località edge. I contenuti comprimibili pubblicati dal backend vengono compressi prima di essere caricati 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 cliente
• Il rapporto di compressione previsto della risposta
• Velocità di compressione (throughput) di Cloud CDN

Brotli può ridurre ulteriormente le dimensioni del download per la maggior parte dei tipi di contenuti rispetto a gzip, con prestazioni di decompressione simili, rendendolo più veloce in generale 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 del download e il costo della CPU sul client. I livelli di compressione più elevati non migliorano sempre le prestazioni, in particolare sui dispositivi mobili meno potenti.

Quando Cloud CDN comprime inizialmente i contenuti, rimuove l'intestazione Content-Length dalla risposta. Questo è necessario per consentire di pubblicare la risposta il più rapidamente possibile, in quanto la lunghezza completa dei contenuti è sconosciuta finché l'intera risposta non è stata 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 una risposta viene compressa?

Se una richiesta contiene un'intestazione Accept-Encoding che elenca esplicitamente il supporto per gli algoritmi gzip o Brotli, le risposte non compresse pubblicate dal backend (origine) con un'intestazione Accept-Encoding corrispondente ai tipi di contenuti comprimibili vengono compresse con gzip o Brotli, a seconda dei casi.Content-Type Se una richiesta non ha un'intestazione Accept-Encoding o se ne ha una con Accept-Encoding: *, la risposta non viene compressa.

Ad esempio, se in una richiesta del client è presente un'intestazione Accept-Encoding, la risposta viene compressa (o meno) in base alle informazioni riportate nella tabella seguente:

Tipi di contenuti comprimibili

La compressione dinamica si applica ai seguenti tipi MIME, in base all'Content-Type intestazione della risposta HTTP. Le risposte che non hanno un'Content-Type intestazione di risposta non vengono compresse.

I tipi di contenuti 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 o application/vnd.apple.mpegURL
• Manifest DASH: application/dash+xml

La tabella seguente riassume l'impatto del tipo MIME sulla compressibilità.

I formati di immagini e video (ad esempio image/jpeg, image/png e video/mpeg4) sono quasi sempre già compressi, quindi Cloud CDN non li comprime. La ricompressione di una risposta già compressa raramente riduce le dimensioni del file e i client potrebbero mostrare un comportamento imprevisto quando ricevono una risposta di questo tipo.

Quando una risposta non viene compressa?

La compressione dinamica non comprime una risposta che presenta una o più delle seguenti caratteristiche:

• La risposta non ha un'intestazione Content-Type che corrisponda 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 la compressione e la decompressione spesso compensa qualsiasi vantaggio. Inoltre, ci sono meno contenuti da comprimere, il che può ridurre l'efficacia della compressione e portare a un rapporto di compressione inferiore.

• È più grande di 10 MiB.

• Ha un'intestazione Cache-Control: no-transform.

• Ha un'intestazione Vary: Accept-Encoding.

Richieste di intervalli

Quando Cloud CDN comprime una risposta, aggiunge un'intestazione Accept-Ranges: none e sostituisce eventuali intestazioni Accept-Ranges: none esistenti.Accept-Ranges I hit della cache per queste risposte ignorano le intestazioni Range.

In questo modo si evita di fornire contenuti parziali errati ai client perché non c'è modo di sapere con certezza se un client si aspetta un intervallo di byte dalla forma compressa o non compressa di una risorsa.

ETags

Quando la compressione dinamica comprime una risposta, eventuali intestazioni ETag significativamente forti vengono attenuate, come richiesto dalla sezione 2.3 della RFC 7232. Ad esempio, ETag: "xyzzy" viene sostituito con ETag: W/"xyzzy".

Intestazione Vary

Quando viene inviata una risposta che potrebbe essere compressa (a seconda della richiesta), Cloud CDN aggiunge l'intestazione Vary: Accept-Encoding alla risposta.

Riepilogo delle modifiche alla risposta

La tabella seguente riassume le modifiche apportate da Cloud CDN alle intestazioni di una risposta quando si verifica la compressione:

Logging

I log di Cloud CDN includono un campo compressionStatus in jsonPayload che indica se la risposta è stata compressa dal bilanciatore del carico, nonché 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 in uscita della cache o il trasferimento di dati in uscita da internet pertinenti viene misurato in base ai byte compressi finali inviati al client.

Se pubblichi una grande quantità di risposte comprimibili, questo può comportare una riduzione delle tariffe mensili per il trasferimento di dati in uscita, nonché un aumento del rendimento per gli utenti finali.

Metriche

Quando la compressione è attiva, la metrica https/response_bytes_count esistente in loadbalancing.googleapis.com indica le dimensioni della risposta compressa.

Dovresti notare un calo dei byte di risposta totale (e del throughput del trasferimento di dati in uscita).

Se pubblichi una grande quantità di contenuti basati su testo che si comprimono bene, come HTML, CSS, JavaScript o JSON, potresti notare un forte calo in termini di byte di risposta.

Per ulteriori informazioni, consulta la sezione Monitoraggio.

Passaggi successivi

• Per capire in che modo le modalità di cache semplificano la memorizzazione nella cache dei contenuti, consulta Modificare le modalità di cache.
• Per attivare Cloud CDN per le istanze con bilanciamento del carico HTTP(S) e per i bucket di archiviazione, consulta la Panoramica della configurazione.
• Per scoprire di più sull'annullamento della convalida delle cache, consulta la Panoramica dell'annullamento della convalida della cache.
• Per trovare i punti di presenza GFE, consulta Località delle cache.