Komprimierte Dateien bereitstellen

Sie können CloudFront es verwenden, um bestimmte Objekttypen (Dateien) automatisch zu komprimieren und die komprimierten Objekte bereitzustellen, wenn Viewer (Webbrowser oder andere Clients) sie unterstützen. Viewer geben ihre Unterstützung für komprimierte Objekte mit dem Accept-Encoding-HTTP-Header an.

CloudFront kann Objekte mit den Komprimierungsformaten Gzip und Brotli komprimieren. Wenn der Viewer beide Formate unterstützt und beide auf dem erreichten Cache-Server vorhanden sind, wird Brotli bevorzugt. CloudFront Wenn auf dem Cacheserver nur ein Komprimierungsformat vorhanden ist, wird es CloudFront zurückgegeben.

Anmerkung

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

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. Insbesondere bei JavaScript CSS-Dateien können schnellere Downloads zu einem schnelleren Rendern von Webseiten für Ihre Benutzer führen. Da die Kosten für die CloudFront Datenübertragung zudem von der Gesamtmenge der bereitgestellten Daten abhängen, kann die Bereitstellung komprimierter Objekte kostengünstiger sein als die Bereitstellung unkomprimierter Objekte.

Einige benutzerdefinierte Ursprünge können auch Objekte komprimieren. Ihr Origin ist möglicherweise in der Lage, Objekte zu komprimieren, die CloudFront nicht komprimiert werden (sieheDateitypen, die von CloudFront komprimiert werden). Wenn Ihr Origin ein komprimiertes Objekt zurückgibt CloudFront, CloudFront erkennt es anhand des Vorhandenseins eines Content-Encoding Headers, dass das Objekt komprimiert ist, und komprimiert das Objekt nicht erneut.

Konfigurieren Sie CloudFront es, um Objekte zu komprimieren

Um das Komprimieren von Objekten CloudFront zu konfigurieren, aktualisieren Sie das Cache-Verhalten, das Sie für die komprimierten Objekte bereitstellen möchten, indem Sie alle folgenden Schritte ausführen:

1. Stellen Sie sicher, dass die Einstellung Objekte automatisch komprimieren auf Ja gesetzt ist. (In AWS CloudFormation oder in der CloudFront API, Compress auf eingestellttrue.)

2. Verwenden Sie eine Cache-Richtlinie, um Cache-Einstellungen anzugeben, und stellen Sie sicher, dass die Gzip- und Brotli-Einstellungen aktiviert sind. (In AWS CloudFormation oder in der CloudFront API, setzen EnableAcceptEncodingGzip und EnableAcceptEncodingBrotli auftrue.)

3. Vergewissern Sie sich, dass die TTL-Werte in der Cache-Richtlinie auf einen Wert höher als Null festgelegt sind. Wenn Sie die TTL-Werte auf Null setzen, ist das Zwischenspeichern deaktiviert und Objekte werden CloudFront nicht komprimiert.

Sie können ein Cache-Verhalten mithilfe eines der folgenden Tools aktualisieren:

• Die Konsole CloudFront

• AWS CloudFormation

• AWS -SDKs und Befehlszeilen-Tools

Wie funktioniert die CloudFront Komprimierung

Wenn Sie CloudFront das Komprimieren von Objekten konfigurieren (siehe vorherigen Abschnitt), funktioniert das wie folgt:

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, CloudFront bevorzugt er Brotli.

   Anmerkung

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

2. Sucht am Edge-Standort im Cache CloudFront nach einer komprimierten Kopie des angeforderten Objekts.

3. Wenn sich das komprimierte Objekt bereits im Cache befindet, wird es CloudFront an den Viewer gesendet und die verbleibenden Schritte übersprungen.

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

   Anmerkung

   Wenn sich bereits eine unkomprimierte Kopie des Objekts im Cache befindet, wird sie CloudFront möglicherweise an den Betrachter gesendet, ohne die Anfrage an den Ursprung weiterzuleiten. Dies kann beispielsweise passieren, wenn die Komprimierung CloudFront zuvor übersprungen wurde. In diesem Fall wird das unkomprimierte Objekt CloudFront zwischengespeichert und solange bereitgestellt, bis das Objekt abläuft, entfernt oder ungültig gemacht wird.

4. Wenn der Ursprung ein komprimiertes Objekt zurückgibt, was durch das Vorhandensein eines Content-Encoding Headers in der HTTP-Antwort angezeigt wird, CloudFront sendet er das komprimierte Objekt an den Viewer, fügt es dem Cache hinzu und überspringt den verbleibenden Schritt. CloudFront komprimiert das Objekt nicht erneut.

   Wenn der Ursprung ein unkomprimiertes Objekt zurückgibt CloudFront (es gibt keinen Content-Encoding Header in der HTTP-Antwort), wird CloudFront bestimmt, ob das Objekt komprimierbar ist. Weitere Informationen darüber, wie CloudFront bestimmt wird, ob ein Objekt komprimierbar ist, finden Sie im folgenden Abschnitt.

5. Wenn das Objekt komprimierbar ist, wird CloudFront es komprimiert, an den Viewer gesendet und dem Cache hinzugefügt. (In seltenen Fällen CloudFront kann die Komprimierung übersprungen und das unkomprimierte Objekt an den Viewer gesendet werden.)

Wann werden Objekte CloudFront komprimiert

Die folgende Liste enthält weitere Informationen darüber, wann Objekte CloudFront komprimiert werden.

Anforderung verwendet HTTP 1.0

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

Accept-Encoding-Header der Anforderung

