Attiva la compressione dinamica

La compressione dinamica comprime automaticamente le risposte fornite da Cloud CDN. Le dimensioni dei dati inviati attraverso la rete si riducono del 60%-85% nei casi tipici.

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

Per ulteriori informazioni sui vantaggi della compressione delle risposte, consulta la guida di 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 dal perimetro di Cloud CDN al client. In questo modo puoi:

  • Riduci le dimensioni di CSS e JavaScript, contribuendo a un rendering più rapido delle pagine web e a ridurre il tempo necessario per First Contentful Paint, un'importante metrica per le prestazioni web.

  • Hanno un grande impatto positivo sulla memorizzazione nella cache delle 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 popolare per ridurre il carico dell'origine, mantenendo al contempo l'aggiornamento dei dati.

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

  • Migliora l'ora di inizio della riproduzione per l'invio dei video e la latenza di join per il live streaming. Le playlist dal vivo di grandi dimensioni (manifest) contengono una notevole quantità di dati ripetuti, tra cui il prefisso host + percorso di ciascun segmento, nonché i metadati delle playlist HLS o DASH. Più velocemente la playlist viene caricata o è possibile scaricare gli aggiornamenti della playlist, meno tempo il client è in attesa di analizzare e iniziare a scaricare i 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:

  • È stato configurato un backend abilitato per Cloud CDN. Se Cloud CDN non è attualmente configurato, puoi seguire una delle guide alla configurazione.
  • Il backend abbia 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. Non sono compatibili con la compressione dinamica.
  • I client possono gestire le risposte senza intestazioni Content-Length. Ad esempio, i fallimenti della cache che le compressione di Cloud CDN non hanno intestazioni Content-Length.
  • Il ruolo Amministratore Bilanciatore del carico Compute (roles/compute.loadBalancerAdmin) IAM, necessario per apportare modifiche alla configurazione del backend.

Abilita la compressione su un servizio o un bucket di backend

Per attivare la compressione:

Console

Aggiungere una nuova origine

Per aggiungere e configurare una nuova origine, segui le istruzioni in Panoramica della configurazione per il tipo di backend appropriato. Durante la creazione dell'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:

  1. Nella console Google Cloud, vai alla pagina Origini Cloud CDN.

    Vai alle origini Cloud CDN

  2. Fai clic sul nome dell'origine che vuoi modificare, quindi fai clic su Modifica.

  3. Nella sezione Nozioni di base sull'origine, fai clic su Avanti.

  4. Nella sezione Regole host e percorso, fai clic su Avanti.

  5. Nella sezione Rendimento della cache, vai a Opzioni avanzate.

  6. Nell'elenco Modalità di compressione, seleziona Automatica.

  7. 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, utilizza 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'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, questo fa sì che la compressione Brotli sia favorita.
  • DISABLED (predefinita): 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 (consigliata): utilizza automaticamente la compressione migliore in base all'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, questo fa sì che la compressione Brotli sia favorita.
  • DISABLED (predefinita): disattiva la compressione.

Entro pochi minuti, la configurazione si propaga a tutte le località sul perimetro della rete. I contenuti comprimibili forniti dal backend vengono compressi prima di essere recapitati al 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:

  • Codifica accettata dal cliente
  • 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 rispetto a gzip, con prestazioni di decompressione simili, rendendolo più veloce in generale se si considera 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 di download totali e i costi della CPU sul client. Livelli di compressione più elevati non sempre migliorano le prestazioni, in particolare sui dispositivi mobili con minore potenza.

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 alla compressione dell'intera risposta. 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 usa Content-Length.

Quando viene compressa una risposta?

Se una richiesta ha un'intestazione Accept-Encoding che elenca esplicitamente il supporto degli 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 contiene Accept-Encoding: *, la risposta non viene compressa.

Ad esempio, se si tratta di un'intestazione Accept-Encoding in una richiesta client, la risposta viene compressa (o meno) in base alle informazioni della tabella seguente:

Intestazione della richiesta Accept-Encoding Codifica delle risposte
gzip, compress, br Brotli (BR)
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 senza intestazione della risposta Content-Type 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 in che modo il tipo MIME influisce sulla comprimibilità.

  Tipi MIME comprimibili
Corrispondenza esatta application/x-JavaScript
application/x-sdch-mpegx-dictionary
application/JavaScript
application/xml
application/csv
application/json
application/json+protobuf
application/istituito e modificato
application/vnd.apple.mpegurl
application/wasm
application/x-plist-xml
application/x-protobuffer-xml
application/x-protobuffer
Corrispondenza di schema application/*+json
application/*+xml
application/*mpegURL
text/*

I formati di immagini e video (come image/jpeg, image/png e video/mpeg4) sono quasi sempre già compressi, perciò 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 una risposta 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 contenuti comprimibili.
  • Non ha un'intestazione Content-Length.

  • È inferiore a 1 KiB.

    Il tempo impiegato per comprimere e decomprimere spesso compensa eventuali vantaggi. Ci sono anche meno contenuti da comprimere, il che può ridurre l'efficacia della compressione e il rapporto di compressione.

  • Ha dimensioni superiori a 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 eventuali intestazioni Accept-Ranges esistenti. Gli hit memorizzati nella cache per queste risposte ignorano le intestazioni Range.

In questo modo si impedisce la pubblicazione di contenuti parziali errati per i client, perché non è possibile assicurarsi che un client preveda un intervallo di byte dalla forma compressa o non compressa di una risorsa.

ETags

Quando la compressione dinamica comprime una risposta, tutte le intestazioni ETag efficaci sono indebolite, come richiesto dalla sezione 2.3 di RFC 7232. Ad esempio, ETag: "xyzzy" viene sostituito con ETag: W/"xyzzy".

Varia intestazione

Quando fornisci 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 seguente tabella 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 Imposta il valore su gzip o brotli.
ETag Qualsiasi tag entità efficace viene sostituito con una versione indebolita, indicata dal prefisso W/.
Accetta-intervalli Imposta il valore sul valore none.
Content-Length Potrebbe essere rimosso completamente o, se presente, impostato sulla lunghezza del corpo compresso.
Codifica-trasferimento Per i protocolli HTTP/1.1 e 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, oltre che dal 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 dei dati della cache in uscita pertinente o il trasferimento dei dati internet in uscita vengono misurati rispettivamente in base ai byte compressi finali inviati al client.

Se fornisci 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 compressa.

È possibile che si verifichi un calo dei byte totali di risposta (e della velocità effettiva di trasferimento dei dati in uscita).

Se pubblichi una grande quantità di contenuti basati su testo che vengono compressi correttamente, ad esempio HTML, CSS, JavaScript o JSON, potresti notare una diminuzione significativa nei byte di risposta.

Per ulteriori informazioni, consulta Monitoring.

Passaggi successivi