Bereitstellen von komprimierten Dateien - Amazon CloudFront

Bereitstellen von komprimierten Dateien

Sie können mit CloudFront bestimmte Objekttypen (Dateien) automatisch komprimieren und die komprimierten Objekte bereitstellen, wenn Viewer (Webbrowser oder andere Clients) diese unterstützen. Viewer geben ihre Unterstützung für komprimierte Objekte mit dem Accept-Encoding-HTTP-Header an. CloudFront kann Objekte mithilfe des Gzip- und Brotli-Komprimierungsformats komprimieren. Wenn der Viewer beide Formate unterstützt, bevorzugt CloudFront 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.

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. Gerade bei JavaScript- und CSS-Dateien bedeuten schnellere Downloads auch ein schnelleres Rendern von Webseiten für Ihre Benutzer. Da die Kosten der CloudFront-Datenübertragung außerdem auf der Gesamtmenge der bereitgestellten Daten basieren, kann die Bereitstellung komprimierter Objekte kostengünstiger sein als die Bereitstellung unkomprimierter Objekte.

Einige benutzerdefinierte Ursprünge können auch Objekte komprimieren. Ihr Ursprung kann möglicherweise Objekte komprimieren, die CloudFront nicht komprimiert (siehe Dateitypen, die von CloudFront komprimiert werden). Wenn Ihr Ursprung ein komprimiertes Objekt an CloudFront zurückgibt, erkennt CloudFront, dass das Objekt basierend auf dem Vorhandensein eines Content-Encoding-Headers komprimiert ist und komprimiert das Objekt nicht erneut.

Konfigurieren von CloudFront zur Kompression von Objekten

Um CloudFront zum Komprimieren von Objekten zu konfigurieren, aktualisieren Sie das Cache-Verhalten, das Sie den komprimierten Objekten bereitstellen möchten, indem Sie alle der folgenden Schritte ausführen:

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

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

  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 festlegen, wird das Zwischenspeichern deaktiviert und die Objekte werden nicht von CloudFront komprimiert.

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

Funktionsweise von CloudFront-Kompression

Wenn Sie CloudFront zum Komprimieren von Objekten konfigurieren (siehe vorheriger Abschnitt), funktioniert es 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, bevorzugt CloudFront 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. CloudFront prüft am Edge-Standort den Cache auf eine komprimierte Kopie des angeforderten Objekts.

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

    Wenn das komprimierte Objekt nicht im Cache enthalten ist, leitet CloudFront die Anfrage 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, was durch das Vorhandensein eines Content-Encoding-Headers in der HTTP-Antwort angezeigt wird, 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.

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

  5. Wenn das Objekt komprimierbar ist, komprimiert CloudFront es, sendet es an den Viewer und fügt es dem Cache hinzu. (In seltenen Fällen könnte CloudFront die Komprimierung überspringen und das unkomprimierte Objekt an den Viewer senden.)

Hinweise zur CloudFront-Kompression

Die folgende Liste enthält weitere Informationen zum Komprimieren von Objekten in CloudFront.

Anforderung verwendet HTTP 1.0

Wenn eine Anfrage 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-Anfrage 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. Wenn der Accept-Encoding-Header jedoch explizit in der Cache-Richtlinie (oder in den Legacy-Cache-Einstellungen) aufgeführt ist, komprimiert CloudFront das Objekt in der Antwort nicht.

Dynamischer Inhalt

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

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 Anfrage für das Objekt an Ihren Ursprung weiterleitet, komprimiert CloudFront das Objekt nicht, wenn Ihr Ursprung einen HTTP-Statuscode 304 zurückgibt, was bedeutet, dass der Edge-Standort bereits die neueste Version des Objekts. 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.

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 gibt 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 der Dateitypen, die CloudFront komprimiert, finden Sie unter 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 enthält oder einen Wert außerhalb des von CloudFront komprimierten Größenbereichs enthält, komprimiert CloudFront das Objekt nicht.

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. 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/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/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 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-Header-Wert beginnt 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: