Bereitstellen von komprimierten Dateien

Wenn angeforderte Objekte komprimiert werden, können Downloads schneller sein, da die Objekte kleiner sind – in einigen Fällen weniger als ein Viertel der Größe des Originals. Schnellere Downloads können zum schnelleren Rendern von Webseiten für Ihre Viewer führen, insbesondere bei JavaScript- und CSS-Dateien. Darüber hinaus basieren die Kosten für CloudFront-Datenübertragungen auf dem Gesamtvolumen der bereitgestellten Daten. Die Bereitstellung komprimierter Objekte kann kostengünstiger sein als die Bereitstellung unkomprimierter Objekte.

Konfigurieren von CloudFront zur Komprimierung von Objekten

Um CloudFront zum Komprimieren von Objekten zu konfigurieren, aktualisieren Sie das Cacheverhalten, das Sie den komprimierten Objekten bereitstellen möchten.

So konfigurieren Sie CloudFront für die Komprimierung von Objekten (Konsole)

1. Melden Sie sich bei der CloudFront-Konsole an.

2. Wählen Sie Ihre Distribution und dann das zu bearbeitende Verhalten aus.

3. Setzen Sie Objekte automatisch komprimieren auf Ja.

4. Verwenden Sie eine Cache-Richtlinie, um Cache-Einstellungen anzugeben, und aktivieren Sie die Komprimierungsformate Gzip und Brotli.

Hinweise

• Für die Brotli-Komprimierung müssen Sie Cache-Richtlinien verwenden. Brotli unterstützt keine Legacy-Cache-Einstellungen.

• Um die Komprimierung mithilfe der CloudFormation oder der CloudFront-API zu aktivieren, setzen Sie die Parameter Compress, EnableAcceptEncodingGzip und EnableAcceptEncodingBrotli auf true.

Wie CloudFront Objekte komprimiert, wird im folgenden Abschnitt geschildert.

Funktionsweise von CloudFront-Kompression

1. Ein Viewer fordert ein Objekt an. Der Viewer fügt den HTTP-Header Accept-Encoding in die Anforderung ein. Die Header-Werte fügen gzip, br oder beides ein. Dadurch wird angezeigt, dass der Viewer komprimierte Objekte unterstützt. Wenn der Viewer sowohl Gzip als auch Brotli unterstützt, verwendet CloudFront Brotli.

   Anmerkung

   Die Webbrowser Chrome und Firefox unterstützen die Brotli-Komprimierung nur, wenn die Anforderung über HTTPS gesendet wird. Sie unterstützen Brotli für HTTP-Anforderungen nicht.

2. CloudFront prüft am Edge-Standort den Cache auf eine komprimierte Kopie des angeforderten Objekts.

3. Je nachdem, ob sich das komprimierte Objekt im Cache befindet oder nicht, führt CloudFront eine der folgenden Aktionen aus:

   • Wenn sich das komprimierte Objekt bereits im Cache befindet, sendet CloudFront es an den Viewer und überspringt die verbleibenden Schritte.

   • Wenn sich das komprimierte Objekt nicht im Cache befindet, leitet CloudFront die Anforderung an den Ursprung weiter.

   Anmerkung

   Wenn sich bereits eine unkomprimierte Kopie des Objekts im Cache befindet, sendet CloudFront sie möglicherweise an den Viewer, ohne die Anforderung an den Ursprung weiterzuleiten. Dies kann beispielsweise passieren, wenn CloudFront die Komprimierung zuvor übersprungen hat. In diesem Fall speichert CloudFront das unkomprimierte Objekt im Cache und stellt es weiter bereit, bis das Objekt abläuft, entfernt wird oder ungültig wird.

4. Wenn der Ursprung ein komprimiertes Objekt zurückgibt (wie durch den Content-Encoding-Header in der HTTP-Antwort angezeigt), sendet CloudFront das komprimierte Objekt an den Viewer, fügt es dem Cache hinzu und überspringt die verbleibenden Schritte. CloudFront komprimiert das Objekt nicht erneut.

5. Wenn der Ursprung ein unkomprimiertes Objekt ohne den Content-Encoding-Header in der HTTP-Antwort an CloudFront zurückgibt, bestimmt CloudFront, ob das Objekt komprimierbar ist. Weitere Informationen finden Sie unter Bedingungen für die Komprimierung.

6. Wenn das Objekt komprimiert werden kann, komprimiert CloudFront es, sendet es an den Viewer und fügt es dem Cache hinzu.

