收盘前$ .ready（） [英] $.ready() before closing body
问题描述
这不是一个真正的编码问题，更像是一个现实世界的陈述。
This is not a real coding question, more of a real-world statement.
我之前已经注意到 DOMReady 事件很慢，很慢。因此，我注意到在浏览jQuery源代码时，可以使用 $ .ready（）触发jQuery domeready事件。然后我想，在关闭正文之前放置这个简单的执行脚本应该触发所有先前附加的onDomReady监听器。是的，它按预期工作：
I have previously noted that DOMReady events are slow, very slow. So, I noticed while browsing the jQuery source that the jQuery domeready event can be trigger using $.ready(). Then I thought, placing this simple execution script just before closing the body should trigger all the "onDomReady" listeners that where previoulsy attached. And yes, it works as expected:
<script>$.ready()</script>
</body>
以下是两个示例，这个示例衡量等待DOMReady时花费的ms：
Here are two examples, this one measures the ms spent while waiting for DOMReady:
正如您所看到的，DOMReady触发器本身非常慢，用户必须在domready脚本启动之前等待整整200-300毫秒。
As you can see, the DOMReady trigger is very natively slow, the user has to wait for a whole 200-300 milliseconds before the domready script kick in.
无论如何，如果我们在关闭 BODY $。ready（） c>标签我们得到这个：
Anyway, if we place $.ready() just before closing the BODY tag we get this:
看到区别？通过手动触发domready，我们可以切断100-300 ms的执行延迟。这是一个重要的交易，因为在我们看到它们之前我们可以依赖jQuery来处理DOM操作。
See the difference? By triggering domready manually, we can cut off 100-300 ms of execution delay. This is a major deal, because we can rely on jQuery to take care of DOM manipulations before we see them.
现在，对于一个问题，我从未见过这个问题。以前推荐或讨论过，但它似乎仍然是一个主要的性能问题。一切都是关于优化代码本身的，这当然是好的，但是如果执行被延迟了很长时间以至于用户看到闪存unjQueryedContent那么就是徒劳。
Now, to a question, I have never seen this being recommended or discussed before, but still it seems like a major performance issue. Everything is about optimizing the code itself, which is good of course, but it is in vain if the execution is delayed for such a long time that the user sees a "flash of "unjQueryedContent".
为什么不经常讨论/推荐这个？
Any ideas why this is not discussed/recommended more frequently?
推荐答案
有没有想过为什么不经常讨论/推荐这个？
Any ideas why this is not discussed/recommended more frequently?
在< / body>之前放置JavaScript 已经讨论了很多，如你所知，如果你正在寻找更快的页面加载，建议你手动触发jQuery ready 处理程序。事实上讨论得不好。为什么？嗯，我认为没有一个单一的客观答案，但我会在这里概述一些可能性：
Placing JavaScript just before </body> has been discussed a lot, and as you know it's recommended if you're looking for faster page loads. Manually triggering the jQuery ready handlers is in fact poorly discussed. Why? Well, I don't think there is one single objective answer to that, but I'll try to outline some possibilities here:
-
性能不是jQuery的主要目标（嗯它绝对是一个问题），性能怪胎通常会寻找用于跨浏览器DOM操作和事件处理的较轻的库，或者自己编写。
Performance is not the main goal of jQuery (anthough it's definitely a concern), and performance freaks will usually look for lighter libraries for cross-browser DOM manipulation and event handling, or roll their own.
这是一个额外的步骤，它看起来不干净。 jQuery试图保持干净和优雅，并建议一个额外的步骤来初始化脚本听起来不像是会发生的事情。他们建议绑定到 ready ，因此建议强制 .ready（）并忽略实际的浏览器事件看起来错误 。无论谁担心这可能都知道在< / body> 之前初始化脚本的速度更快。
It's an extra step, and it doesn't look clean. jQuery tries to be clean and elegant, and recommending an extra step to initialize scripts doesn't sound like something that's gonna happen. They recommend binding to ready, so recommending to force .ready() and ignoring the actual browser event looks "wrong". Whoever is concerned about that probably knows that initializing scripts right before </body> is faster.
优化 DOMContentLoaded 听起来像浏览器供应商的任务。我不知道为什么它会慢一点，也许没有太多的优化空间–在我的理解中，在< / body> 之前调用init脚本应始终是初始化内容的最快方法（因为它在解析容器时立即执行 < script> 标记，而浏览器必须在触发 DOMContentLoaded 之前完成解析整个文件。
Optimizing DOMContentLoaded sounds like a task for browser vendors. I'm not sure why it's slower, though, and maybe there's not much room for optimization – in my understanding, calling init scripts before </body> should always be the fastest way to initialize stuff (as it's executed immediately when parsing the container <script> tag, while browsers must finish parsing the whole file before triggering DOMContentLoaded).
您可能还记得不久前通常的做法是将< script> 块分散到处在HTML上。然后Web标准运动来了，并建议更多理智和可维护的方式来做事。这包括从一个地方引导脚本–最初， window.onload ，然后被认为是慢的问题，然后是 DOMContentLoaded 及其对IE8及以下版本的仿真。但是，我们仍然在StackOverflow上每天都看到带有脚本的spaghetti-HTML。所以我不确定今天是否建议在正文结束前放置脚本是一个很好的调用，因为它可能被解释为在正文中的任何地方添加脚本的许可。
You probably remember that not so long ago it was common practice to have <script> blocks scattered everywhere on the HTML. Then the Web Standards movement came, and recommended more sane and maintanable ways to do things. That included bootstraping scripts from a single place – initially, window.onload, which was then considered problematic for being slow, then DOMContentLoaded and its emulations for IE8 and below. However, we still see spaghetti-HTML with scripts everywhere on a daily basis here on StackOverflow. So I'm not sure if recommending placing scripts before the end of the body is a good call today, because it may be interpreted as a license to add scripts anywhere within the body.
最后，如果您真的担心快速加载脚本，并且您的代码没有操作DOM，那么加载它的最快方法是将它放在< head> 在任何样式表之前。我只是说，没有灵丹妙药，没有最佳方式来初始化脚本，这是每个场景中最快，最优雅的。我认为这就是为什么社区坚持推荐一些看起来很健全并且往往会创建更易维护的代码的原因，而不是其他更好的代码。
Finally, if you're really concerned about loading your script fast, and your code does not manipulate the DOM, the fastest way to load it is to put it in the <head> before any stylesheets. And I'm stating that just to say that there's no silver bullet, no optimal way to init scripts that is the fastest and most elegant in every scenario. I think that's why the community sticks with recommending something that looks sane and tends to create more maintainable code, instead of other better performing alternatives.
这篇关于收盘前$ .ready（）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
