这不是一个真正的编码问题，而是一个现实世界的陈述。
我之前noted DOMReady事件缓慢，非常缓慢。所以，我在浏览jQuery源时注意到可以使用$.ready()触发jQuery domeready事件。然后我想，在关闭正文之前放置这个简单的执行脚本应该触发所有先前附加的“onDomReady”监听器。是的，它按预期工作：
<script>$.ready()</script>
</body>
以下是两个示例，这个示例测量等待DOMReady时花费的ms：
正如您所看到的，DOMReady触发器本身非常慢，用户必须在domready脚本启动之前等待整整200-300毫秒。
无论如何，如果我们在关闭$.ready()代码之前放置BODY，我们就会知道：
看到区别？通过手动触发domready，我们可以切断100-300 ms的执行延迟。这是一个重要的交易，因为在我们看到它们之前，我们可以依赖jQuery来处理DOM操作。
现在，对于一个问题，我从未见过这个被推荐或讨论过，但它似乎仍然是一个主要的性能问题。一切都是关于优化代码本身的，当然这很好，但是如果执行被延迟了很长时间，以至于用户看到“flash of”unjQueryedContent“，那就徒劳无功了。”
为什么不经常讨论/推荐这个想法？
答案 0 :(得分：4)
通过自己触发事件，你向你的ready（）处理程序说明你的dom已被加载但它可能不是！没有简短的切入DOM就绪事件。如果确实有很长的等待时间，那么就使用萤火虫，铬等的惊人的调试工具....检查你的资源和他们的时间问题。所有这些都是黑白的，并指出需要这么长时间（请求，渲染，有多少资源等）。
答案 1 :(得分：3)
实际上，在</body>标记之前放置一个函数调用使得使用jQuery ready()毫无意义。只需将本机JS-wrapper函数调用包含在文档准备就绪时应调用的所有其他函数的调用。
一般来说，当作者根本不需要/想要使用jQuery时，它是一种工作（虽然有点乱抛垃圾的HTML代码，因此对于完美主义者来说是不可接受的）。在这种情况下，我更喜欢使用大多数浏览器支持的本地DOMContentLoaded事件处理程序，包括IE9 +（对于IE8-我们可以使用window.load()作为可接受的后备）。
答案 2 :(得分：3)
为什么不经常讨论/推荐这个想法？
在</body>之前放置JavaScript已被大量讨论，如您所知，如果您正在寻找更快的页面加载，建议您使用它。事实上，手动触发jQuery ready处理程序的讨论很少。为什么？好吧，我认为没有一个客观的答案，但我会在这里概述一些可能性：
性能不是jQuery的主要目标（嗯它绝对是一个问题），性能怪胎通常会寻找更轻的库来进行跨浏览器的DOM操作和事件处理，或者滚动他们自己的。
这是一个额外的步骤，它看起来不干净。 jQuery试图保持干净和优雅，并建议一个额外的步骤来初始化脚本听起来不像是会发生的事情。他们建议绑定到ready，因此建议强制.ready()并忽略实际的浏览器事件看起来“错误”。无论谁担心这一点，都可能知道在</body>之前初始化脚本的速度更快。
优化DOMContentLoaded听起来像浏览器供应商的任务。我不知道为什么它会慢一些，也许没有太多的优化空间 - 在我的理解中，在</body>之前调用init脚本应该始终是初始化东西的最快方法（因为它在解析时立即执行）容器<script>标记，而浏览器必须在触发DOMContentLoaded之前完成解析整个文件。
您可能还记得，不久前通常的做法是在HTML上的任何地方散布<script>块。然后Web标准运动来了，并建议更多理智和可维护的方式来做事。这包括从一个地方引导脚本 - 最初是window.onload，然后被认为是慢的问题，然后是DOMContentLoaded及其对IE8及以下的模拟。但是，我们仍然在StackOverflow上每天都看到带有脚本的spaghetti-HTML。所以我不确定今天是否建议在正文结束前放置脚本是一个很好的调用，因为它可能被解释为在正文中任何地方添加脚本的许可。
最后，如果您真的担心快速加载脚本，并且您的代码没有操作DOM，那么加载它的最快方法是在任何样式表之前将其放在<head>中。我只是说，没有灵丹妙药，没有最佳方式来初始化脚本，这是每个场景中最快，最优雅的。我认为这就是为什么社区坚持推荐一些看起来很健全的东西，并且倾向于创建更易于维护的代码，而不是其他更好的替代方案。