为什么推荐jQuery.ready这么慢? [英] Why is jQuery.ready recommended when it’s so slow?

查看:173
本文介绍了为什么推荐jQuery.ready这么慢?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我之前曾问过一个类似的问题,但我从未提出我的观点非常清楚,或者至少我认为这是一个相关的问题,值得提出来,看看是否有人可以提出一些有见地的想法.

I have asked a similar question before but I never made my point exactly clear, or at least I think it’s such a relevant question that it’s worth to bring it up and see if anyone can give some insightful thoughts.

使用jQuery时,我们中的许多人在加载DOM后使用jQuery.ready函数执行init.它已成为使用jQuery将DOM操作程序添加到网页的事实上的标准方法.某些浏览器存在本机,但是jQuery在其他浏览器中进行了模拟,例如某些IE版本.示例:

When using jQuery, many of us use the jQuery.ready function to execute an init when the DOM has loaded. It has become the de-facto standard way of adding DOM manipulation programs to a web page using jQuery. A related event exists natively some browsers, but jQuery emulates it in other browsers, such as some IE versions. Example:

<head>
<script>
    var init = function() { alert('hello world'); };
    $.ready(init);
</script>

现在,我们所有的测试都表明该事件可能非常缓慢.它的速度不及window.onload慢,但执行前通常仍要延迟100毫秒左右.如果设置为FF,则最长可达200​​-300毫秒,尤其是在刷新时.

Now, all our tests show that this event can be quite slow. It’s not nearly as slow as window.onload, but it’s still often around 100 ms delay before execution. If FF it can be up to 200-300 ms, especially on refresh.

这是一些非常重要的毫秒,因为这是在进行任何DOM操作(例如隐藏下拉菜单)之前显示初始布局的时间.很多时候,布局闪烁"主要是由于使用了慢速的DOM ready事件导致的,迫使程序员改而使用CSS隐藏元素,并可能使其难以访问.

These are some very important milliseconds, because this is the amount of time the initial layout is shown before any DOM manipulations are made (such as hiding a dropdown). Many times, a layout "flicker" is mainly caused by using a slow DOM ready event, forcing programmers to hide elements using CSS instead and potentially making it less accessible.

现在,如果我们在关闭body标签之前将init函数放置在script标签中,则它的执行速度将大大提高,通常会缩短一半的时间,但有时甚至会更快:

Now if we instead place an init function in a script tag before closing the body tag, it will be executed much faster, usually around half the time but sometimes even faster:

<head>
<script>
    var init = function() { alert('hello world'); };
</script>
</head>
<body>
<!-- some HTML -->
<script>init();</script>
</body>

一个证明差异的简单测试页面: http://jsbin.com/aqifon/10

A simple test page that proves the differences: http://jsbin.com/aqifon/10

我的意思是,我们并不是在谈论几乎没有什么明显的差异,因为在使用有效选择器时,某些优化策略"会促进这种差异.我们谈论的是在进行DOM操作加载时的一些主要延迟.在FF中尝试此示例,有时domready的速度可能会慢100倍以上(300ms与2ms).

I mean, we are not talking about barely noticeable differences as some of the "optimization police" promotes when it comes to using effective selectors. We are talking about some major delays when doing DOM manipulations onload. Trying this example in FF, domready can sometimes be more than 100 times slower (300ms vs 2ms).

我的问题是:为什么建议jQuery.ready在明显比其他替代方案慢得多的情况下使用?与使用jQuery.ready相比,在关闭BODY之前调用init有什么缺点?使用domReady可以说更安全",但是在什么情况下它比其他选择更安全? (我在考虑诸如document.write和延迟脚本之类的东西)我们已经在许多客户端站点上使用BODY方法近5年了,我们从未遇到任何问题.只是快了很多.

Now to my question: Why is jQuery.ready recommended to use when it’s obviously much slower that other alternatives? And what are the drawbacks of calling the init before closing the BODY vs using jQuery.ready? It’s arguably more "safe" to use domReady, but in what context is it more safe than the other option? (I’m thinking stuff like document.write and deferred scripts) We have used the BODY way for nearly 5 years on many client sites, and we never run into any problems. It’s just a lot faster.

我也想知道,由于关于jsPerf和为每10000次执行中的ms进行优化的选择器如此之多,所以为什么对此没有太多讨论?从根本上讲,这是用户面临的第一个延迟,并且在每次页面加载时将其切成50-100毫秒似乎很简单...

I’m also wondering, since there is so much fuzz about jsPerf and optimizing selectors for a couple of ms per 10000 executions, how come there is not much talk about this? It’s basically the first delay the user faces, and it seems to be fairly simple to slice 50-100 ms on each page load...

推荐答案

首先要指出的是:

不,在关闭<body>之前给您打电话init并没有什么不利.正如您已经注意到的那样,依靠$.ready()会更好地工作,并且还可以与所有浏览器完美无缺(即使在IE上也是如此).

No, there is no disadvantage in calling you init before closing the <body>. It will as you have noticed perform better that relying on $.ready() and will also work with all the browsers flawlessly (even on IE).

但是,现在有使用$.ready()的原因,在您的情况下,它们可能不适用:

Now, there are however reasons to use $.ready(), which in your case they do not probably apply:

  1. $.ready()使开发人员可以轻松按正确的顺序进行操作.特别是,关键是不要引用尚未加载的DOM元素.尽管这很简单,但是许多开发人员仍然感到困惑. $.ready()很容易,尽管很慢.
  2. 在您说过几个需要init()的脚本时,手动在身体的末端进行操作并不一定容易/方便.它需要纪律和知识,这些脚本做什么.特别是,您经常会在依赖jQuery的库中看到$.ready(),因为无论开发人员以何种方式加载库,它都能使工作正常.
  3. 随着异步模块定义(例如 require.js )作为一种加载JavaScript的方式而流行起来,不能保证<body/>方法.
  1. $.ready() makes it easy for developers to do stuff in the right order. In particular, the critical thing is to not reference DOM elements that have not been loaded. While this is simple enough, lots of developers still find it confusing. $.ready() is a no-brainer, albeit a slow one.
  2. In you have say several scripts that need to init(), it is not necessarily easy/convenient to manually do that at the end of your body. It requires discipline and knowledge of what these scripts do. In particular you will often see $.ready() in libraries dependent on jQuery, since it makes things work no matter what way developers will use to load the libs.
  3. With Asynchronous Module Definition (for instance require.js) becoming popular as a way to load your javascript, the end of <body/> method is not guaranteed.

这篇关于为什么推荐jQuery.ready这么慢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