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