Zum Inhalt springen
Aback Tools Logo

Checkliste für die Komprimierung statischer S3-Assets

Arbeiten Sie diese Schritt-für-Schritt-Checkliste durch, um Ihren AWS S3-Bucket und die CloudFront-Verteilung so zu konfigurieren, dass vorkomprimierte statische GZIP- und Brotli-Assets korrekt bereitgestellt werden. Die S3-Checkliste für die Komprimierung statischer Assets umfasst Bucket-Richtlinien, vorkomprimierte Datei-Uploads mit korrekten Content-Encoding-Metadaten, CloudFront-Cache-Richtlinien, Vary-Header und Verifizierungsbefehle – jeweils mit kopierfertigen AWS CLI- und Terraform-Snippets. Alle Inhalte laufen in Ihrem Browser – keine Anmeldung erforderlich.

S3 Static Asset Compression Checklist
Work through this checklist to configure your AWS S3 bucket and CloudFront distribution to serve pre-compressed GZIP and Brotli static assets correctly. Each item includes configuration snippets, warnings, and verification commands. All content is generated in your browser - no signup required.
0 / 17 completed0%

Enable public read access (or use CloudFront OAC)

For public static sites, configure the bucket policy to allow s3:GetObject. For private assets served via CloudFront, use Origin Access Control (OAC) instead of public access.

Enable static website hosting (if serving directly from S3)

Go to S3 → Bucket → Properties → Static website hosting → Enable. Set index.html as the index document. Skip this step if you are serving exclusively through CloudFront.

Configure CORS for font and API assets (if needed)

If your S3 bucket serves fonts or JSON assets loaded cross-origin, add a CORS configuration to allow the correct origins.

Upload pre-compressed .gz files alongside originals

Pre-compress your static assets at build time and upload both the original and .gz version. S3 does not compress on-the-fly - you must upload pre-compressed files.

Upload pre-compressed .br files for Brotli support

Upload Brotli-compressed versions of your assets. CloudFront can serve .br files to clients that send Accept-Encoding: br.

Set correct Content-Type on all uploaded files

S3 must serve the correct Content-Type for each asset - not the MIME type of the compressed wrapper. Set Content-Type to the original file type (e.g. application/javascript for .js.gz).

Set Cache-Control headers on uploaded assets

Set long-lived Cache-Control headers on versioned/hashed assets and short-lived headers on index.html and other non-versioned files.

Create a CloudFront distribution with S3 as origin

Create a CloudFront distribution pointing to your S3 bucket. Use the S3 REST endpoint (not the website endpoint) for OAC support and better performance.

Enable CloudFront automatic compression

In CloudFront → Behaviors → Edit → Compress objects automatically → Yes. This enables CloudFront to compress responses on-the-fly for objects not already compressed. For pre-compressed assets, CloudFront will pass through the Content-Encoding header.

Configure cache policy to forward Accept-Encoding

Create a CloudFront cache policy that includes Accept-Encoding in the cache key. This ensures CloudFront caches separate versions for GZIP, Brotli, and uncompressed responses.

Enforce HTTPS with redirect-to-https viewer protocol policy

Set the viewer protocol policy to "Redirect HTTP to HTTPS" to ensure all traffic is encrypted. This is required for Brotli - browsers only send Accept-Encoding: br over HTTPS.

Add Vary: Accept-Encoding response header

Configure a CloudFront response headers policy to add Vary: Accept-Encoding. This tells downstream caches (browsers, CDN edge nodes) to cache separate versions for different encodings.

Add security headers via CloudFront response headers policy

Use a CloudFront managed response headers policy (SecurityHeadersPolicy) or create a custom one with X-Content-Type-Options, X-Frame-Options, and Strict-Transport-Security.

Verify GZIP compression is working

Use curl to confirm CloudFront is serving GZIP-compressed responses with the correct Content-Encoding header.

Verify Brotli compression is working

Confirm CloudFront serves Brotli-compressed responses when the client sends Accept-Encoding: br.

Verify CloudFront cache hit ratio

Check the X-Cache response header to confirm CloudFront is caching compressed responses. "Hit from cloudfront" means the response was served from cache.

Measure actual transfer size savings

Use curl with --compressed to measure the actual transfer size vs the uncompressed size and confirm the expected savings.

Quick Reference: S3 + CloudFront Compression Architecture

Browser
  │  Accept-Encoding: gzip, br
  ▼
CloudFront Edge
  │  Checks cache key (includes Accept-Encoding)
  │  Cache HIT → serve cached compressed response
  │  Cache MISS → forward to S3 origin
  ▼
S3 Origin
  │  Returns pre-compressed file (app.js with Content-Encoding: gzip)
  │  OR returns uncompressed file (CloudFront compresses on-the-fly)
  ▼
