Skip to content
Aback Tools Logo

S3 Static Asset Compression Checklist

Work through this step-by-step checklist to configure your AWS S3 bucket and CloudFront distribution to serve pre-compressed GZIP and Brotli static assets correctly. The S3 static asset compression checklist covers bucket policy, pre-compressed file upload with correct Content-Encoding metadata, CloudFront cache policy, Vary headers, and verification commands — each with ready-to-copy AWS CLI and Terraform snippets. All content runs in your browser — no signup required.

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

Why Use Our S3 Static Asset Compression Checklist?

Complete S3 Compression Setup in One Place

The S3 static asset compression checklist covers every step — bucket policy, pre-compressed file upload, CloudFront configuration, Vary headers, and verification commands — so you don't miss a critical step that breaks compression.

Secure S3 Compression Checklist Online

All checklist content is generated entirely in your browser. No AWS credentials, bucket names, or domain names are sent to any server — safe for planning production S3 and CloudFront compression configurations.

Configuration Snippets for Every Step

Each checklist item includes a ready-to-copy configuration snippet — AWS CLI commands, Terraform resources, bucket policies, and curl verification commands — so you can implement each step immediately.

100% Free Forever

The S3 static asset compression checklist is completely free with no signup, no premium tier, no limits, and no ads. Use it as many times as you need, forever.

Common Use Cases for S3 Static Asset Compression Checklist

New S3 + CloudFront Static Site Setup

Use the S3 static asset compression checklist when setting up a new static site on S3 and CloudFront — work through each step to ensure GZIP and Brotli compression are configured correctly from day one.

React, Next.js, and Vite Build Deployment

Deploy pre-compressed React, Next.js, or Vite build outputs to S3 — the checklist covers how to upload .gz and .br files with correct Content-Encoding and Content-Type metadata for transparent browser decompression.

E-Commerce CDN Performance Optimization

Reduce page load times for Shopify, WooCommerce, or custom e-commerce storefronts served from S3 + CloudFront — the checklist ensures all JS, CSS, and JSON assets are served with maximum compression.

CI/CD Pipeline Compression Integration

Integrate pre-compression into your GitHub Actions, GitLab CI, or AWS CodePipeline — the checklist provides the exact AWS CLI commands to compress and upload assets with correct metadata in your pipeline.

CloudFront Cache Hit Rate Improvement

Diagnose low CloudFront cache hit rates caused by missing Accept-Encoding in the cache key — the checklist covers the exact cache policy configuration needed to cache compressed and uncompressed versions separately.

Compression Audit for Existing S3 Deployments

Audit an existing S3 + CloudFront deployment for compression gaps — use the checklist to identify missing Content-Encoding headers, incorrect MIME types, or misconfigured cache policies.

Understanding S3 Static Asset Compression

Why S3 Compression Requires Pre-compression

Unlike Nginx or Apache, Amazon S3 does not compress responses on-the-fly. S3 is an object storage service — it serves files exactly as they were uploaded. To serve compressed assets from S3, you must pre-compress your files at build time and upload both the original and compressed versions with the correctContent-Encoding metadata. Our S3 static asset compression checklist walks you through every step of this process, from bucket configuration to CloudFront cache policy setup and verification.

How the S3 Compression Checklist Works

  1. Work Through Each Category: The checklist is organized into five categories — S3 Bucket Setup, Upload Pre-compressed Files, CloudFront Configuration, Response Headers, and Verification. Click each item to expand configuration snippets and warnings.
  2. Check Off Completed Steps: Click the circle icon next to each item to mark it complete. The progress bar tracks your overall completion across all 16 checklist items.
  3. Copy and Deploy: Each item includes a ready-to-copy AWS CLI command, Terraform resource, or curl verification command — click Copy to use it immediately in your terminal or pipeline.

