Bei der dynamischen Komprimierung werden die von Cloud CDN bereitgestellten Antworten 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
Sie benötigen Folgendes:
- Ein konfiguriertes Cloud CDN-fähiges Backend. Wenn du hast nicht Cloud CDN derzeit konfiguriert ist, können Sie einer der Einrichtungsleitfäden.
- Ihr Backend hat komprimierbare Inhalte, die bereitgestellt werden können, z. B. Web-Assets oder Videomanifeste zwischen 1 KiB und 10 MiB (einschließlich).
- Kunden verlassen sich nicht darauf, Teilinhalte mit Bereichsanfragen oder mit starken ETags verwenden. Diese sind mit der dynamischen Komprimierung nicht kompatibel.
- Clients können Antworten ohne
Content-Length
verarbeiten headers. Beispiele für Cache-Fehler, die von Cloud CDN komprimiert werden hat keineContent-Length
-Header. - Das IAM
Rolle „Administrator für Compute-Load-Balancer“
(
roles/compute.loadBalancerAdmin
), was erforderlich ist, um Änderungen an Ihrer Back-End-Konfiguration vorzunehmen.
Komprimierung für einen Backend-Dienst oder -Bucket aktivieren
So aktivieren Sie die Komprimierung:
Console
Neuen Ursprung hinzufügen
Folgen Sie zum Hinzufügen und Einrichten eines neuen Ursprungs den Anweisungen unter Übersicht zur Einrichtung für den passenden Back-End-Typ Nutzen Sie beim Erstellen des Ursprungs den Abschnitt Erweiterte Optionen, um dynamische Komprimierung, indem Sie im Komprimierungsmodus die Option Automatisch auswählen Liste.
Vorhandenen Ursprung bearbeiten
So bearbeiten Sie einen vorhandenen Cloud CDN-Ursprung:
Rufen Sie in der Google Cloud Console die Cloud CDN-Ursprünge auf. Seite.
Klicken Sie auf den Namen des Ursprungs, den Sie bearbeiten möchten, und dann auf Bearbeiten.
Klicken Sie im Abschnitt Origin-Grundlagen auf Weiter.
Klicken Sie im Abschnitt Host- und Pfadregeln auf Weiter.
Gehen Sie im Abschnitt Cache-Leistung zu Erweiterte Optionen.
Wählen Sie in der Liste Komprimierungsmodus die Option Automatisch aus.
Klicken Sie auf Fertig, um die Änderungen zu übernehmen.
gcloud
Verwenden Sie für Back-End-Dienste den Befehl gcloud compute backend-services
create
oder
gcloud compute backend-services
update
-Befehl
mit dem Flag --compression-mode
.
Verwenden Sie für Back-End-Buckets den Befehl gcloud compute backend-buckets create
.
oder den Befehl 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 HeaderAccept-Encoding
. In den meisten Fällen wird die Brotli-Komprimierung bevorzugt.DISABLED
(Standard): Komprimierung wird deaktiviert.
API
Verwenden Sie für Backend-Dienste die Methode
backendServices.insert
-Methode oder die
backendServices.update
-Methode.
Verwenden Sie für Backend-Buckets die Methode
backendBuckets.insert
-Methode oder die
backendBuckets.update
-Methode.
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 HeaderAccept-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)
Mit Brotli lassen sich noch 10 bis 20 % mehr Umsatz erzielen. die geringere Downloadgröße für die meisten Inhaltstypen über gzip, Dekomprimierungsleistung. Das macht es insgesamt schneller, Zeit und Dekomprimierungsgeschwindigkeit auf dem Client.
Cloud CDN gibt die ausgewählte Komprimierungsmethode folgendermaßen an:
gzip
oder brotli
im Content-Encoding
-Header der Antwort.
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.
Bei der ersten Komprimierung von Inhalten durch Cloud CDN werden die
Content-Length
-Header aus der Antwort; Das ist notwendig, um
dass die Antwort so schnell wie möglich bereitgestellt wird,
Länge ist unbekannt, bis die gesamte Antwort komprimiert wurde.
Nachdem eine Antwort komprimiert und im Cache gespeichert wurde, kann Cloud CDN
Fügen Sie den Content-Length
-Header in nachfolgenden Antworten ein.
(Bei HTTP/1.1 und früheren Versionen verwendet Cloud CDN in der Antwort Transfer-Encoding:
chunked
, wenn Content-Length
nicht verwendet wird.)
Wann wird eine Antwort komprimiert?
Wenn eine Anfrage einen Accept-Encoding
-Header hat, in dem explizit die Unterstützung für
den gzip- oder den Brotli-Algorithmus, dann werden unkomprimierte Antworten vom
Back-End (Ursprung) mit einem Content-Type
-Header, der dem
komprimierbare Inhaltstypen werden mit gzip komprimiert oder
Brotli entsprechend. Wenn eine Anfrage keinen Accept-Encoding
-Header hat oder
Accept-Encoding: *
, wird die Antwort nicht komprimiert.
Beispiel: Bei einem Accept-Encoding
-Header in einer Clientanfrage lautet die Antwort
gemäß den Informationen in der folgenden Tabelle komprimiert ist (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
oderapplication/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 Anwendung/XML Anwendung/CSV application/json application/json+protobuf application/signed-exchange application/vnd.apple.mpegurl Anwendung/Wasm application/x-plist application/x-protobuffer application/x-protobuf application/x-nacl application/x-pnacl Schriftart/TTF Schriftart/OTF Schriftart/Eote Bild/svg+xml Bild/pwg-Raster Bild/X-Symbol image/vnd.microsoft.icon video/vnd.mpeg.dash.mpd Audio/MPEG-URL application/dash+xml application/vnd.ms-sstr+xml |
Schemaabgleich | Anwendung/*+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 hat keinen
Content-Type
-Header, der mit einem komprimierbarer Inhaltstyp. - 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 müssen weniger Inhalte komprimiert werden, was die Effektivität beeinträchtigen kann. und führen zu einem niedrigeren Verdichtungsverhältnis.
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 einen Accept-Ranges: none
-Header hinzu und ersetzt vorhandene Accept-Ranges
-Elemente
headers. Cache-Treffer für solche Antworten ignorieren Range
-Header.
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 den Header einer Antwort bei der Komprimierung:
Antwortheader | Header-Wert nach der Komprimierung |
---|---|
Inhaltscodierung | Legen Sie gzip oder brotli fest. |
ETag | Jedes starke Entitäts-Tag wird durch eine abgeschwächte Version ersetzt, W/. |
Akzeptanzbereiche | Legen Sie dafür den Wert none fest. |
Inhaltslänge | Kann vollständig entfernt werden oder, falls vorhanden, auf die Länge festgelegt des komprimierten Textinhalts. |
Transferverschlüsselung | Wenn Cloud CDN bei HTTP/1.1 und älteren Protokollen Content-Length ist, wird dieser Header mit folgendem Wert hinzugefügt: chunked und teilt den Text der Antwort. |
Logging
Die Cloud CDN-Logs enthalten das Feld compressionStatus
im
jsonPayload
, der angibt, ob die Antwort durch den Ladevorgang komprimiert wurde
und die Komprimierungsart.
{ 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 durch Cloud CDN oder Cloud Load Balancing komprimiert wird, die relevante ausgehende Cache-Datenübertragung oder die ausgehende Internet-Datenübertragung werden mit den endgültigen komprimierten Bytes verglichen, die an den Client gesendet wurden.
Wenn Sie eine große Anzahl komprimierbarer Antworten bereitstellen, kann dies zu reduzierte Ihre monatlichen Gebühren für ausgehende Datenübertragungen sowie die für die Endanwendenden.
Messwerte
Wenn die Komprimierung aktiviert ist, meldet der vorhandene https/response_bytes_count
-Messwert unter loadbalancing.googleapis.com
die komprimierte Antwortgröße.
Es ist ein Rückgang bei der Gesamtzahl der Antwortbyte (und der ausgehenden Datenübertragung) zu erwarten. Durchsatz).
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
- So aktivieren Sie Cloud CDN für Ihre HTTP(S)-Instanzen mit Load-Balancing und Storage-Buckets finden Sie unter Übersicht über die Einrichtung.
- Weitere Informationen zum Entwerten von Caches finden Sie unter Übersicht zur Cache-Entwertung.
- Informationen zu GFE-Points-of-Presence finden Sie unter Cache-Speicherorte.