我如何估计浏览器的Javascript功能?

时间:2009-08-06 13:22:06

标签: javascript browser

我提供的网页让客户端在点击后立即执行大量Javascript工作。工作量与内容量成正比,而且变化很大。

如果内容量很大,工作可能会花费很长时间,客户会向用户发出其中一个“无响应的脚本 - 您要取消它吗?”消息。在几乎没有任何内容的情况下,工作在眨眼之间就结束了。

我添加了一项功能,在内容大于某个值X的情况下,我在硬件工作开始之前向用户显示“这可能需要一段时间”的消息。

麻烦在于为X选择一个好的价值,因为对于这个特定的页面,Chrome比Firefox快得多,比IE快。我想在适当的时候警告所有用户,但是当它只在那里持续100ms时避免把消息放好,因为这会分散注意力。换句话说,我希望X的值也取决于浏览器的Javascript功能。

那么有没有人有一个很好的方法来确定浏览器的功能?我目前正在考虑明确关闭浏览器的内容,但这看起来很糟糕,我想还有其他因素。

4 个答案:

答案 0 :(得分:4)

如果数据是相对同质的,一种方法可能是使用辅助函数来检查特定数据子集经过多长时间,并对整个集合将花费多长时间进行保守估计。 / p>

从那里决定是否显示信息。

答案 1 :(得分:2)

这可能不是你想去的地方,但是你有一个好主意为什么 javascript需要这么长时间?它是通过网络下载一堆内容还是浏览器上的实际格式/搅拌慢的部分?

您甚至可以逐步执行某些操作,以便整个shebang需要很长时间,但用户会看到内容“构建”,因此无需收到警告。

答案 2 :(得分:0)

为什么不让用户决定X是什么? (例如,每页选择“显示10 | 20 | 50 | 100”)那么你根本不需要做任何测量/猜测;你可以让他们做出最佳的延迟/信息内容权衡。

答案 3 :(得分:0)

这有点误导;通常当讨论浏览器的JS功能时,它指的是浏览器的实际功能,例如它是否支持原生XMLHTTP?它是否支持ActiveX?等

无论如何,无法可靠地推断出浏览器的处理能力或速度。有人可能会认为您可以运行一些简单的压力测试,计算结果并与过去的表现列表进行比较,以查看当前用户的浏览器排名,并可能使用此信息来估算时间。这里的问题是,这些计算不仅会受到浏览器中的活动(或仅仅是操作系统)的影响;例如,你运行你的分析脚本,用户的AV扫描仪启动,因为它是下午5点;什么通常需要2s,需要20秒。

在问自己的事情上,是:这个处理是否必须立即进行?正如n8wrl和Beska所提到的那样,您可能需要编写自己的方法,然后将要完成的工作分解为块,然后逐个操作它们并使用类似setTimeout()的方法。这将使发动机有时间“呼吸” - 因此有希望避免“反应迟钝的脚本”警告。这些块中的每一个也可以用于更新进度条(或类似的),为用户提供工作正在进行的指示。

或者您可以像GMail一样采用这种方法 - 它们会在窗口的一角闪烁一个非常小的红色“正在加载...”文本区域。有时它会在那里停留几秒钟,有时它不足以读取它。其他时候它会眨眼几次。但是当你做某事时,知道

最后,在逐步“构建”页面的过程中,您可以检查Chrome新标签页的来源。注意:您无法使用“查看源”查看此内容;相反,选择“javascript控制台”选项(在新标签页上),然后查看那里的HTML源代码。应该有一个评论解释他们的总体策略,如:

<!-- This page is optimized for perceived performance. Our enemies are the time
 taken for the backend to generate our data, and the time taken to parse
 and render the starting HTML/CSS content of the page. This page is
 designed to let Chrome do both of those things in parallel.

 1. Defines temporary content callback functions
 2. Fires off requests for content (these can come back 20-150ms later)
 3. Defines basic functions (handlers)
 4. Renders a fast-parse hard-coded version of itself (this can take 20-50ms)
 5. Defines the full content-rendering functions

 If the requests for content come back before the content-rendering functions
 are defined, the data is held until those functions are defined. -->

不确定这是否有帮助,但我认为它确实可以让我们了解一些大型玩家如何应对这些挑战。