通过 S3 从 Amazon CloudFront 提供压缩的 CSS 和 JavaScript [英] Serving gzipped CSS and JavaScript from Amazon CloudFront via S3

问题描述

我一直在寻找加快网站加载速度的方法，我想探索的一种方法是更多地利用 Cloudfront.

因为 Cloudfront 最初不是作为自定义源 CDN 设计的，并且因为它不支持 gzip，所以到目前为止我一直使用它来托管我的所有图像，这些图像在我的站点代码中由它们的 Cloudfront cname 引用，并且使用远期标题进行了优化.

另一方面，CSS 和 javascript 文件托管在我自己的服务器上，因为直到现在我的印象是无法从 Cloudfront 提供 gzip 文件，并且 gzipping 的收益(大约 75%) 超过使用 CDN(大约 50%):Amazon S3(以及 Cloudfront)不支持通过使用浏览器发送的 HTTP Accept-Encoding 标头以标准方式提供 gzipped 内容，以表明他们对 gzip 的支持压缩，因此他们无法即时压缩和提供组件.

因此，直到现在，我的印象是，必须在两种选择之间做出选择:

1. 将所有资产移至 Amazon CloudFront 并忘记 GZipping；

2. 保持组件自托管并配置我们的服务器以检测传入请求并根据需要执行动态 GZIP 压缩，这是我目前选择的做法.

有变通方法来解决这个问题，但基本上这些不起作用.[链接].

现在，Amazon Cloudfront 似乎支持自定义源，并且如果您使用的是自定义源，现在可以使用标准的 HTTP 接受编码方法来提供 gzipped 内容 [link].>

到目前为止，我还没有能够在我的服务器上实现新功能.我在上面链接的博客文章是我发现的唯一一篇详细介绍更改的博客文章，似乎暗示您只能启用 gzipping(我不想使用的条形解决方法)，如果您选择自定义来源，我宁愿不这样做:我发现在我的 Cloudfront 服务器上托管相应的文件并从那里链接到它们更简单.尽管仔细阅读了文档，但我不知道:

• 新功能是否意味着文件应该通过自定义源托管在我自己的域服务器上，如果是，什么代码设置将实现这一点；

• 如何配置 css 和 javascript 标头以确保它们是从 Cloudfront 以 gzip 格式提供的.

解决方案

更新: Amazon 现在支持 gzip 压缩，因此不再需要.亚马逊公告

原答案:

答案是对 CSS 和 JavaScript 文件进行 gzip.是的，你没看错.

gzip -9 production.min.css

这将产生 production.min.css.gz.删除 .gz，上传到 S3(或您使用的任何源服务器)并将文件的 Content-Encoding 标头显式设置为 gzip.

它不是动态 gzip 压缩，但您可以非常轻松地将其打包到您的构建/部署脚本中.优点是:

1. Apache 在请求文件时对内容进行 gzip 不需要 CPU.
2. 文件以最高压缩级别进行 gzip 压缩(假设 gzip -9).
3. 您正在通过 CDN 提供文件.

假设您的 CSS/JavaScript 文件 (a) 已缩小且 (b) 大到足以证明在用户计算机上解压缩所需的 CPU 是合理的，您可以在此处获得显着的性能提升.

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

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.

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.

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.

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;

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.

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].

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. 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.

解决方案

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

Original answer:

The answer is to gzip the CSS and JavaScript files. Yes, you read that right.

gzip -9 production.min.css

This will produce 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.

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

1. It requires no CPU for Apache to gzip the content when the file is requested.
2. The files are gzipped at the highest compression level (assuming gzip -9).
3. You're serving the file from a 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.

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.

这篇关于通过 S3 从 Amazon CloudFront 提供压缩的 CSS 和 JavaScript的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！