Rails 3.1 http 流式传输——js 在头部还是底部？

Posted 2023-04-15

【中文标题】Rails 3.1 http 流式传输——js 在头部还是底部？

【英文标题】：Rails 3.1 http streaming -- js in head or bottom of body?

【发布时间】：2011-09-01 06:23:51

【问题描述】：

在 Rails 3.1 中，可以选择启用 HTTP 流，以便您的页面可以分块下载。在有关此功能的 Railscast 中，Ryan 建议启用此功能是一个好主意，这样您的 CSS 和 javascript 就可以在页面的其余部分仍在呈现时被拉下。

我一直遵循这样的指导方针，即在加载完所有页面内容后，脚本应该位于页面底部，这样可以减少感知的加载时间，但这样做不会利用 HTTP流媒体。

你认为现在最好的做法是什么？

【参考方案1】：

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

将脚本资源放在页面底部的理由是为了防止阻塞浏览器的渲染器，否则浏览器的渲染器可能会在屏幕上绘制像素，从而让用户在加载页面的其余功能时保持忙碌。对于 HTTP 流，我们谈论的是能够解决 服务器 成为瓶颈的问题。当我们等待所有那些昂贵的数据库查询和后端服务调用完成时，我们可以加载 JS/CSS 资产。

在我看来，有一个临界点，你应该

你的资产还是不你的资产。如果您的 JS/CSS 资产可以在您的服务器准备好其余响应之前下载，这只是净性能提升。

在以下情况下不要

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

如果满足以下条件，则执行

页面的资产： 您的服务器响应时间更长，而不是在等待期间加载所有 JS/CSS 资产

这听起来对吗？

【参考方案2】：

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

由于文档的头部通常较小，Safari 用户仍然会得到一般的糟糕体验。

Firefox、Opera、IE8 不缓冲，Chrome 缓冲 252 字节，根据我和赖宏利一起做的一些测试。

我仍在对此进行研究，但在撰写本文时，这是我的结论。

【参考方案3】：

对主观问题的主观回答：

库（和 head 中的函数定义），全部作为静态资产提供，因此可以缓存。 脚本块中页面底部的“触发器”回调等。