7. Bei nachfolgenden Viewer-Anforderungen für dasselbe Objekt gibt CloudFront die erste zwischengespeicherte Version zurück. Wenn ein Viewer beispielsweise ein bestimmtes zwischengespeichertes Objekt anfordert, das Gzip-Komprimierung verwendet, und der Viewer das Gzip-Format akzeptiert, geben nachfolgende Anforderungen an dasselbe Objekt immer die Gzip-Version zurück, auch wenn der Viewer sowohl Brotli als auch Gzip akzeptiert.

Einige benutzerdefinierte Ursprünge können auch Objekte komprimieren. Ihr Ursprung kann möglicherweise Objekte komprimieren, die CloudFront nicht komprimiert. Weitere Informationen finden Sie unter Dateitypen, die von CloudFront komprimiert werden.

Bedingungen für die Komprimierung

Die folgende Liste enthält weitere Informationen zu Szenarien, in denen CloudFront Objekte nicht komprimiert.

Anforderung verwendet HTTP 1.0

Wenn eine Anforderung an CloudFront HTTP 1.0 verwendet, entfernt CloudFront den Accept-Encoding-Header und komprimiert das Objekt in der Antwort nicht.

Accept-Encoding-Header der Anforderung

Wenn der Accept-Encoding-Header in der Viewer-Anforderung fehlt oder gzip oder br nicht als Wert enthält, komprimiert CloudFront das Objekt in der Antwort nicht. Wenn der Accept-Encoding-Header zusätzliche Werte wie deflate enthält, entfernt CloudFront diese vor dem Weiterleiten der Anforderung an den Ursprung.

Wenn CloudFront für die Komprimierung von Objekten konfiguriert ist, schließt es den Accept-Encoding-Header automatisch in den Cache-Schlüssel und in Ursprungsanforderungen ein.

Inhalte werden bereits zwischengespeichert, wenn Sie CloudFront so konfigurieren, dass Objekte komprimiert werden

CloudFront komprimiert Objekte, wenn sie vom Ursprung abgerufen werden. Wenn Sie CloudFront zum Komprimieren von Objekten konfigurieren, komprimiert CloudFront keine Objekte, die bereits an Edge-Standorten zwischengespeichert wurden. Wenn ein zwischengespeichertes Objekt an einem Edge-Standort abläuft und CloudFront eine weitere Anforderung für das Objekt an Ihren Ursprung weiterleitet, komprimiert CloudFront das Objekt nicht, wenn Ihr Ursprung den HTTP-Statuscode 304 zurückgibt. Das bedeutet, dass Edge-Standort bereits über die neueste Version des Objekts verfügt. Wenn Sie möchten, dass CloudFront die Objekte komprimiert, die an Edge-Standorten bereits zwischengespeichert sind, müssen Sie diese Objekte invalidieren. Weitere Informationen finden Sie unter Aufheben der Gültigkeit von Dateien zum Entfernen von Inhalten.

Ursprung ist bereits für die Kompression von Objekten konfiguriert

Wenn Sie CloudFront für die Komprimierung von Objekten konfigurieren und der Ursprung Objekte ebenfalls komprimiert, enthält der Ursprung den Header Content-Encoding. Dieser Header zeigt CloudFront an, dass das Objekt bereits komprimiert ist. Wenn eine Antwort von einem Ursprung den Header Content-Encoding enthält, komprimiert CloudFront das Objekt nicht, unabhängig vom Wert des Headers. CloudFront sendet die Antwort an den Viewer und speichert das Objekt im Cache des Edge-Standorts.

Dateitypen, die von CloudFront komprimiert werden

Eine vollständige Liste finden Sie hier: Dateitypen, die von CloudFront komprimiert werden.

Größe der Objekte, die CloudFront komprimiert

CloudFront kann Objekte komprimieren, die zwischen 1 000 Byte und 10 000 000 Byte groß sind.

Content-Length-Header

Der Ursprung muss in der Antwort einen Content-Length-Header enthalten, mit dem CloudFront bestimmt, ob die Größe des Objekts in dem von CloudFront komprimierten Bereich liegt. Wenn der Header Content-Length fehlt, einen ungültigen Wert oder einen Wert außerhalb des von CloudFront komprimierten Größenbereichs enthält, komprimiert CloudFront das Objekt nicht. Weitere Informationen darüber, wie CloudFront große Objekte verarbeitet, die eventuell den Größenbereich überschreiten, finden Sie unter Wie CloudFront werden Teilanfragen für ein Objekt (BereichGETs) verarbeitet.

