Dynamische Komprimierung aktivieren

Bei der dynamischen Komprimierung werden Antworten, die von Cloud CDN bereitgestellt werden, automatisch komprimiert. Die Größe der über das Netzwerk gesendeten Daten wird in den typischen Fällen um 60 % bis 85 % reduziert.

So wird die Zeit für das Herunterladen von Inhalten reduziert. Bei wichtigen Assets wie Stylesheets (CSS), Skripts (JavaScript) und Videomanifesten (HLS/DASH) kann dies die Seitenladezeit und die Startzeiten von Videos reduzieren.

Weitere Informationen zu den Vorteilen der Komprimierung von Antworten finden Sie im Web Fundamentals-Leitfaden.

Sie können die Komprimierung für einen Backend-Dienst oder einen Backend-Bucket aktivieren.

Beispielanwendungsfälle

Die dynamische Komprimierung reduziert die Größe der vom Cloud CDN-Edge an den Client gesendeten Daten direkt. Das hat folgende Möglichkeiten:

  • Reduzieren Sie die Größe von CSS und JavaScript, damit Webseiten schneller gerendert werden, und reduzieren die Zeit für First Contentful Paint, einen wichtigen Messwert für die Webleistung.

  • Sie haben große, positive Auswirkungen beim Caching von REST API-Antworten, z. B. JSON-Nutzlasten. Diese Nutzlasten werden aufgrund der wiederkehrenden Schlüssel, Leerzeichen und geschweiften Klammern gut komprimiert. Das Caching öffentlicher APIs für 5–10 Sekunden ist ein beliebter Ansatz, um die Ursprungslast zu reduzieren und gleichzeitig die Aktualität der Daten zu gewährleisten.

    Selbst ohne Caching kann die Komprimierung dieser Antworten die Gesamtbyte reduzieren, die um bis zu 90 % gesendet werden.

  • Verbessern Sie die Startzeit der Wiedergabe für die Videobereitstellung und die Join-Latenz für das Livestreaming. Große Live-Genehmigungen (Manifeste) haben eine beträchtliche Menge an wiederkehrenden Daten, einschließlich des Host- + Pfadpräfixes der einzelnen Segmente sowie der HLS- oder DASH-Wiedergabemetadaten. Je schneller die Playlist geladen wird oder Aktualisierungen der Playlist heruntergeladen werden, desto weniger Zeit wartet ein Client auf das Parsen und das Herunterladen der referenzierten Videosegmente. Die HLS- und DASH-Listen werden häufig insgesamt um mehr als 90 % reduziert.

Hinweise

Du benötigst Folgendes:

  • Ein Cloud CDN-fähiges Back-End ist konfiguriert. Wenn Sie Cloud CDN noch nicht konfiguriert haben, können Sie einer der Einrichtungsanleitungen folgen.
  • Ihr Backend hat komprimierbare Inhalte, die bereitgestellt werden können, z. B. Web-Assets oder Videomanifeste zwischen 1 KiB und 10 MiB (einschließlich).
  • Clients müssen sich nicht darauf verlassen, dass sie mit Bereichsanfragen oder starken ETags Teilinhalte abrufen. Diese sind mit der dynamischen Komprimierung nicht kompatibel.
  • Clients können Antworten ohne Content-Length-Header verarbeiten. Cache-Fehler, die von Cloud CDN komprimiert werden, enthalten beispielsweise keine Content-Length-Header.
  • Die IAM-Rolle Administrator für Compute-Load-Balancer (roles/compute.loadBalancerAdmin), die erforderlich ist, um Änderungen an Ihrer Backend-Konfiguration vorzunehmen.

Komprimierung für einen Backend-Dienst oder -Bucket aktivieren

So aktivieren Sie die Komprimierung:

Console

Neuen Ursprung hinzufügen

