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:

Console

Aggiungere una nuova origine

Per aggiungere e configurare una nuova origine, segui le istruzioni riportate nella 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:

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

    Vai a Origini

  2. Fai clic sul nome dell'origine che vuoi modificare e poi su Modifica.

  3. Nella sezione Nozioni di base su Origin, fai clic su Avanti.

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

  5. Nella sezione Prestazioni 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, si ottiene una compressione Brotli.
  • DISABLED (impostazione 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 (consigliato): utilizza automaticamente la compressione migliore in base all'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, si ottiene una compressione Brotli.
  • DISABLED (impostazione predefinita): disattiva la compressione.

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:

Intestazione della richiesta Accept-Encoding Codifica della risposta
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'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à.

  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-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
font/ttf
font/otf
font/eot
image/svg+xml
image/pwg-raster
image/x-icon
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/mpegURL
application/dash+xml
application/vnd.ms-sstr+xml
Corrispondenza di pattern 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, 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:

Intestazione della risposta Valore dell'intestazione dopo la compressione
Content-Encoding Imposta su gzip o brotli.
ETag Qualsiasi tag entità forte viene sostituito con una versione attenuata, indicata dal prefisso W/.
Accept-Ranges Imposta il valore none.
Content-Length Potrebbe essere rimosso completamente o, se presente, impostato sulla lunghezza dei contenuti del corpo compressi.
Transfer-Encoding Per HTTP/1.1 e i protocolli precedenti, se Cloud CDN rimuove Content-Length, aggiunge questa intestazione, con il valore impostato su chunked, e suddivide il corpo della risposta in blocchi.

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