使用 DOMContentReady 被 Google 视为反模式

Question

一位 Google Closure 库团队成员断言正在等待对于 DOMContentReady 事件来说是一个不好的做法。

简短的故事是我们不想要 等待 DOMContentReady （或者更糟 加载事件），因为它会导致不良 用户体验。用户界面不是 响应直到所有 DOM 都已响应 从网络加载。所以 首选方法是使用内联脚本 尽快。

由于他们仍然没有提供更多详细信息，所以我想知道他们如何处理 操作中止 对话框。该对话框是我所知道的等待 DOMContentReady（或加载）事件的唯一关键原因。

1. 你还知道其他原因吗？
2. 您认为他们如何处理 IE 问题？

Answer 1

首先稍微解释一下：内联 JavaScript 的要点是尽快包含它。然而，这个“可能”取决于该脚本需要声明的 DOM 节点。例如，如果您有一些需要 JavaScript 的导航菜单，您可以在 HTML 中定义菜单后立即包含该脚本。

<ul id="some-nav-menu">
    <li>...</li>
    <li>...</li>
    <li>...</li>
</ul>
<script type="text/javascript">
    // Initialize menu behaviors and events
    magicMenuOfWonder( document.getElementById("some-nav-menu") );
</script>

只要您只处理已知已声明的 DOM 节点，就不会遇到 DOM 不可用问题。至于 IE 问题，开发人员必须策略性地包含他们的脚本，这样就不会发生这种情况。这其实并不是一个大问题，也不难解决。真正的问题是“大局”，如下所述。

当然，一切都有利有弊。

优点

1. 一旦 DOM 元素显示给用户，JavaScript 添加到其中的任何功能几乎立即可用（而不是等待加载整个页面）。
2. 在某些情况下，Pro #1 可以加快感知页面加载时间并改善用户体验。

缺点

1. 在最坏的情况下，您会混合演示文稿和业务逻辑，在最好的情况下，您会在整个演示文稿中混合包含脚本，这两者都可能难以管理。在我看来，以及社区的大部分人都不能接受。
2. 正如无眼睑指出的，如果脚本有问题有外部依赖项（例如库），那么必须首先加载这些依赖项，这将在解析和执行它们时锁定页面渲染。

我使用这种技术吗？不。我更喜欢在页面末尾加载所有脚本，就在结束 标记之前。几乎在每种情况下，对于效果和事件处理程序的感知和实际初始化性能来说，这都足够快。

其他人可以使用它吗？开发人员将做他们想要/需要的事情来完成工作并让他们的客户/老板/营销部门满意。权衡是存在的，只要您理解并管理它们，无论哪种方式都应该没问题。

Answer 2

内联脚本最大的问题是无法正确缓存。如果您将所有脚本存储在一个缩小的 js 文件中（使用编译器），则浏览器可以为整个站点缓存该文件一次。

如果您的网站往往很繁忙，从长远来看，这会带来更好的性能。为脚本使用单独的文件的另一个优点是，您往往不会“重复自己”并尽可能声明可重用的函数。 DOMContentReady 不会导致糟糕的用户体验。至少它预先为用户提供了内容，而不是让用户等待 UI 加载，这最终可能会让用户感到厌烦。

此外，使用内联脚本并不能确保 UI 比与 DOMContentReady 一起使用时的响应速度更快。想象一下您使用内联脚本进行 ajax 调用的场景。如果您有一张表格提交即可。有多个表单，您最终会重复 ajax 调用..因此每次都会重复相同的脚本。最终，它会导致浏览器缓存更多的 javascript 代码，而不是在 DOM 准备好时将其分离到加载的 js 文件中。

内联脚本的另一个大缺点是您需要维护两个独立的代码库：一个用于开发，另一个用于生产。您必须确保两个代码库保持同步。开发版本包含代码的非缩小版本，生产版本包含缩小版本。这是开发周期中的一大难题。您必须手动将隐藏在那些庞大的 html 文件中的所有代码片段替换为缩小版本，并最终希望没有代码中断！但是，通过在开发周期中维护单独的文件，您只需将该文件替换为生产代码库中已编译的缩小版本即可。

如果你使用 YSlow 你会看到：

使用外部 JavaScript 和 CSS
文件通常会产生更快的页面
因为文件被缓存了
浏览器。 JavaScript 和 CSS 分别是
内联在 HTML 文档中获取
每次下载 HTML 文档
被要求。这减少了数量
HTTP 请求但增加了
HTML 文档大小。另一方面，
如果 JavaScript 和 CSS 位于
浏览器缓存的外部文件，
HTML 文档大小减小
不增加HTTP数量
请求。

当且仅当代码更改如此频繁以至于将其放在单独的 js 文件中并不重要并且最终会产生与这些内联脚本相同的影响时，我才能保证内联脚本。不过，浏览器不会缓存这些脚本。浏览器缓存脚本的唯一方法是将其存储在带有 etag。

然而，这绝不是 JQuery 与 Google 的终结。封闭有其自身的优点。然而，闭包库使得将所有脚本都放在外部文件中变得很困难（尽管这并不是不可能，只是让它变得困难）。您只是倾向于使用内联脚本。

Answer 3

避免内联脚本的原因之一是，它要求您在文档中将任何依赖库放在它们之前，这可能会抵消内联脚本的性能提升。我熟悉的最佳实践是将所有脚本（在单个 HTTP 请求中！）放在文档的最后，就在 之前。这是因为脚本加载会阻塞当前请求和所有子请求，直到脚本完全加载、解析和执行。

由于缺乏魔杖，我们总是不得不做出这些权衡。值得庆幸的是，HTML 文档本身将越来越成为资源密集程度最低的请求（除非您正在做一些愚蠢的事情，例如巨大的 data: URL 和巨大的内联 SVG 文档）。对我来说，等待 HTML 文档结束的权衡似乎是最明显的选择。

Answer 4

我认为这个建议并没有多大帮助。 DOMContentReady 可能只是不好的做法，因为它目前被过度使用（可能是因为 jquery 易于使用的就绪事件）。许多人将其用作任何 javascript 操作的“启动”事件。尽管 jQuery 的 read() 事件也只是用作 DOM 操作的启动点。

推论，页面加载时的 DOM 操作会导致糟糕的用户体验！因为它们不是必需的，服务器端可以完全生成初始页面。

那么，也许关闭团队成员只是试图朝相反的方向前进，并阻止人们在页面加载时进行 DOM 操作？

Answer 5

如果在不考虑图像加载的情况下解析、加载和渲染布局（domready 应该触发的点）花费的时间太长，以至于导致明显的 UI 延迟，那么您可能在构建该页面时遇到了一些非常难看的事情后端，这才是你真正的问题。

此外，页面结束之前的 JavaScript 会暂停 HTML 解析/DOM 评估，直到 JS 被解析和评估。在给出有关 JavaScript 的建议之前，Google 应该先看看他们的 Java。

Answer 6

如果你需要自己处理你的HTML，谷歌的方法似乎很尴尬。他们使用编译的方法，可能会在其他问题上浪费他们的大脑周期，考虑到他们的应用程序的复杂用户界面，这是理智的。如果您追求要求更宽松的东西（阅读：几乎所有其他东西），也许不值得付出努力。

但遗憾的是 GWT 只谈论 Java。

Answer 7

这可能是因为 Google 并不关心你是否有 Javascript，他们所做的几乎所有事情都需要它。如果您在已经运行的网站之上使用 Javascript 作为补充，那么在 DOMContentReady 中加载脚本就可以了。重点是使用 Javascript 来增强用户体验，而不是在用户没有 JavaScript 的情况下将他们隔离开来。