通过S3从Amazon CloudFront提供压缩的CSS和JavaScript

Question

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

由于Cloudfront最初不是设计为自定义CDN的，并且因为它不支持gziping，所以到目前为止，我一直使用它来托管我的所有图像，这些图像在我的站点代码中由它们的Cloudfront
cname引用，并经过了优化-futures标头。

另一方面，CSS和javascript文件托管在我自己的服务器上，因为到目前为止，我一直无法从Cloudfront中获得CSS和javascript文件的印象，而获得gzip压缩（大约75％）的收益超过了使用CDN（约占50％）：Amazon
S3（因此Cloudfront）不支持使用浏览器发送的HTTP Accept-
Encoding标头以标准方式提供压缩内容，以表明其支持gzip压缩，并且因此他们无法即时压缩和提供组件。

因此，直到现在，我的印象是，必须在两种选择之间进行选择：

1. 将所有资产移至Amazon CloudFront，而不必担心GZipping；

2. 保持组件自托管，并配置我们的服务器以检测传入的请求，并根据需要即时执行GZipping，这是我到目前为止选择的操作。

还有 人 变通办法来解决这个问题，但本质上这些 没有工作 。[ 链接 ]。

现在，Amazon Cloudfront似乎支持自定义来源，并且 如果您正在使用“自定义来源” link， 现在可以使用标准的HTTP Accept-Encoding方法来提供压缩后的内容 。

到目前为止，我还无法在服务器上实现新功能。我上面链接到的博客文章，这是我发现的唯一详细说明更改的文章，似乎暗示着，如果您选择自定义来源，则只能启用gziping（我不想使用的条形变通方法）。我宁愿不要：我发现将Coresponding的文件托管在Cloudfront服务器上并从那里链接到它们更简单。尽管仔细阅读了文档，但我不知道：

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

• 如何配置css和javascript标头，以确保从Cloudfront压缩后提供它们。

Answer 1

更新： Amazon现在支持gzip压缩，因此不再需要。

原始答案：

答案是gzip CSS和JavaScript文件。是的，你没看错。

gzip -9 production.min.css

这将产生production.min.css.gz。删除.gz，将其上传到S3（或您使用的任何原始服务器），然后Content- Encoding将文件的标头明确设置为gzip。

这不是即时的gzip压缩，但是您可以非常轻松地将其打包到构建/部署脚本中。优点是：

1. 请求文件时，Apache不需要CPU来gzip内容。
2. 这些文件以最高压缩级别压缩（假定为gzip -9）。
3. 您正在从CDN提供文件。

假设您的CSS / JavaScript文件经过（a）缩小和（b）足够大，足以证明在用户计算机上进行解压缩所需的CPU，那么您可以在此处获得显着的性能提升。

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