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 verringert. Bei wichtigen Assets wie Stylesheets (CSS), Scripts (JavaScript) und Videomanifesten (HLS/DASH) kann dies die Seitenladezeit und die Startzeiten von Videos verkürzen.

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. Dies kann zu Folgendem führen:

• Reduzierung der Größe von CSS und JavaScript, sodass Webseiten schneller gerendert werden und die Zeit für First Contentful Paint, einen wichtigen Messwert für die Webleistung, verkürzt wird.

• Großen, positiven Auswirkungen beim Caching von REST API-Antworten, z. B. JSON-Nutzlasten. Diese Nutzlasten lassen sich aufgrund der wiederkehrenden Schlüssel, Leerzeichen und geschweiften Klammern gut komprimieren. 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 insgesamt gesendeten Byte um bis zu 90 % verringern.

• Verbesserung der Startzeit der Wiedergabe bei der Videobereitstellung sowie der Join-Latenz beim Livestreaming. Große Liveplaylists (Manifeste) haben eine beträchtliche Menge an wiederkehrenden Daten, einschließlich des Präfixes aus Host + Pfad für jedes einzelne Segment sowie der HLS- oder DASH-Playlistmetadaten. Je schneller die Playlist geladen wird oder Aktualisierungen der Playlist heruntergeladen werden können, desto weniger lange wartet ein Client mit dem Parsen und dem Herunterladen der referenzierten Videosegmente. Die Größe der HLS- und DASH-Playlists wird häufig insgesamt um mehr als 90 % reduziert.

Hinweis

Folgende Voraussetzungen müssen erfüllt sein:

• Ein Cloud CDN-fähiges Backend ist konfiguriert. Wenn Sie Cloud CDN 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 verlassen sich nicht darauf, mit Bereichsanfragen oder starken ETags Teilinhalte abzurufen. Diese sind mit der dynamischen Komprimierung nicht kompatibel.
• Clients können Antworten ohne Content-Length-Header verarbeiten. Antworten, die von Cloud CDN bei Cache-Fehlern komprimiert werden, haben beispielsweise keine Content-Length-Header.
• Sie haben 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

Im Folgenden wird beschrieben, wie Sie die Komprimierung aktivieren.

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

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

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

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

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

"compressionMode": AUTOMATIC

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:

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

Brotli kann die Downloadgröße für die meisten Inhaltstypen bei ähnlicher Dekomprimierungsleistung im Vergleich zu gzip um 10 bis 20 % reduzieren. Dadurch ist es insgesamt schneller, 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 auszubalancieren. Höhere Komprimierungsstufen wirken sich nicht immer positiv auf die Leistung aus, insbesondere auf Mobilgeräten mit geringerer Leistung.

Wenn Cloud CDN beginnt, Inhalte zu komprimieren, 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, kann Cloud CDN den Content-Length-Header in nachfolgende Antworten einfügen. Bei HTTP/1.1 und früheren Versionen verwendet Cloud CDN Transfer-Encoding: chunked in der Antwort, wenn Content-Length nicht verwendet wird.

Wann wird eine Antwort komprimiert?

Wenn eine Anfrage einen Accept-Encoding-Header enthält, in dem die Unterstützung für gzip- oder Brotli-Algorithmen explizit aufgeführt ist, werden nicht komprimierte 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 enthält oder wenn sie Accept-Encoding: * enthält, wird die Antwort nicht komprimiert.

Beim Accept-Encoding-Header in einer Clientanfrage wird die Antwort beispielsweise gemäß den Informationen in der folgenden Tabelle komprimiert (bzw. nicht komprimiert).

Komprimierbare Inhaltstypen

Die dynamische Komprimierung gilt für die folgenden MIME-Typen, basierend auf dem Content-Type-HTTP-Antwortheader. 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-Playlists: 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.

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 zeigen, 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 hat 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, hebt häufig alle Vorteile auf. Außerdem gibt es weniger Inhalte, die komprimiert werden können, wodurch die Effektivität der Komprimierung reduziert werden kann, was zu einem niedrigeren Komprimierungsverhältnis führt.

• 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 Cache-Treffern für solche Antworten werden Range-Header ignoriert.

Dadurch wird verhindert, dass für die Clients falsche Teilinhalte bereitgestellt werden, da unklar ist, 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 abgeschwächt. 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 Vary: Accept-Encoding-Header 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:

Logging

Die Cloud CDN-Logs enthalten das Feld compressionStatus in jsonPayload, das angibt, ob die Antwort vom Load Balancer komprimiert wurde und welcher Komprimierungstyp ggf. verwendet wurde.

{
  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 ausgehende Cache-Datenübertragung bzw. die 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 Größe der komprimierten Antwort.

Sie sollten einen Rückgang der Gesamtantwortbyte und des Durchsatzes der ausgehenden Datenübertragung feststellen.

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

• Informationen dazu, wie Cache-Modi das Speichern von Inhalten im Cache erleichtern, finden Sie unter Cache-Modi ändern.
• Informationen zum Aktivieren von Cloud CDN für Ihre HTTP(S)-Instanz mit Load Balancing und ihre Storage-Buckets finden Sie unter Einrichtung: Übersicht.
• Weitere Informationen zum Entwerten von Caches finden Sie unter Übersicht zur Cache-Entwertung.
• Informationen zu GFE-Points-of-Presence finden Sie unter Cache-Speicherorte.