Wenn du eine neue Quelle hinzufügen und einrichten möchtest, folge der Anleitung unter Einrichtung – Übersicht für den entsprechenden Back-End-Typ. Konfiguriere beim Erstellen des Ursprungs im Bereich Erweiterte Optionen die dynamische Komprimierung. Wähle dazu in der Liste Komprimierungsmodus die Option Automatisch aus.

Vorhandenen Ursprung bearbeiten

So bearbeiten Sie einen vorhandenen Cloud CDN-Ursprung:

  1. Rufen Sie in der Google Cloud Console die Seite Ursprünge von Cloud CDN auf.

    Zu „Herkunft“

  2. Klicken Sie auf den Namen des Ursprungs, den Sie bearbeiten möchten, und dann auf Bearbeiten.

  3. Klicken Sie im Bereich Ursprung-Grundlagen auf Weiter.

  4. Klicken Sie im Abschnitt Host- und Pfadregeln auf Weiter.

  5. Gehen Sie im Bereich Cache-Leistung zu Erweiterte Optionen.

  6. Wählen Sie in der Liste Komprimierungsmodus die Option Automatisch aus.

  7. Klicken Sie auf Fertig, um die Änderungen anzuwenden.

gcloud

Verwenden Sie für Back-End-Dienste den Befehl gcloud compute backend-services create oder gcloud compute backend-services update mit dem Flag --compression-mode.

Verwenden Sie für Back-End-Buckets den Befehl gcloud compute backend-buckets create oder gcloud compute backend-buckets update mit dem Flag --compression-mode.

Verwenden Sie für einen neuen Backend-Dienst den Befehl create:

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

Verwenden Sie für einen vorhandenen Backend-Dienst den Befehl update:

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

Verwenden Sie für einen neuen Backend-Bucket den Befehl create:

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

Verwenden Sie für einen vorhandenen Backend-Bucket den Befehl update:

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

Der Wert für compression-mode kann einer der folgenden sein:

  • AUTOMATIC: Verwendet automatisch die beste Komprimierung basierend auf dem vom Client gesendeten Header Accept-Encoding. In den meisten Fällen wird die Brotli-Komprimierung bevorzugt.
  • DISABLED (Standard): Komprimierung wird deaktiviert.

API

Verwenden Sie für Back-End-Dienste die Methode backendServices.insert oder die Methode backendServices.update.

Verwenden Sie für Back-End-Buckets die Methode backendBuckets.insert oder die Methode backendBuckets.update.

Verwenden Sie einen der folgenden Befehle:

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

Fügen Sie dem JSON-Anfragetext folgendes Snippet hinzu:

"compressionMode": AUTOMATIC

Der Wert für compression-mode kann einer der folgenden sein:

  • AUTOMATIC (empfohlen): Verwendet automatisch die beste Komprimierung basierend auf dem vom Client gesendeten Header Accept-Encoding. In den meisten Fällen wird die Brotli-Komprimierung bevorzugt.
  • DISABLED (Standard): Komprimierung wird deaktiviert.

Innerhalb weniger Minuten wird Ihre Konfiguration an alle Edge-Standorte verteilt. Komprimierbare Inhalte, die vom Backend bereitgestellt werden, werden komprimiert, bevor sie an den Client gesendet werden.

Komprimierungsmodi

Der Standardkomprimierungsmodus ist DISABLED.

Im AUTOMATIC-Modus kann Cloud CDN die beste Komprimierungsmethode anhand der folgenden Kriterien auswählen:

  • Die vom Client akzeptierte Codierung
  • Erwartetes Komprimierungsverhältnis der Antwort
  • Cloud CDN-Komprimierungsgeschwindigkeit (Durchsatz)

Brotli kann die Downloadgröße für die meisten Inhaltstypen im Vergleich zu Gzip um 10 bis 20 % reduzieren, bei ähnlicher Dekomprimierungsleistung, sodass es insgesamt schneller ist, wenn man die Downloadzeit und die Dekomprimierungsgeschwindigkeit auf dem Client berücksichtigt.

Cloud CDN gibt die ausgewählte Komprimierungsmethode im Content-Encoding-Header in der Antwort als gzip oder brotli an.

Cloud CDN bestimmt die Komprimierungsstufe, um die Gesamtgröße des Downloads und die CPU-Kosten auf dem Client auszugleichen. Höhere Komprimierungsstufen profitieren nicht immer von der Leistung, insbesondere auf Mobilgeräten mit geringerer Leistung.

Wenn Cloud CDN Inhalte zum ersten Mal komprimiert, wird der Content-Length-Header aus der Antwort entfernt. Dies ist erforderlich, damit die Antwort so schnell wie möglich bereitgestellt werden kann, da die vollständige Inhaltslänge erst bekannt ist, wenn die gesamte Antwort komprimiert wurde. Nachdem eine Antwort komprimiert und im Cache gespeichert wurde, fügt Cloud CDN den Header Content-Length möglicherweise in nachfolgende Antworten ein. Bei HTTP/1.1 und niedriger verwendet Cloud CDN Transfer-Encoding: chunked in der Antwort, wenn es Content-Length nicht verwendet.

Wann wird eine Antwort komprimiert?

Wenn eine Anfrage einen Accept-Encoding-Header enthält, in dem die Unterstützung für den GZIP- oder Brotli-Algorithmus explizit aufgeführt ist, werden unkomprimierte Antworten, die vom Backend (Ursprung) mit einem Content-Type-Header bereitgestellt werden, der mit den komprimierbaren Inhaltstypen übereinstimmt, entsprechend mit GZIP oder Brotli komprimiert. Wenn eine Anfrage keinen Accept-Encoding-Header oder Accept-Encoding: * enthält, wird die Antwort nicht komprimiert.

Wenn in einer Clientanfrage beispielsweise ein Accept-Encoding-Header vorhanden ist, wird die Antwort gemäß den Informationen in der folgenden Tabelle komprimiert (oder nicht):

Anfrageheader Accept-Encoding Antwortcodierung
gzip, compress, br Brotli (br)
deflate Nicht komprimiert
deflate, gzip GZIP
identity Nicht komprimiert
* Nicht komprimiert

Komprimierbare Inhaltstypen

Die dynamische Komprimierung gilt für die folgenden MIME-Typen, die auf dem HTTP-Antwortheader Content-Type basieren. Antworten ohne Content-Type-Antwortheader werden nicht komprimiert.

Zu den gängigen Inhaltstypen und ihren MIME-Typen gehören:

  • HTML-Inhalt: text/html
  • Stylesheets: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • HLS-Playlisten: application/x-mpegURL oder application/vnd.apple.mpegURL
  • DASH-Manifeste: application/dash+xml

In der folgenden Tabelle ist zusammengefasst, wie sich der MIME-Typ auf die Komprimierung auswirkt.

  Komprimierbare MIME-Typen
