I had a CloudFront distribution configured with S3 as an origin.

I have enabled "Compress Objects Automatically" as per Amazon guide. Waited for the distribution status to display "online" then invalidated all files.

My Response headers are:

Date:Sat, 03 Mar 2018 15:39:10 GMT
Last-Modified:Sat, 03 Mar 2018 15:37:32 GMT
Via:1.1 4dbdc57755819d1a0ec1defc2630d677.cloudfront.net (CloudFront)
X-Cache:Hit from cloudfront

Request Headers:

Accept-Encoding:gzip, deflate, br
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

It has a "Content-length" and supported "Content-Type", what am I missing? I'm going mad here...

Since then I've created a new s3 bucket and new distribution going through the steps described above, but choosing a different bucket location (in case this is affecting is somehow), Here are distribution general settings:

Delivery Method Web
Cookie Logging  Off
Distribution Status Deployed
Comment -
Price Class Use All Edge Locations (Best Performance)
State   Enabled
Alternate Domain Names (CNAMEs) -
SSL Certificate Default CloudFront Certificate (*.cloudfront.net)
Domain Name d189ud9v76clu1.cloudfront.net
Custom SSL Client Support   -
Security Policy TLSv1
Supported HTTP Versions HTTP/2, HTTP/1.1, HTTP/1.0
IPv6    Enabled
Default Root Object -
Last Modified   2018-03-03 15:46 UTC
Log Bucket

And behaviours: distribution behaviours

I still can't get gzip to work here is the new file: http://d189ud9v76clu1.cloudfront.net/app.min.js

  • Is the client sending "Accept-Encoding: gzip" in the request to CloudFront? Press F12 in your browser and verify the request headers. – John Hanley Mar 3 '18 at 17:43
  • Yes, I've updated the question with request headers – Lukigi Mar 3 '18 at 19:04
  • I've been messing with this for a while, so I did both, I always invalidate before testing as you can see by the age in the response header. – Lukigi Mar 4 '18 at 12:54
  • What cache? browser cache is cleared while dev tools enabled (I have it ticked). CloudFront cache also no, as before I posted this I had a miss from CloudFront with the same result (I've been messing with this for days now) – Lukigi Mar 7 '18 at 18:30
  • @Lukigi I see that the file is now gzipped. Do you know what made it work? I'm experiencing the same issue right now. – Jacob Stamm Oct 24 '18 at 21:13

Does your request contain the necessary Accept-Encoding: gzip header?

Your headers look like curl output, which does not send that header by default.

You can test gzip encoding with curl via: curl -H "Accept-Encoding: gzip" https://example.com/asset.js"

  • This is a standard static web asset, included in html, I've added request headers to the question – Lukigi Mar 3 '18 at 19:04

After that I've paid for AWS help desk to solve this issue for me, here is their reply:

I do understand as it can be frustrating, unable to view changes made to your configuration using Developer Tools.

From the documentation that is online I do confirm that it can be a little confusing which I will do a feedback request to make some changes to the documentation, in your case it's more performance changes, if you look at the bottom of Chrome browser, Network option under Developer tools you will see how your pages performance was impacted due to the gzip compression.

To view the configuration through the browser another option the same as you would get in the "curl" command output, by viewing the Response Headers in Developer Tools from any browser.

This can be found if you go the Developer Tools -> Select Network: * As you saw all the links to your resources , click on the top link domain name "noru.co.uk". * This will open your Headers which will give the same output as the curl command did example:

Accept-Ranges: bytes

Alt-Svc: quic=":443"; ma=2592000; v="35,37,38,39"

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Content-Encoding: gzip

Content-Length: 3152

Content-Type: text/html; charset=utf-8

Date: Tue, 20 Mar 2018 06:37:04 GMT

Etag: "7073226-1521527798;gz"

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Pragma: no-cache

Server: LiteSpeed

Vary: Accept-Encoding

X-Firefox-Spdy: h2

charset: utf-8

x-litespeed-cache: hit,private

x-powered-by: Craft CMS

This will give you most of the information of your configuration to your web pages of that domain.

I hope this helped, if you have any other concerns, please don't hesitate to contact us as I would gladly further assist.


I'll see if I can summarize what happened to me and maybe this will help someone.

Did the initial setup of the S3. Setup CORS but did not have Content-Length added. Did the initial setup of CloudFront. Did not check Compress.

Everything deploys.

Run a GTMetrix test on the domain and get a F for gzip.

Go back and google what to do to make it work. Realize I need Content-Length header <AllowedHeader>Content-Length</AllowedHeader> and realize I need to go back to CloudFront and check compress on the Distribution.

But... you also need to invalidate your cache. Essentially all the assets were coming back 304 (Not modified). So you won't get your gzipped assets.

Distribution, Edit, Invalidations, create * and go.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.