CloudFront Edge
  │  Caches response keyed by Accept-Encoding
  │  Adds Vary: Accept-Encoding header
  ▼
Browser
  │  Decompresses response transparently
  └  Renders page

Warum sollten Sie unsere S3-Checkliste für die statische Asset-Komprimierung verwenden?

  • Komplette Einrichtung der S3-Komprimierung an einem Ort: Die S3-Checkliste für die Komprimierung statischer Assets deckt jeden Schritt ab – Bucket-Richtlinie, Upload vorkomprimierter Dateien, CloudFront-Konfiguration, Vary-Header und Verifizierungsbefehle – damit Sie keinen kritischen Schritt verpassen, der die Komprimierung unterbricht.
  • Checkliste für sichere S3-Komprimierung online: Der gesamte Inhalt der Checkliste wird vollständig in Ihrem Browser generiert. Es werden keine AWS-Anmeldeinformationen, Bucket-Namen oder Domänennamen an einen Server gesendet – sicher für die Planung von Produktions-S3- und CloudFront-Komprimierungskonfigurationen.
  • Konfigurationsausschnitte für jeden Schritt: Jeder Checklistenpunkt enthält einen kopierfertigen Konfigurationsausschnitt – AWS CLI-Befehle, Terraform-Ressourcen, Bucket-Richtlinien und Curl-Verifizierungsbefehle – sodass Sie jeden Schritt sofort implementieren können.
  • Für immer 100 % kostenlos: Die S3-Checkliste für die statische Asset-Komprimierung ist völlig kostenlos, ohne Anmeldung, ohne Premium-Stufe, ohne Einschränkungen und ohne Werbung. Benutzen Sie es so oft Sie brauchen, für immer.

Warum die S3-Komprimierung eine Vorkomprimierung erfordert

Im Gegensatz zu Nginx oder Apache komprimiert Amazon S3 Antworten nicht im laufenden Betrieb. S3 ist ein Objektspeicherdienst – er stellt Dateien genau so bereit, wie sie hochgeladen wurden. Um komprimierte Assets aus S3 bereitzustellen, müssen Sie Ihre Dateien zum Zeitpunkt der Erstellung vorkomprimieren und sowohl die ursprüngliche als auch die komprimierte Version mit den richtigen Content-Encoding-Metadaten hochladen. Unsere S3-Checkliste für die statische Asset-Komprimierung führt Sie durch jeden Schritt dieses Prozesses, von der Bucket-Konfiguration bis zur Einrichtung und Überprüfung der CloudFront-Cache-Richtlinie.

So funktioniert die S3-Komprimierungs-Checkliste

  1. Durcharbeiten jeder Kategorie: Die Checkliste ist in fünf Kategorien unterteilt: S3-Bucket-Setup, Hochladen vorkomprimierter Dateien, CloudFront-Konfiguration, Antwortheader und Überprüfung. Klicken Sie auf jedes Element, um Konfigurationsausschnitte und Warnungen zu erweitern.
  2. Abgeschlossene Schritte abhaken: Klicken Sie auf das Kreissymbol neben jedem Element, um es als abgeschlossen zu markieren. Der Fortschrittsbalken verfolgt Ihren Gesamtabschluss aller Checklistenpunkte.
  3. Kopieren und Bereitstellen: Jedes Element enthält einen kopierbereiten AWS CLI-Befehl, eine Terraform-Ressource oder einen Curl-Verifizierungsbefehl – ​​klicken Sie auf „Kopieren“, um ihn sofort in Ihrem Terminal oder Ihrer Pipeline zu verwenden.

Was die Checkliste abdeckt

  • S3-Bucket-Setup: Bucket-Richtlinie für öffentliches Lesen oder CloudFront OAC, statisches Website-Hosting und CORS-Konfiguration für ursprungsübergreifende Schriftarten und API-Assets.
  • Hochladen vorkomprimierter Dateien: So laden Sie.gz- und.br-Dateien mit korrekten Inhaltskodierungs-, Inhaltstyp- und Cache-Kontrollmetadaten mithilfe der AWS CLI hoch.
  • CloudFront-Konfiguration: Verteilungseinrichtung, automatische Komprimierung, Cache-Richtlinie mit Accept-Encoding im Cache-Schlüssel und HTTPS-Durchsetzung.
  • Überprüfung: Curl-Befehle zur Bestätigung, dass GZIP und Brotli funktionieren, Überprüfung der Cache-Trefferquote und Messung der Übertragungsgröße.

S3 + CloudFront vs. On-the-Fly-Komprimierung