What the Checklist Covers

  • S3 Bucket Setup: Bucket policy for public read or CloudFront OAC, static website hosting, and CORS configuration for cross-origin font and API assets.
  • Pre-compressed File Upload: How to upload .gz and .br files with correct Content-Encoding, Content-Type, and Cache-Control metadata using the AWS CLI.
  • CloudFront Configuration: Distribution setup, automatic compression, cache policy with Accept-Encoding in the cache key, and HTTPS enforcement.
  • Verification: curl commands to confirm GZIP and Brotli are working, cache hit ratio checks, and transfer size measurement.

S3 + CloudFront vs On-the-fly Compression

Pre-compression + S3is more efficient than on-the-fly compression for static assets — the compression CPU cost is paid once at build time, not on every request. CloudFront can also compress responses on-the-fly for objects not already compressed (objects ≥1000 bytes), but pre-compression gives you maximum compression levels (GZIP level 9, Brotli quality 11) that CloudFront's on-the-fly compression does not use. For the best performance, pre-compress your assets and upload them to S3 with correct metadata — CloudFront will pass through the Content-Encodingheader transparently.

Frequently Asked Questions About S3 Static Asset Compression Checklist

The S3 static asset compression checklist is a step-by-step guide for configuring AWS S3 and CloudFront to serve pre-compressed GZIP and Brotli static assets correctly. It covers bucket policy, pre-compressed file upload with correct metadata, CloudFront cache policy, Vary headers, and verification commands — all with ready-to-copy configuration snippets.

No. Amazon S3 is an object storage service — it serves files exactly as they were uploaded. To serve compressed assets from S3, you must pre-compress your files at build time and upload them with the correct Content-Encoding metadata (Content-Encoding: gzip or Content-Encoding: br). CloudFront can compress responses on-the-fly for uncompressed objects, but pre-compression gives better compression ratios.

Yes. The S3 static asset compression checklist is 100% free with no signup, no subscription, no limits, and no ads. All checklist content is generated in your browser — no AWS credentials or configuration data are sent to any server.

Upload the compressed file using the original filename (e.g. app.js, not app.js.gz) and set two metadata fields: Content-Encoding: gzip (or br for Brotli) and Content-Type: application/javascript (the original MIME type, not the compressed type). This tells browsers to decompress the response transparently. If you upload as app.js.gz without Content-Encoding, browsers will download it as a binary file.

Enable "Compress objects automatically" in your CloudFront behavior settings and create a cache policy with EnableAcceptEncodingBrotli: true. CloudFront will serve Brotli to clients that send Accept-Encoding: br (all modern browsers over HTTPS). Note: Brotli is only negotiated over HTTPS — HTTP connections will only receive GZIP.

Without Accept-Encoding in the cache key, CloudFront caches only one version of each object — either compressed or uncompressed. If a compressed response is cached and served to a client that doesn't support GZIP, the browser receives corrupted content. Including Accept-Encoding in the cache key ensures CloudFront caches separate versions for each encoding.

CloudFront on-the-fly compression compresses objects at the edge on each cache miss — it uses GZIP level 6 and only compresses objects ≥1000 bytes. Pre-compression compresses at build time using maximum levels (GZIP level 9, Brotli quality 11) and uploads the compressed files to S3. Pre-compression is more efficient for static assets since the CPU cost is paid once, not on every cache miss.

Run: `curl -H "Accept-Encoding: gzip" -I https://YOUR-CLOUDFRONT-DOMAIN/app.js` and look for `Content-Encoding: gzip` in the response headers. For Brotli: `curl -H "Accept-Encoding: br" -I https://YOUR-CLOUDFRONT-DOMAIN/app.js` and look for `Content-Encoding: br`. Also check for `X-Cache: Hit from cloudfront` on subsequent requests to confirm caching is working.

Use the S3 REST endpoint (YOUR-BUCKET.s3.REGION.amazonaws.com) with CloudFront Origin Access Control (OAC). The S3 website endpoint does not support OAC, requires public bucket access, and does not support HTTPS from CloudFront to S3. The REST endpoint with OAC is more secure and supports all CloudFront features.