Attiva la 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 Cloud CDN perimetrale al client. Con questa operazione puoi eseguire direttamente le seguenti operazioni:

  • 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 grande impatto positivo quando memorizzano nella cache le risposte dell'API REST, ad esempio Payload JSON. Questi payload si comprimono bene a causa dei tasti ripetuti, spazi vuoti e parentesi graffe. La memorizzazione nella cache delle API pubbliche per 5-10 secondi è per ridurre il carico dell'origine mantenendo l'aggiornamento dei dati.

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

  • Migliora l'ora di inizio della riproduzione per la distribuzione dei video e la latenza di join per in live streaming. 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 abilitato per Cloud CDN configurato. Se non hai configurato Cloud CDN, puoi seguire una delle guide alla configurazione.
  • Nel backend sono pronti contenuti comprimibili per la pubblicazione, ad esempio asset web o manifest video compresi tra 1 KiB e 10 MiB (incluso).
  • I client non si basano sul recupero di contenuti parziali con richieste di intervallo o con ETag forti. Si tratta di incompatibili con la compressione dinamica.
  • I client possono gestire le risposte senza Content-Length intestazioni. Ad esempio, gli errori della cache che Cloud CDN esegue non hanno intestazioni Content-Length.
  • IAM Ruolo Amministratore bilanciatore del carico Compute (roles/compute.loadBalancerAdmin), necessario per apportare modifiche alla configurazione del backend.

Attivare la compressione su un servizio 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 riportate nella Panoramica della configurazione per il tipo di backend appropriato. Quando crei l'origine, usa la sezione Opzioni avanzate per configurare Compressione dinamica selezionando Automatica in Modalità di compressione dall'elenco di lettura.

Modificare un'origine esistente

Per modificare un'origine Cloud CDN esistente:

  1. Nella console Google Cloud, vai alla pagina Origins 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 sull'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ò essere uno dei seguenti:

  • AUTOMATIC: utilizza automaticamente la compressione migliore in base all'intestazione Accept-Encoding inviata dal client. Nella maggior parte dei casi, ciò determina la preferenza della compressione Brotli.
  • DISABLED (impostazione predefinita): disattiva la compressione.

API

Per i servizi di backend, utilizza backendServices.insert o il metodo 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, in questo modo viene favorita la compressione Brotli.
  • DISABLED (impostazione predefinita): disattiva la compressione.

Entro pochi minuti, la configurazione viene propagata a tutte le località edge. I contenuti comprimibili forniti dal backend vengono compressi prima di essere disponibili al cliente.

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 (velocità effettiva) di Cloud CDN

Brotli può produrre dal 10% al 20% in più di riduzione delle dimensioni di download per la maggior parte dei tipi di contenuti su gzip, con simili prestazioni di decompressione, rendendole più veloci nel complesso se si considera il download il tempo 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 da bilanciare dimensioni totali di download e 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 Content-Length della risposta; Ciò è necessario per consentire la risposta venga fornita il più rapidamente possibile perché l'intero contenuto la lunghezza non è nota fino a quando 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 ha un'intestazione Accept-Encoding che elenca esplicitamente il supporto per in formato gzip o Brotli, quindi le risposte non compresse fornite dal backend (origin) con un'intestazione Content-Type che corrisponde i tipi di contenuti comprimibili vengono compressi con gzip o Brotli, di conseguenza. Se una richiesta non ha un'intestazione Accept-Encoding o se ha Accept-Encoding: *, la risposta non viene compressa.

Ad esempio, data un'intestazione Accept-Encoding in una richiesta del client, la risposta sia compresso (o meno) in base alle informazioni nella seguente tabella:

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 ai Intestazione della risposta HTTP Content-Type. Le risposte che non hanno un'Content-Type intestazione di risposta 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 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 schema application/*+json
application/*+xml
application/*mpegURL
testo/*

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 clienti potrebbero presentare un comportamento inaspettato quando ricevono una risposta gentile.

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 corrispondente a un tipo di contenuto comprimibile.
  • Non è presente 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. Ci sono anche meno contenuti da comprimere, il che può ridurre l'efficacia di compressione e ridurre il rapporto di compressione.

  • È 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 elemento Accept-Ranges esistente intestazioni. Le hit della cache per queste risposte ignorano le intestazioni Range.

In questo modo si impedisce la pubblicazione per i client di contenuti parziali non corretti, in quanto non sono per essere sicuro se un client si aspetta un intervallo di byte dalla non compressa di una risorsa.

ETag

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 si fornisce una risposta che potrebbe essere compressa (a seconda automaticamente la richiesta), Cloud CDN aggiunge l'intestazione Vary: Accept-Encoding la risposta corretta.

Riepilogo delle modifiche alle risposte

La tabella seguente riassume le modifiche apportate da Cloud CDN a intestazioni di una risposta quando si è verificata la compressione:

Intestazione della risposta Valore intestazione dopo la compressione
Codifica dei contenuti 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 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 divide il corpo della risposta in blocchi.

Logging

I log di Cloud CDN includono un campo compressionStatus nella jsonPayload che indica se la risposta è stata compressa dal 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 pertinente dalla cache in uscita o il trasferimento di dati internet in uscita (rispettivamente) viene misurato in base ai byte compressi finali inviati al client.

Se stai pubblicando un numero elevato di risposte comprimibili, questo può di una riduzione delle tariffe mensili per il trasferimento di dati in uscita e di un aumento il rendimento per gli utenti finali.

Metriche

Se la compressione è abilitata, 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 grandi quantità di contenuti di testo che si comprimeno bene, ad esempio HTML, CSS, JavaScript o JSON, potresti notare un calo significativo byte.

Per ulteriori informazioni, consulta la sezione Monitoraggio.

Passaggi successivi