javascript - 通过S3从Amazon CloudFront提供gzip CSS和JavaScript(Serving gzipped CSS and JavaScript from Amazon CloudFront via S3)

Question

I've been looking for ways of making my site load faster and one way that I'd like to explore is making greater use of Cloudfront.

(我一直在寻找让我的网站加载更快的方法，我想探索的一种方法是更多地使用Cloudfront。)

Because Cloudfront was originally not designed as a custom-origin CDN and because it didn't support gzipping, I have so far been using it to host all my images, which are referenced by their Cloudfront cname in my site code, and optimized with far-futures headers.

(因为Cloudfront最初并非设计为自定义源CDN，并且因为它不支持gzipping，所以到目前为止我一直使用它来托管我的所有图像，这些图像在我的站点代码中由他们的Cloudfront cname引用，并且远远优化了-futures标题。)

CSS and javascript files, on the other hand, are hosted on my own server, because until now I was under the impression that they couldn't be served gzipped from Cloudfront, and that the gain from gzipping (about 75 per cent) outweighs that from using a CDN (about 50 per cent): Amazon S3 (and thus Cloudfront) did not support serving gzipped content in a standard manner by using the HTTP Accept-Encoding header that is sent by browsers to indicate their support for gzip compression, and so they were not able to Gzip and serve components on the fly.

(另一方面，CSS和javascript文件托管在我自己的服务器上，因为直到现在我的印象是他们无法从Cloudfront gzip服务，并且gzipping（大约75％）的收益超过了使用CDN（约50％）：Amazon S3（以及Cloudfront）不支持使用浏览器发送的HTTP Accept-Encoding标头以标准方式提供gzip压缩内容，以表明它们支持gzip压缩，以及所以他们无法动态地使用Gzip和服务组件。)

Thus I was under the impression, until now, that one had to choose between two alternatives:

(因此，直到现在，我仍然不得不在两种选择之间做出选择：)

1. move all assets to the Amazon CloudFront and forget about GZipping;

   (将所有资产移至Amazon CloudFront并忘记GZipping;)

2. keep components self-hosted and configure our server to detect incoming requests and perform on-the-fly GZipping as appropriate, which is what I chose to do so far.

   (保持组件自托管并配置我们的服务器以检测传入请求并在适当时执行动态GZipping，这是我到目前为止所做的。)

There were workarounds to solve this issue, but essentially these didn't work .

(有变通方法来解决这个问题，但本质上这些没有工作 。)

[ link ].

([ 链接 ]。)

Now, it seems Amazon Cloudfront supports custom origin, and that it is now possible to use the standard HTTP Accept-Encoding method for serving gzipped content if you are using a Custom Origin [ link ].

(现在，似乎Amazon Cloudfront支持自定义源，并且如果您使用自定义源 [ 链接 ]， 现在可以使用标准HTTP Accept-Encoding方法来提供gzip压缩内容 。)

I haven't so far been able to implement the new feature on my server.

(到目前为止，我还没有能够在我的服务器上实现新功能。)

The blog post I linked to above, which is the only one I found detailing the change, seems to imply that you can only enable gzipping (bar workarounds, which I don't want to use), if you opt for custom origin, which I'd rather not: I find it simpler to host the coresponding fileds on my Cloudfront server, and link to them from there.

(我上面链接的博客文章，这是我发现的唯一一个详细说明变更的博客文章，似乎暗示你只能启用gzipping（条形图解决方法，我不想使用），如果你选择自定义来源，我宁愿不这样做：我发现在我的Cloudfront服务器上托管相应的文件更简单，并从那里链接到它们。)

Despite carefully reading the documentation, I don't know:

(尽管仔细阅读文档，但我不知道：)

• whether the new feature means the files should be hosted on my own domain server via custom origin, and if so, what code setup will achieve this;

  (新功能是否意味着文件应该通过自定义源托管在我自己的域服务器上 ，如果是，那么代码设置将实现此目的;)

• how to configure the css and javascript headers to make sure they are served gzipped from Cloudfront.

  (如何配置css和javascript标头以确保它们是从Cloudfront gzip中提供的。)

  ask by Donald Jenkins translate from so

Answer 1

UPDATE: Amazon now supports gzip compression, so this is no longer needed.

(更新：亚马逊现在支持gzip压缩，因此不再需要。)

Amazon Announcement

(亚马逊公告)

Original answer:

(原始答案：)

The answer is to gzip the CSS and JavaScript files.

(答案是gzip CSS和JavaScript文件。)

Yes, you read that right.

(是的，你没有看错。)

gzip -9 production.min.css

This will produce production.min.css.gz .

(这将生成production.min.css.gz 。)

Remove the .gz , upload to S3 (or whatever origin server you're using) and explicitly set the Content-Encoding header for the file to gzip .

(删除.gz ，上传到S3（或您正在使用的.gz服务器），并将文件的Content-Encoding标头显式设置为gzip 。)

It's not on-the-fly gzipping, but you could very easily wrap it up into your build/deployment scripts.

(它不是即时的gzipping，但你可以很容易地将它包装到你的构建/部署脚本中。)

The advantages are:

(优点是：)

1. It requires no CPU for Apache to gzip the content when the file is requested.

   (在请求文件时，Apache不需要CPU来gzip内容。)

2. The files are gzipped at the highest compression level (assuming gzip -9 ).

   (文件在最高压缩级别进行gzip -9压缩（假设为gzip -9 ）。)

3. You're serving the file from a CDN.

   (您正在从CDN提供该文件。)

Assuming that your CSS/JavaScript files are (a) minified and (b) large enough to justify the CPU required to decompress on the user's machine, you can get significant performance gains here.

(假设你的CSS / JavaScript文件被缩小（b）大到足以证明在用户机器上解压缩所需的CPU，你可以在这里获得显着的性能提升。)

Just remember: If you make a change to a file that is cached in CloudFront, make sure you invalidate the cache after making this type of change.

(请记住：如果您对在CloudFront中缓存的文件进行了更改，请确保在进行此类更改后使缓存无效。)