Wenn der Accept-Encoding Header in der Viewer-Anfrage fehlt oder wenn er keinen Wert enthält gzip oder br CloudFront keinen Wert enthält, wird das Objekt in der Antwort nicht komprimiert. Wenn der Accept-Encoding Header zusätzliche Werte enthältdeflate, z. B. CloudFront werden diese entfernt, bevor die Anfrage an den Ursprung weitergeleitet wird.

Wenn für die Komprimierung von Objekten konfiguriert CloudFront ist, nimmt er den Accept-Encoding Header automatisch in den Cache-Schlüssel und in Ursprungsanfragen auf.

Dynamischer Inhalt

CloudFront komprimiert dynamische Inhalte nicht immer. Manchmal werden Antworten auf dynamische Inhalte komprimiert und manchmal nicht.

Inhalt wird bereits zwischengespeichert, wenn Sie das Komprimieren von CloudFront Objekten konfigurieren

CloudFront komprimiert Objekte, wenn sie vom Ursprung abgerufen werden. Wenn Sie CloudFront das Komprimieren von Objekten konfigurieren, werden Objekte, die bereits an Kantenpositionen zwischengespeichert sind, CloudFront nicht komprimiert. Wenn ein zwischengespeichertes Objekt an einem Edge-Standort abläuft und eine weitere Anforderung für das Objekt an Ihren Ursprung CloudFront weiterleitet, wird das Objekt außerdem CloudFront nicht komprimiert, wenn Ihr Origin-Objekt den HTTP-Statuscode 304 zurückgibt, was bedeutet, dass der Edge-Standort bereits über die neueste Version des Objekts verfügt. Wenn Sie Objekte komprimieren CloudFront möchten, die bereits an Edge-Standorten zwischengespeichert sind, müssen Sie diese Objekte für ungültig erklären. Weitere Informationen finden Sie unter Machen Sie Dateien ungültig, um Inhalte zu entfernen.

Ursprung ist bereits für die Kompression von Objekten konfiguriert

Wenn Sie die Konfiguration so konfigurieren CloudFront , dass Objekte komprimiert werden und der Ursprung auch Objekte komprimiert, sollte der Ursprung einen Content-Encoding Header enthalten, der angibt, CloudFront dass das Objekt bereits komprimiert ist. Wenn eine Antwort von einem Ursprung den Content-Encoding Header enthält, CloudFront wird das Objekt nicht komprimiert, unabhängig vom Wert des Headers. CloudFront sendet die Antwort an den Betrachter und speichert das Objekt an der Edge-Position im Cache.

Dateitypen, die CloudFront komprimiert werden

Eine vollständige Liste der Dateitypen, die CloudFront komprimiert werden, finden Sie unter. Dateitypen, die von CloudFront komprimiert werden

Größe der Objekte, die CloudFront komprimiert werden

CloudFront komprimiert Objekte mit einer Größe zwischen 1.000 Byte und 10.000.000 Byte.

Content-Length-Header

Der Ursprung muss in der Antwort einen Content-Length Header enthalten, CloudFront anhand dessen bestimmt wird, ob die Größe des Objekts in dem Bereich liegt, der komprimiert wird. CloudFront Wenn der Content-Length Header fehlt, einen ungültigen Wert enthält oder einen Wert außerhalb des Größenbereichs für die CloudFront Komprimierung enthält, CloudFront wird das Objekt nicht komprimiert.

Den HTTP-Statuscode der Antwort.

CloudFront komprimiert Objekte nur, wenn der HTTP-Statuscode der Antwort 200403, oder lautet. 404

Antwort hat keinen Körper

Wenn die HTTP-Antwort vom Ursprung keinen Hauptteil hat, gibt es nichts, was komprimiert werden CloudFront könnte.

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 bestem Wissen. In seltenen Fällen CloudFront überspringt die Komprimierung. CloudFront trifft diese Entscheidung auf der Grundlage einer Vielzahl von Faktoren, einschließlich der Hostkapazität. Wenn die Komprimierung für ein Objekt CloudFront übersprungen wird, wird das unkomprimierte Objekt zwischengespeichert und Benutzern weiterhin zur Verfügung gestellt, bis das Objekt abläuft, entfernt oder ungültig gemacht wird.

Dateitypen, die von CloudFront komprimiert werden

Wenn Sie das Komprimieren von Objekten konfigurieren CloudFront , werden CloudFront nur Objekte komprimiert, die einen der folgenden Werte im Antwort-Header haben: Content-Type

• 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

ETag-Header-Konvertierung

Wenn das unkomprimierte Objekt aus dem Ursprung einen gültigen, starken ETag HTTP-Header enthält und das Objekt CloudFront komprimiert, konvertiert es CloudFront auch den starken ETag Header-Wert in einen schwachen ETag und gibt den schwachen ETag Wert 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. Auf diese Weise können Betrachter und der Ursprung die komprimierten und unkomprimierten Versionen eines Objekts als semantisch gleichwertig behandeln, wodurch unnötige Datenübertragungen vermieden werden. CloudFront

Ein gültiger, starker ETag-Header-Wert beginnt mit einem doppelten Anführungszeichen ("). Um den starken ETag Wert in einen schwachen Wert umzuwandeln, werden die Zeichen W/ am Anfang des starken ETag Werts CloudFront hinzugefügt.

Wenn das Objekt aus dem Ursprung einen schwachen ETag Header-Wert (einen Wert, der mit den Zeichen beginntW/) enthält, CloudFront ändert dieser Wert nicht und gibt ihn an den Betrachter zurück, so 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 mitW/), CloudFront wird der ETag Header entfernt und das Objekt ohne den ETag Antwort-Header an den Viewer zurückgegeben.

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