我一直在寻找让我的网站加载更快的方法,我想探索的一种方法是更多地使用Cloudfront .
因为Cloudfront最初并非设计为自定义源CDN,并且因为它不支持gzipping,所以到目前为止我一直使用它来托管我的所有图像,这些图像在我的站点代码中由他们的Cloudfront cname引用,并且远远优化了-futures Headers .
另一方面,CSS和javascript文件托管在我自己的服务器上,因为直到现在我的印象是他们无法从Cloudfront gzip服务,并且gzipping(大约75%)的收益超过了使用CDN(约50%):Amazon S3(以及Cloudfront)不支持使用浏览器发送的HTTP Accept-Encoding标头以标准方式提供gzip压缩内容,以表明它们支持gzip压缩,以及所以他们无法动态地使用Gzip和服务组件 .
因此,直到现在,我仍然不得不在两种选择之间做出选择:
-
将所有资产移至Amazon CloudFront并忘记GZipping;
-
保持组件自托管并配置我们的服务器以检测传入请求并在适当时执行动态GZipping,这是我到目前为止所做的 .
有解决这个问题的解决方法,但基本上是这些 didn't work . [link] .
现在,似乎Amazon Cloudfront支持自定义源,并且 it is now possible to use the standard HTTP Accept-Encoding method for serving gzipped content if you are using a Custom Origin [link] .
到目前为止,我还没有能够在我的服务器上实现新功能 . 我上面链接的博客文章是我发现的唯一详细说明变更的博客文章,似乎暗示你只能启用gzipping(bar变通办法,我不想使用),如果你选择自定义原点,我宁愿不这样做:我发现在我的Cloudfront服务器上托管相应的文件更简单,并从那里链接到它们 . 尽管仔细阅读了文档,但我不知道:
-
新功能是否意味着文件应该通过自定义源托管在我自己的域服务器上,如果是,那么代码设置将实现此目的;
-
如何配置css和javascript标头以确保它们是从Cloudfront gzip中提供的 .
6 回答
我的答案是对此的启动:http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html
Build Skyler 's answer you can upload a gzip and non-gzip version of the css and js. Be careful naming and test in Safari. Because safari won' t处理
.css.gz
或.js.gz
文件 .site.js
和site.js.jgz
以及site.css
和site.gz.css
(您需要将content-encoding
标头设置为正确的MIME类型才能使这些服务正确)然后在你的页面中 .
gzipcheck.js.jgz只是
sr_gzipEnabled = true;
这个测试确保浏览器可以处理gzip压缩代码并提供备份,如果他们不能 .然后在页脚中执行类似的操作,假设所有js都在一个文件中,并且可以进入页脚 .
UPDATE: 亚马逊现在支持gzip压缩 . 公告,所以不再需要 . Amazon Announcement
昨天亚马逊发布了新功能,你现在可以在你的发行版上启用gzip了 .
它适用于s3而没有自己添加.gz文件,我今天尝试了新功能并且效果很好 . (虽然需要使你的当前对象无效)
More info
我们还整合了一个在CloudFront和S3之间代理以压缩内容的Heroku应用程序:http://dfl8.co
鉴于可以使用简单的URL结构访问可公开访问的S3对象,http://dfl8.co只使用相同的结构 . 即以下网址是等效的:
Cloudfront支持gzipping .
Cloudfront通过HTTP 1.0连接到您的服务器 . 默认情况下,某些Web服务器(包括nginx)不会将gzip压缩内容提供给HTTP 1.0连接,但您可以通过添加以下内容来告诉它:
到你的nginx配置 . 可以为您正在使用的任何Web服务器设置等效配置 .
这确实会产生副作用,使得保持活动连接不适用于HTTP 1.0连接,但由于压缩的好处是巨大的,所以绝对值得权衡 .
摘自http://www.cdnplanet.com/blog/gzip-nginx-cloudfront/
Edit
提供通过亚马逊 Cloud 前端动态压缩的内容是危险的,可能不应该这样做 . 基本上,如果您的网络服务器正在压缩内容,它将不会设置内容长度,而是将数据作为分块发送 .
如果Cloudfront与您的服务器之间的连接中断并过早切断,Cloudfront仍会缓存部分结果并将其作为缓存版本提供,直至其过期 .
接受的首先在磁盘上压缩然后提供gzip压缩版本的答案是一个更好的想法,因为Nginx将能够设置Content-Length标头,因此Cloudfront将丢弃截断版本 .
您可以将CloudFront配置为自动压缩某些类型的文件并提供压缩文件 .
请参阅AWS Developer Guide
UPDATE: 亚马逊现在支持gzip压缩,因此不再需要它 . Amazon Announcement
原始答案:
答案是gzip CSS和JavaScript文件 . 是的,你没有看错 .
这将产生
production.min.css.gz
. 删除.gz
,上传到S3(或您正在使用的任何源服务器)并将文件的Content-Encoding
标头显式设置为gzip
.它不是即时的gzipping,但你可以很容易地将它包装到你的构建/部署脚本中 . 优点是:
在请求文件时,Apache不需要CPU来gzip内容 .
文件以最高压缩级别进行gzip压缩(假设为
gzip -9
) .您正在从CDN提供该文件 .
假设你的CSS / JavaScript文件被缩小(b)大到足以证明在用户机器上解压缩所需的CPU,你可以在这里获得显着的性能提升 .
请记住:如果您对在CloudFront中缓存的文件进行了更改,请确保在进行此类更改后使缓存无效 .