Vorkomprimierung + S3 ist effizienter als die On-the-Fly-Komprimierung für statische Assets – die Komprimierungs-CPU-Kosten werden einmalig zur Erstellungszeit bezahlt, nicht bei jeder Anfrage. CloudFront kann Antworten für Objekte, die noch nicht komprimiert sind (Objekte ≥ 1000 Bytes), auch im laufenden Betrieb komprimieren. Durch die Vorkomprimierung erhalten Sie jedoch maximale Komprimierungsstufen (GZIP-Stufe 9, Brotli-Qualität 11), die von der spontanen Komprimierung von CloudFront nicht verwendet werden. Um die beste Leistung zu erzielen, komprimieren Sie Ihre Assets vorab und laden Sie sie mit den korrekten Metadaten auf S3 hoch. CloudFront leitet den Content-Encoding-Header transparent weiter.

Häufig gestellte Fragen

Die Checkliste für die Komprimierung statischer S3-Assets ist eine Schritt-für-Schritt-Anleitung für die Konfiguration von AWS S3 und CloudFront, um vorkomprimierte statische GZIP- und Brotli-Assets korrekt bereitzustellen. Es umfasst Bucket-Richtlinien, vorkomprimierte Datei-Uploads mit korrekten Metadaten, CloudFront-Cache-Richtlinien, Vary-Header und Verifizierungsbefehle.

Nein. Amazon S3 ist ein Objektspeicherdienst – er stellt Dateien genau so bereit, wie sie hochgeladen wurden. Um komprimierte Assets aus S3 bereitzustellen, müssen Sie Ihre Dateien zum Zeitpunkt der Erstellung vorkomprimieren und sie mit den richtigen Content-Encoding-Metadaten hochladen. CloudFront kann Antworten für unkomprimierte Objekte im laufenden Betrieb komprimieren, die Vorkomprimierung führt jedoch zu besseren Komprimierungsverhältnissen.

Ja. Die S3-Checkliste für die statische Asset-Komprimierung ist 100 % kostenlos, ohne Anmeldung, ohne Abonnement, ohne Einschränkungen und ohne Werbung. Der gesamte Inhalt der Checkliste wird in Ihrem Browser generiert – es werden keine AWS-Anmeldeinformationen oder Konfigurationsdaten an einen Server gesendet.

Laden Sie die komprimierte Datei mit dem ursprünglichen Dateinamen hoch (z. B. app.js, nicht app.js.gz) und legen Sie Content-Encoding: gzip und Content-Type: application/javascript fest. Dadurch werden Browser angewiesen, die Antwort transparent zu dekomprimieren. Wenn Sie app.js.gz ohne Content-Encoding hochladen, laden Browser es als Binärdatei herunter.

Aktivieren Sie „Objekte automatisch komprimieren“ in Ihren CloudFront-Verhaltenseinstellungen und erstellen Sie eine Cache-Richtlinie mit EnableAcceptEncodingBrotli: true. CloudFront stellt Brotli für Kunden bereit, die Accept-Encoding: br senden. Hinweis: Brotli wird nur über HTTPS ausgehandelt.

Ohne Accept-Encoding im Cache-Schlüssel speichert CloudFront nur eine Version jedes Objekts zwischen. Wenn eine komprimierte Antwort zwischengespeichert und einem Client bereitgestellt wird, der GZIP nicht unterstützt, empfängt der Browser beschädigte Inhalte. Durch die Aufnahme von Accept-Encoding in den Cache-Schlüssel wird sichergestellt, dass CloudFront für jede Codierung separate Versionen zwischenspeichert.

Die On-the-Fly-Komprimierung von CloudFront verwendet GZIP Level 6 und komprimiert nur Objekte ≥1000 Bytes. Bei der Vorkomprimierung werden maximale Ebenen (GZIP-Ebene 9, Brotli-Qualität 11) verwendet und komprimierte Dateien auf S3 hochgeladen. Die Vorkomprimierung ist für statische Assets effizienter, da die CPU-Kosten einmalig zur Erstellungszeit bezahlt werden.

Führen Sie Folgendes aus: „curl -H „Accept-Encoding: gzip“ -I https://YOUR-CLOUDFRONT-DOMAIN/app.js“ und suchen Sie nach „Content-Encoding: gzip“. Für Brotli: `curl -H "Accept-Encoding: br" -I https://YOUR-CLOUDFRONT-DOMAIN/app.js` und suchen Sie nach `Content-Encoding: br`.

Verwenden Sie den S3-REST-Endpunkt mit CloudFront Origin Access Control (OAC). Der S3-Website-Endpunkt unterstützt OAC nicht, erfordert öffentlichen Bucket-Zugriff und unterstützt kein HTTPS von CloudFront zu S3. Der REST-Endpunkt mit OAC ist sicherer und unterstützt alle CloudFront-Funktionen.