Abilita compressione dinamica

La compressione dinamica comprime automaticamente le risposte fornite 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), questo può ridurre i tempi di caricamento della pagina e di avvio del video.

Puoi scoprire di più sui vantaggi della compressione delle risposte nella guida Web Fundamentals.

Puoi attivare 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. Questo ottiene direttamente i seguenti effetti:

  • Riduce le dimensioni di CSS e JavaScript, contribuendo a eseguire il rendering delle pagine web più velocemente e riducendo il tempo di First Contentful Paint, un'importante metrica delle prestazioni web.

  • Ha un impatto positivo significativo quando le risposte delle API REST, ad esempio i payload JSON, sono memorizzate nella cache. Questi payload vengono compressi bene grazie alle presenza di chiavi ripetute, spazi vuoti e parentesi graffe. La memorizzazione nella cache delle API pubbliche per 5-10 secondi è un approccio comune per ridurre il carico sull'origine mantenendo i dati aggiornati.

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

  • Migliora il tempo di avvio della riproduzione per il caricamento dei video e la latenza di accesso per i live streaming. Le playlist live (manifest) di grandi dimensioni contengono una quantità significativa di dati ripetuti, tra cui il prefisso host + percorso di ogni segmento, nonché i metadati della playlist HLS o DASH. Più rapido è il tempo di caricamento della playlist o di download degli aggiornamenti della playlist, minore sarà il tempo atteso da un client per analizzare e iniziare a scaricare i segmenti video a cui viene fatto riferimento. Le playlist HLS e DASH spesso registrano una riduzione delle dimensioni totali superiore al 90%.

Prima di iniziare

Assicurati di disporre di quanto segue:

  • Un backend configurato con Cloud CDN abilitato. Se non hai configurato Cloud CDN, puoi seguire una delle guide alla configurazione.
  • Il backend deve avere contenuti comprimibili pronti per la pubblicazione, ad esempio asset web o manifest video tra 1 KiB e 10 MiB (inclusi).
  • Client che non fanno affidamento sul recupero di contenuti parziali con richieste di intervalli o con ETag forti, che non sono compatibili con la compressione dinamica.
  • Client in grado di gestire le risposte senza intestazioni Content-Length. Ad esempio, i fallimenti della cache compressi da Cloud CDN non hanno intestazioni Content-Length.
  • Il ruolo IAM Compute Load Balancer Admin (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 abilitare la compressione, segui questi passaggi.

Console

Aggiungi una nuova origine

Per aggiungere e configurare una nuova origine, segui le istruzioni riportate in Panoramica della configurazione per il tipo di backend in questione. Quando crei l'origine, utilizza la sezione Opzioni avanzate per configurare la compressione dinamica selezionando Automatica nell'elenco Modalità di compressione.

Modifica 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 da modificare, quindi su Modifica.

  3. Nella sezione Elementi di base dell'origine, 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ò avere uno dei seguenti valori:

  • AUTOMATIC: utilizza automaticamente la migliore compressione in base all'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, ciò comporta la preferenza per la compressione Brotli.
  • DISABLED (valore predefinito): disabilita 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ò avere uno dei seguenti valori:

  • AUTOMATIC (consigliato): utilizza automaticamente la migliore compressione in base all'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, ciò comporta la preferenza per la compressione Brotli.
  • DISABLED (valore predefinito): disabilita la compressione.

Nel giro di pochi minuti, la configurazione viene propagata a tutte le località perimetrali. I contenuti comprimibili forniti dal backend vengono compressi prima di essere forniti 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:

  • La codifica accettata dal client
  • Il rapporto di compressione previsto della risposta
  • La velocità di compressione (throughput) di Cloud CDN

La compressione Brotli può ridurre le dimensioni del download di un ulteriore 10-20% rispetto a gzip per la maggior parte dei tipi di contenuti, con prestazioni di decompressione simili, il che la rende complessivamente più veloce 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 totali del download e il costo della CPU sul client. Livelli di compressione più elevati non sempre migliorano le prestazioni, soprattutto sui dispositivi mobili meno potenti.

Quando Cloud CDN comprime inizialmente i contenuti, rimuove l'intestazione Content-Length dalla risposta. Questa operazione è necessaria per consentire di fornire la risposta il più rapidamente possibile, perché 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.

Casi in cui una risposta viene compressa

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, a seconda del caso. Se una richiesta non ha un'intestazione Accept-Encoding o se il valore è Accept-Encoding: *, la risposta non viene compressa.

Ad esempio, data un'intestazione Accept-Encoding in una richiesta client, 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 compressa
deflate, gzip gzip
identity Non compressa
* Non compressa

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 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 seguente tabella riassume l'influenza dei diversi tipi MIME 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-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 pattern application/*+json
application/*+xml
application/*mpegURL
text/*

I formati immagine e video (come 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.

Casi in cui 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 corrisponde 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 vanifica gli eventuali vantaggi. Inoltre, ci sono meno contenuti da comprimere, il che può ridurre l'efficacia della compressione e portare a un rapporto di compressione inferiore.

  • È superiore a 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 le intestazioni Accept-Ranges esistenti. I successi della cache per queste risposte ignorano le intestazioni Range.

In questo modo si impedisce di fornire contenuti parziali errati ai client, perché non è possibile sapere se un client si aspetta un intervallo di byte dalla forma compressa o decompressa di una risorsa.

ETag

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

Intestazione Vary

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

Riepilogo delle modifiche alle risposte

La seguente tabella riepiloga le modifiche apportate da Cloud CDN alle intestazioni di una risposta quando è stata eseguita la compressione:

Intestazione della risposta Valore dell'intestazione dopo la compressione
Content-Encoding Impostata su gzip o brotli.
ETag Qualsiasi tag di entità forte viene sostituito con una versione debole, indicata dal prefisso W/.
Accept-Ranges Impostata sul valore none.
Content-Length Potrebbe essere rimossa completamente o, se presente, impostata sulla lunghezza del corpo del contenuto compresso.
Transfer-Encoding 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 in chunk.

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 in uscita dalla cache o il trasferimento di dati in uscita su internet (rispettivamente) viene misurato in base ai byte compressi finali inviati al client.

Se gestisci 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 è attiva, la metrica https/response_bytes_count esistente nei report loadbalancing.googleapis.com indica le dimensioni della risposta compressa.

Puoi aspettarti una riduzione dei byte di risposta totali (e del throughput di trasferimento dei dati in uscita).

Se gestisci una grande quantità di contenuti basati su testo che vengono compressi bene, come HTML, CSS, JavaScript o JSON, potresti notare una riduzione significativa dei byte di risposta.

Per saperne di più, consulta Monitoring.

Passaggi successivi