【问题标题】:How is jQuery so fast?jQuery 怎么这么快?
【发布时间】:2011-06-02 04:28:57
【问题描述】:

我有一个相当大的应用程序,在管理前端,加载页面需要几秒钟,因为它必须在显示任何内容之前将所有页面浏览量加载到对象中。解释系统如何工作有点复杂,但我的其他一些问题非常详细地解释了系统。他们所说的与当前系统之间的主要区别在于,当客户第一次查看页面时,客户前端不再将所有页面浏览量加载到对象中 - 它只是将页面浏览量添加到数据库中并在不同步的列表中创建一个对象。 . 简单地说,当客户浏览一个页面时,它不再将所有的浏览量加载到对象中;但管理前端仍然如此。

我最近一直在开发客户前端的一些管理工具,因此如果管理员单击目录中项目的描述,那么右侧列将显示所选项目的统计信息和可用操作。为此,(通过$('action-container').load(bla bla bla);)加载到右侧列的页面必须遍历所有的综合浏览量——这最终意味着所有的综合浏览量如果还没有被加载到对象中。由于某种原因,这加载得非常快。速度上的差异在我的开发网站上只有一秒钟,但实时网站有数千次浏览量,所以差异很大......

所以我的问题是:为什么在使用$(bla).load(bla); 时管理前端加载速度如此之快?我的意思是无论 jQuery 使用什么方法,浏览器不能也使用这种方法并超快地加载页面吗?显然不像现在有人会这样做 - 但我很想知道为什么差异如此之大......这只是我的系统还是浏览器获取页面和jQuery获取速度之间存在重大差异页面?其他人是否也有同样的差异?

【问题讨论】:

  • 谢谢。所以我猜其他人也会遇到同样的结果,嗯?
  • 我相信最大的改进发生在最慢的系统上,而且看起来更快。该页面功能齐全(这是人们正在等待的)并且在没有所有内容的情况下呈现,而不是等待所有内容然后呈现。等待首屏下方的内容查看首屏上方的内容是愚蠢的。
  • 我想我明白你的意思了——浏览器必须等待服务器将页面发回才能呈现任何内容;但对于 jQuery 来说,情况肯定是一样的......否则浏览器可能会呈现在 LoadComplete 事件(在 VB.Net 中)中在最后一刻变得不可见的东西......我想说的是理论上,相同的规则在发送请求/接收响应时应该同时适用于浏览器和 jQuery,因此 jQuery 还应该在告诉浏览器渲染任何内容之前等待页面完成。
  • @Wayne:我刚刚阅读了更新的评论,现在意识到我没有理解你最初的意思。基本上我的问题是问为什么当部分页面本身需要一个如果我直接浏览到它,加载几秒钟。单击目录中的项目时,div 被指示加载统计/操作页面,而不是页面加载。
  • 嗯我认为我可能刚刚解决了它。初始时间通常是我在编译应用程序后第一次加载页面。如果我加载一个页面,重新编译应用程序,然后单击页面上的一个项目,大约需要 2 秒才能显示统计信息。我不知道如何解决这个问题,但似乎情况可能如此。这得到了如此多的赞成票这一事实表明,其他人在使用 jQuery 时会体验到同样的速度提升,所以我将把这个问题留给任何人能想到的任何答案。有时间我会进一步调查这个问题。

标签: jquery performance browser load-time


【解决方案1】:

没有看到一些代码,很难推测,但我怀疑如果您要在 Firefox/Firebug 或 IE/Fiddler 中运行测试,当您直接浏览到每个“部分页面”时,您会看到许多 http 连接被打开.当您使用 jQuery 加载每个“部分页面”时,您只加载“部分页面”内容,而不是任何 CSS、JS 或图像文件。

【讨论】:

  • 如果在同一台主机上,仍然是一个连接。您不是说:“请求已发出”而不是“连接已打开?”
  • @chprpipr:这很容易成为其中的主要部分——我的意思是有 4 个样式表(其中一个很大)以及 2 个 jQuery 文件,这些文件在原始页面加载时加载。这些也用于在不重新加载 css / jQuery 的情况下对部件进行样式设置。感谢您指出了这一点。我不知道我怎么没想到这一点 - 现在我想起来很明显!
  • @Time Machine:是的。感谢您澄清这一点。
  • @ClarkeyBoy:您需要确保这些文件正确缓存。此外,如果您还没有,您可能会考虑缩小和压缩选项。我最近主要使用 .NET,并且是 SquishIt 的忠实粉丝。
  • 我现在看到@patrick_dw 已经提出了这个建议。我可以确认 SquishIt 在调试模式下处理单个文件并在生产模式下“编译”代码时处理繁琐的工作。
【解决方案2】:

Facebook 在这方面做了很多研究(通过 Javascript 部分加载页面,而不是一次全部加载)。

在此处查看他们的“BigPipe”技术说明:http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919

【讨论】:

  • +1 链接 - 谢谢 Jamie - 当我有一些 kip 时,我会仔细阅读它!
【解决方案3】:

我的意思是无论 jQuery 使用什么方法,浏览器不能也使用这种方法并超快速地加载页面吗?

jQuery 只能使用浏览器提供的(DOM API)。而已。 jQuery 没有带来任何额外的东西,也没有任何魔术。

它基本上只是该 API 之上的一个层,因此,它实际上比直接使用 API 更慢

...这获得了如此多的赞成票,这表明其他人在使用 jQuery 时也能体验到同样的速度提升。

您收到了赞成票,因为您称赞 jQuery 速度快。我认为这些支持者都不愿意指出 jQuery 不能以某种方式比浏览器更快的事实证明了这一点。

如果你批评了 jQuery,我猜你会被一些用户否决。

【讨论】:

  • 我理解你所说的它只是浏览器提供的东西,它不可能更快,它是如此之快似乎真的很奇怪。我认为 chprpipr 得到了最好的答案,关于在初始页面加载中加载的所有图像/css 等 - 它可以解释为什么差异如此之大,比我对这个问题的最后评论更重要。我想可能投票的原因是其他人正在经历时差,但也无法解释(因此没有回答问题)。
  • @ClarkeyBoy:是的,我明白这一点。加载的时间差异与提供内容的内容和提供的内容有关。听起来你正在关注这个问题。我的观点是,问题的前提(jQuery 看起来异常快)并不是造成差异的实际原因,但是这个问题被大量投票,而没有费心指出前提是错误的。用一粒盐来投票(上下)。
  • downvoter:您的反对票有助于证明我回答中的最后一句话。谢谢你。 :o)
  • 您说 jQuery“实际上比直接使用 API 慢”,但我认为这种说法是错误的。这取决于您如何直接使用 API。例如,许多人声称用汇编编程会比用 C 编程更快,因为您直接使用机器代码。然而,随着当今编译器的优化,不熟练的汇编程序不太可能成功地实现自己的算法,这些算法的性能优于一个好的编译器。
  • @patrick dw,感谢您澄清您的意思。这就说得通了。除非您对其进行编辑,否则它不会让我删除反对票。
猜你喜欢
  • 2020-12-19
  • 2012-03-18
  • 2014-05-09
  • 2016-03-19
  • 2012-09-19
  • 2010-09-13
  • 1970-01-01
  • 2012-11-04
  • 1970-01-01
相关资源
最近更新 更多