6

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

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

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

4

3 回答 3

2

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

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

在我看来，有一个转折点，你应该<head>你的资产还是不<head>你的资产。如果您的 JS/CSS 资产可以在您的服务器准备好其余响应之前下载，这只是一个净性能提升。

在以下情况下不要<head>页面的资产：

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

在以下情况下执行 <head> 页面资产：

  • 您的服务器响应所需的时间比在等待时加载所有 JS/CSS 资产所需的时间更长

那个听起来是对的吗？

于 2011-06-16T18:24:30.953 回答
2

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

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

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

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

于 2011-06-16T19:04:30.247 回答
1

主观问题的主观回答：

  • 库（和 head 中的函数定义），全部作为静态资产提供，因此可以缓存。
  • 在脚本块的页面底部“触发”回调等。
于 2011-05-24T20:34:53.080 回答