Rails 3.1 http streaming - 身体头部或底部的js？

Question

在Rails 3.1中，可以选择启用HTTP流，以便您的页面可以放在一起。在关于此功能的Railscast中，Ryan建议最好启用此功能，以便在页面的其余部分仍然呈现时可以拉下CSS和JavaScript。

我始终遵循指南，即在加载所有页面内容后脚本应位于页面底部，这样可以减少感知的加载时间，但这样做不会利用HTTP流。

您认为现在的最佳做法是什么？

Answer 1

我认为这是一个很好的问题;我觉得有必要向谷歌寻求答案。

将脚本资源放在页面底部的论点是为了防止阻止浏览器的渲染器，否则可能会在屏幕上绘制像素，以便在加载页面的其余部分时保持用户忙碌。通过HTTP流式传输，我们谈论的是能够做一些关于服务器作为瓶颈的事情。当我们等待所有昂贵的数据库查询和后端服务调用完成时，我们可以加载JS / CSS资产。

在我看来，有一个临界点你应该＆lt; head＆gt;您的资产与否＆lt; head＆gt;你的资产。如果你的JS / CSS资产可以在之前下载你的服务器已准备好其余的响应，那么这只是一个净的性能提升。

不要＆lt; head＆gt;页面的资产如果：

• 您正在从服务器端缓存中提供页面
• 您的服务器响应时间比JS / CSS'实际资产加载时间快（计算加载时间时，请仔细考虑这些资产是否可能已在客户端缓存） ）

做＆lt; head＆gt;页面的资产如果：

• 您的服务器需要更长时间来响应，而不是在等待时加载所有JS / CSS资产

这听起来是对的吗？

Answer 2

对于一般情况，我认为不幸的是他们仍然会走到谷底。原因是Safari for Mac在开始发出资产请求之前缓冲1024个字节（而iPhone和iPad的Safari缓冲区为512个字节）。

由于文档的头部通常较小，因此Safari用户仍会获得普通的糟糕体验。

根据我与Hongli Lai一起完成的一些测试，Firefox，Opera和IE8没有缓冲，Chrome缓冲了252个字节。

我仍在研究这个问题，但在撰写本文时，这是我的结论。

Answer 3

对主观问题的主观回答：

• 库（以及头部中的函数定义），全部作为静态资产提供，因此可以缓存它们。
• '触发'到脚本块中页面底部的回调等。