Jquery / Javascript 速度...我真的应该关心吗？答案

【问题标题】：Jquery / Javascript speed... should I really care?Jquery / Javascript 速度...我真的应该关心吗？
【发布时间】：2011-07-07 01:49:38
【问题描述】：

我看过很多比较各种选择器查询和 DOM 遍历方法的速度的帖子。当然，在具有成百上千个元素和 O^n 操作的情况下，速度确实很重要，但在 99% 的情况下，速度确实很重要，因为 Jquery 为响应用户操作而进行了一些 DOM 操作（或快速动画，或制作吐司） ?

几乎所有的 JQuery 操作不会比往返服务器更快吗？

设计超级优化的服务器端代码是有意义的。在 javascript 中负责内存分配和清理是有意义的，这样用户的浏览器就不会像 Flash 大约 v5 那样运行。我认为浪费时间优化 JQuery / Javascript 的速度没有任何意义，除非在测试期间出现明显减慢页面速度的情况。

有人能告诉我是否以及为什么我应该开始关心 JQuery 速度吗？

编辑

无可否认，我的语气有些发牢骚，但并不意味着争论。当您需要here 时，有很多关于如何进行优化的很好的资源，问我问题的更好方法是：

次优的 Javascript/Jquery 有什么影响？
如果我没有注意到它，我应该担心吗？

接受

阅读回复后，我认为这个问题的最佳答案取决于您的项目和团队规模。在程序员无法完整查看用户将看到的页面的情况下，例如在团队中

程序员负责页面上的各个功能
程序员独立开发和单元测试
有可能影响实际响应时间的定制前端 API 或其他代码

那么，更加小心并将“过早优化”作为例行程序是有意义的。这在有专业的、专业的前端设计师不做其他事情的情况下是可行的。

在较小的项目上，例如我目前的两人团队：

缺乏专业化
需要高程序员输出
一个人集中负责整个前端

所有的优化都在优先级列表中。 @Anurag 的回答帮助我找到了问题的核心并做出了最佳决定。

【问题讨论】：

标签： javascript jquery optimization performance frontend

【解决方案1】：

jQuery 帮助您专注于您的开发，而不是花费数小时修复跨浏览器的不兼容性。速度不是问题，至少肉眼不是问题。这一切都归结为您的代码是如何编写和优化的。这并不意味着您将停止使用 javaScript，但对于像 ajax 请求这样的任务，使用 jQuery 会更轻松，而不必担心跨浏览器的不兼容性。

更新阅读下面的 cmets。这就是我用来测试 javascript 的 for 与 jQuery 的 $.each 函数的方法。 jQuery 在本地以 4 毫秒的优势获胜。 jQuery 11 毫秒与 JavaScript 14 毫秒

var array = new Array();
for (var i = 0; i < 10000; i++) {
    array[i] = 0;
}

console.time('native');
var l = array.length;
for (var i = 0; i < l; i++) {
    array[i] = i;
}
console.timeEnd('native');

console.time('jquery');
$.each(array,
function(i) {
    array[i] = i;
});
console.timeEnd('jquery');

【讨论】：

UI 上下文中 2 毫秒和 160 毫秒响应时间之间的差异在 IMO 中可以忽略不计。这是用 JSLitmus 完成的吗？
@RSG 你是对的，你应该只在出现问题时进行优化。然而，160 毫秒的响应将其置于人类感知的范围内。如果您的 UI 需要至少 160 毫秒，那么您需要考虑优化或向用户提供“做某事”反馈。
我发布的图表结果不正确。我正在使用 console.time 进行循环，我的语法影响了结果。我更新了我的帖子，请参阅上面用于测试的代码。再次尝试后，它表明jQuery的$.each比javaScript原生for更快。

【解决方案2】：

如果您的代码很慢，jQuery 就不太可能成为瓶颈。它的速度很快。

更有可能的是，您的算法将成为问题。

【讨论】：

【解决方案3】：

当它开始变得重要时，你应该关心。

也就是说，性能应该是您的应用程序的特定要求，并且与任何应用程序一样，您不应该花太多时间担心性能，直到缺乏性能影响某些要求。当然，我并不是说当存在简单的线性替代方案时使用 O(n^3) 算法，但瓶颈可能出现在许多地方，而您选择的 JavaScript 库只是其中之一。

【讨论】：

【解决方案4】：

其实优化任何东西prematurely都没有意义，不仅仅是jQuery。

添加这些微优化所花费的时间和精力可能不值得。如果某些东西看起来很慢，那么深入研究这个问题，否则专注于设计好应用程序。

创建好的应用程序并非易事，过早地尝试优化通常会导致设计和架构复杂且难以维护。

【讨论】：

【解决方案5】：

我实际上想投票以主观和争论的方式结束这个问题，但我想这不是为了争论。

我们在这里应该问的问题是，为什么我们不应该优化我们的代码？

我不得不承认，ECMA-/Javascript 解释器在过去几年中确实进步了很多，因此整体 Javascript 性能有所提高。但是，浏览器环境中的 Javascript 仍然不是很快。尤其是当涉及到 DOM 操作时，它实际上非常慢（或者：它可能真的很慢）。

有很多关于这个主题的好书，我强烈推荐的一本是 Nicholas C. Zakas 的High performance Javascript。

我们应该优化代码的几个原因是：

并非所有用户都拥有最先进的浏览器，我们应该保证使用老旧和慢速浏览器的用户也有良好的用户体验
一般来说，Javascript 仍有局限性。这意味着内存使用和执行时间都是有限的
Javascript 和浏览器 UI 线程无法并行执行。这意味着缓慢的 Javascript 会极大地影响用户体验
毕竟这是一个好习惯！如果你习惯于编写最优代码，那么你每次都会这样做，我认为这是一件非常好的事情

即使使用像 jQuery 这样的高度抽象的框架，您也可以轻松地做一些糟糕的事情。举个例子，一个简单的查询语句，如

$('body > *')

几乎总是非常慢。问题是，即使这个语句也不会明显减慢速度，但如果你没有意识到这一点并且你编写了所有没有优化的代码，它最终会加起来。

【讨论】：