Den HTTP-Statuscode der Antwort.

CloudFront komprimiert Objekte nur, wenn der HTTP-Statuscode der Antwort 200, 403 oder 404 ist.

Antwort hat keinen Körper

Wenn die HTTP-Antwort vom Ursprung keinen Text enthält, gibt es nichts für CloudFront zu komprimieren.

ETag-Header

CloudFront ändert manchmal den ETag-Header in der HTTP-Antwort, wenn Objekte komprimiert werden. Weitere Informationen finden Sie unter ETag-Header-Konvertierung.

CloudFront überspringt die Komprimierung

CloudFront komprimiert Objekte nach bestmöglichem Bemühen. In seltenen Fällen überspringt CloudFront die Komprimierung eines Objekts, wenn CloudFront eine hohe Verkehrslast aufweist. CloudFront trifft diese Entscheidung auf der Grundlage einer Vielzahl von Faktoren, einschließlich der Host-Kapazität. Wenn CloudFront die Komprimierung für ein Objekt überspringt, speichert es das unkomprimierte Objekt zwischen und stellt es weiter für Viewer bereit, bis das Objekt abläuft, entfernt oder ungültig gemacht wird.

Dateitypen, die von CloudFront komprimiert werden

Wenn Sie CloudFront zum Komprimieren von Objekten konfigurieren, komprimiert CloudFront nur Objekte, die einen der folgenden Werte im Content-Type-Antwortheader aufweisen:

• application/dash+xml

• application/eot

• application/font

• application/font-sfnt

• application/javascript

• application/json

• application/opentype

• application/otf

• application/pdf

• application/pkcs7-mime

• application/protobuf

• application/rss+xml

• application/truetype

• application/ttf

• application/vnd.apple.mpegurl

• application/vnd.mapbox-vector-tile

• application/vnd.ms-fontobject

• application/wasm

• application/xhtml+xml

• application/xml

• application/x-font-opentype

• application/x-font-truetype

• application/x-font-ttf

• application/x-httpd-cgi

• application/x-javascript

• application/x-mpegurl

• application/x-opentype

• application/x-otf

• application/x-perl

• application/x-ttf

• font/eot

• font/opentype

• font/otf

• font/ttf

• image/svg+xml

• text/css

• text/csv

• text/html

• text/javascript

• text/js

• text/plain

• text/richtext

• text/tab-separated-values

• text/xml

• text/x-component

• text/x-java-source

• text/x-script

• vnd.apple.mpegurl

Mehr anzeigenWeniger anzeigen

ETag-Header-Konvertierung

Wenn das unkomprimierte Objekt vom Ursprung einen gültigen, starken ETag-HTTP-Header enthält und CloudFront das Objekt komprimiert, konvertiert CloudFront auch den starken ETag-Header-Wert in einen schwachen ETag und gibt den schwachen Wert ETag an den Viewer zurück. Viewer können den schwachen ETag-Wert speichern und ihn verwenden, um bedingte Anforderungen mit dem HTTP-Header If-None-Match zu senden. So können Viewer, CloudFront und der Ursprung die komprimierten und unkomprimierten Versionen eines Objekts als semantisch äquivalent behandeln, wodurch unnötige Datenübertragungen reduziert werden.

Ein gültiger, starker ETag-Headerwert beginnt und endet mit einem doppelten Anführungszeichen ("). Um den starken ETag-Wert in einen schwachen Wert zu konvertieren, fügt CloudFront die Zeichen W/ am Anfang des starken ETag-Werts hinzu.

Wenn das Objekt aus dem Ursprung einen schwachen ETag-Header-Wert enthält (einen Wert, der mit den Zeichen W/ beginnt), ändert CloudFront diesen Wert nicht und gibt ihn so an den Viewer zurück, wie er vom Ursprung empfangen wurde.

Wenn das Objekt aus dem Ursprung einen ungültigen ETag-Header-Wert enthält (der Wert beginnt nicht mit " oder mit W/), entfernt CloudFront den ETag-Header und gibt das Objekt ohne den ETag-Antwort-Header an den Viewer zurück.

Weitere Informationen finden Sie auf den folgenden Seiten in den MDN-Webdokumenten:

• Direktiven (ETag-HTTP-Header)

• Schwache Validierung (bedingte HTTP-Anforderungen)

• If-None-Match HTTP-Header