Genaue Übereinstimmung 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
Schemaabgleich application/*+json
application/*+xml
application/*mpegURL
text/*

Bild- und Videoformate (z. B. image/jpeg, image/png und video/mpeg4) sind fast immer komprimiert, sodass sie von Cloud CDN nicht komprimiert werden. Durch die erneute Kompression einer bereits komprimierten Antwort wird die Dateigröße selten reduziert. Außerdem können Clients ein unerwartetes Verhalten aufweisen, wenn sie eine Antwort dieser Art erhalten.

Wann wird eine Antwort nicht komprimiert?

Die dynamische Komprimierung komprimiert eine Antwort nicht, wenn die Antwort eine oder mehrere der folgenden Eigenschaften aufweist:

  • Die Antwort enthält keinen Content-Type-Header, der einem komprimierbaren Inhaltstyp entspricht.
  • Sie hat keinen Content-Length-Header.
  • Sie hat einen Content-Encoding-Header.

  • Sie ist kleiner als 1 KiB.

    Die Zeit, die für das Komprimieren und Dekomprimieren aufgewendet wird, verschiebt häufig alle Vorteile. Außerdem gibt es weniger Inhalte, die komprimiert werden können, wodurch die Effektivität der Komprimierung reduziert werden kann und ein niedrigeres Komprimierungsverhältnis sein kann.

  • Sie ist größer als 10 MiB.

  • Sie hat einen Cache-Control: no-transform-Header.

  • Sie hat einen Vary: Accept-Encoding-Header.

Bereichsanfragen

Wenn Cloud CDN eine Antwort komprimiert, fügt es einen Accept-Ranges: none-Header hinzu und ersetzt alle vorhandenen Accept-Ranges-Header. Bei Cachetreffern für solche Antworten werden Range-Header ignoriert.

Dadurch wird verhindert, dass den Clients falsche Teilinhalte bereitgestellt werden, da nicht sicher sein kann, ob ein Client einen Bytebereich von der komprimierten oder unkomprimierten Form einer Ressource erwartet.

ETags

Wenn die dynamische Komprimierung eine Antwort komprimiert, werden alle starken ETag-Header gemäß RFC 7232, Abschnitt 2.3 schwächen. Beispiel: ETag: "xyzzy" wird durch ETag: W/"xyzzy" ersetzt.

Vary-Header

Wenn eine Antwort bereitgestellt wird, die (abhängig von der Anfrage) komprimiert werden könnte, fügt Cloud CDN der Antwort den Header Vary: Accept-Encoding hinzu.

Zusammenfassung der Antwortänderungen

In der folgenden Tabelle sind die Änderungen zusammengefasst, die Cloud CDN an den Headern einer Antwort vornimmt, wenn eine Komprimierung erfolgt ist:

Antwortheader Headerwert nach Komprimierung
Inhaltscodierung Legen Sie gzip oder brotli fest.
ETag Alle starken Entitäts-Tags werden durch eine abgeschwächte Version ersetzt, die durch das Präfix W/ gekennzeichnet ist.
Accept-Ranges Legen Sie den Wert auf kein fest.
Content-Length Kann vollständig entfernt werden oder, falls vorhanden, auf die Länge des komprimierten Textkörpers gesetzt werden.
Transfer-Encoding Wenn Cloud CDN bei HTTP/1.1 und älteren Protokollen Content-Length entfernt, fügt es diesen Header mit dem Wert chunked hinzu und bricht den Antworttext in Chunks auf.

Logging

Die Cloud CDN-Logs enthalten das Feld compressionStatus in jsonPayload, das angibt, ob die Antwort vom Load Balancer komprimiert wurde sowie den Komprimierungstyp.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

Abrechnung

Wenn eine Antwort von Cloud CDN oder Cloud Load Balancing komprimiert wird, wird die entsprechende ausgehende Cache-Datenübertragung bzw. ausgehende Internet-Datenübertragung anhand der endgültigen komprimierten Byte gemessen, die an den Client gesendet werden.

Wenn Sie eine große Menge komprimierbarer Antworten bereitstellen, kann dies zu einer Reduzierung der monatlichen Gebühren für ausgehende Datenübertragungen sowie zu einer höheren Leistung für Endnutzer führen.

Messwerte

Wenn die Komprimierung aktiviert ist, meldet der vorhandene https/response_bytes_count-Messwert unter loadbalancing.googleapis.com die komprimierte Antwortgröße.

Sie sollten einen Rückgang der Gesamtantwortbyte und des ausgehenden Datenübertragungsdurchsatzes erwarten.

Wenn Sie eine große Menge an textbasierten Inhalten bereitstellen, die gut komprimiert sind, z. B. HTML, CSS, JavaScript oder JSON, kann es zu einem starken Rückgang der Antwortbyte kommen.

Weitere Informationen finden Sie unter Monitoring.

Nächste Schritte