指南是我写的。
您肯定不想活在生产中编译。
当您进行编译时,会发生这样的情况:
对/Asset中的文件的每个请求都传递给链轮。在第一在Rails用于缓存(通常是文件系统)的任何资源中编译和缓存每个资产的请求。
在随后的请求中,链轮接收到请求,并必须查找指纹文件名,检查构成资产的文件(图像)或文件(CSS和js)没有被修改,如果存在缓存版本,则提供该文件。
那是一切在“资产”文件夹中和在插件使用的任何供应商/资产文件夹中。
这是很大的开销,因为,老实说,代码并不是为了速度而优化的。
这将对资产传输到客户端的速度产生影响,并会对站点的页面加载时间产生负面影响。
与默认情况相比:
当资产预编译和编译关闭时,将对资产进行编译,并将其指纹到public/assets
..链轮将普通文件名到指纹文件名的映射表返回给Rails,Rails将其写入文件系统。清单文件(Rails 3中的yml或Rails 4中具有随机名称的JSON)在启动时由Rails加载到内存中,并被缓存以供资产助手方法使用。
这使得具有正确指纹资产的页面生成非常快,而文件本身的服务则是从文件系统中快速生成Web服务器。两者都比实时编译快得多。
要获得管道和指纹的最大优势,您需要在Web服务器上设置未来的头文件,并为js和css文件启用gzip压缩。链轮编写gzip版本的资产,您可以设置您的服务器使用,消除了它这样做的需要,为每个请求。
这将尽可能快地将资产分发给客户端,并且在尽可能小的大小下,加快页面的客户端显示速度,并减少(具有遥远未来的头)请求。
因此,如果您正在进行实时编译,则如下所示:
- 很慢
- 缺乏压缩
- 将影响页的呈现时间。
对决
- 越快越好
- 压缩
- 删除从服务器无意中听到的压缩(可选)。
- 尽量减少页面的呈现时间。
编辑:(回复后续评论)
管道能更改为在第一个请求时预编译,但这样做有一些主要障碍。首先,必须有一个查表来查找指纹名称,否则助手方法太慢。在按需编译的情况下,在编译或请求每个新资产时,需要有一些方式来附加到查找表。
此外,在所有资产汇编到位之前,有些人将不得不在一段未知的时期内支付缓慢交付资产的代价。
默认情况下,编译所有内容的代价是一次性支付的,它不会影响公众访问者,并确保一切在事情开始运行之前都能正常工作。
打破这一协议的原因是,它给生产系统增加了许多复杂性。
如果您正在阅读这篇文章,因为您正在为部署过程中的缓慢编译时间寻找解决方案,那么您可以考虑在本地预编译这些资产。有关这方面的信息,请参阅资产管道指南..这允许您只在发生更改时在本地预编译,提交该更改,然后在没有预编译阶段的情况下进行快速部署。