如果浏览器太慢而不能优雅地处理复杂的JavaScript / CSS,那么在运行时确定的最佳方法是什么?

时间:2011-01-19 11:08:29

标签: javascript performance browser benchmarking

我正在尝试逐步启用/禁用页面上的JavaScript(和CSS)效果 - 这取决于浏览器的速度/速度。

我特别想到的是低功耗移动设备和旧台式电脑 - 而不仅仅是IE6: - )

有没有这类事情的例子?

衡量这一点的最佳方法是什么 - 会计事项,例如繁忙CPU上的临时减速?

注意:

  • 我对浏览器/操作系统检测不感兴趣。
  • 目前,我对带宽测量不感兴趣 - 只有浏览器/ CPU性能。
  • 衡量可能有趣的事情:
    • 基础JavaScript
    • DOM操作
    • DOM / CSS呈现
  • 我想以尽可能少影响页面渲染速度的方式执行此操作。
BTW:为了避免混淆/激怒行为不一致的用户 - 当然,这需要屏幕上的通知,以允许用户选择加入/退出整个性能调整过程。

[更新:我错过了一个相关问题:Disable JavaScript function based on user's computer's performance。谢谢Andrioid!]

7 个答案:

答案 0 :(得分:11)

在这里不要成为一个杀手,但在我看来,这不是一个目前可行的任何有意义的壮举。

有几个原因,主要是:

  1. 无论你做什么测量,如果它有任何意义,都必须测试浏览器/ cpu的最大潜力,这是你无法做到的,并保持任何合理的用户体验

  2. 即使你可以,它也会是一个毫无意义的快照,因为你不知道在你的测试运行时,除了浏览器以外,其他应用程序的CPU负载是什么样的,并且天气是否会继续当用户访问您的网站时。

  3. 即使您可以这样做,每个浏览器都有自己的优点和缺点,这意味着,您必须测试每个dom操作函数,以了解浏览器完成它的速度有多快,没有“通用” “或”平均“在我的经验中是有意义的,即使有,dom操作命令执行的速度,也是基于当前在dom中的内容,当你操作它时会发生变化。” p>

  4. 你能做的最好的是

    1. 让您的用户决定他们想要什么,并让他们在后悔的情况下轻松更改该决定

      或更好

    2. 选择给他们一些你可以合理确定目标受众的大部分能够享受的东西。

    3. 稍微偏离主题,但遵循这一思路:如果您的用户不是他们社交圈中的技术领导者(就像这里的大多数用户一样,但世界上大多数人都不是),不要给他们太多的选择,即。任何不是绝对必要的选择 - 他们不想要它,并且在为时已晚之前他们不理解他们决定的技术后果。

答案 1 :(得分:8)

不需要明确基准的不同方法是逐步启用功能。

您可以按优先顺序应用功能,并且在每个功能之后,如果已经过了一定的时间,则删除其余功能。

确保最昂贵的功能最后,您可以根据浏览器的快速程度向用户提供一些适当的功能选择。

答案 2 :(得分:2)

查看一些针对V8的Google(受版权保护的!)基准测试:

我选择了一些更简单的基础知识,你可以自己创建类似的基准来测试功能集。只要您将测试的运行时间在开始时记录的时间与完成时记录的时间保持在最慢的系统(这些Google测试远远大于)上的时间不到100毫秒,您应该获得所需的信息而不是不利于用户体验。虽然Google基准测试关注较快系统之间的粒度,但事实并非如此。您需要知道的是,哪些系统需要的时间超过XX毫秒才能完成。

你可以测试的东西是正则表达式操作(类似于上面的),字符串连接,页面滚动,任何导致浏览器重绘或重排的东西等。

答案 3 :(得分:1)

你可以试试一些基本的操作 - 看看史蒂夫·索德的剧集和雅虎的飞旋镖,以获得优秀的浏览器计时方法。然而,要弄清楚指标如何与可接受的性能水平/有益的用户体验相关,它会变得相当复杂。

如果您要提供用户界面选择加入/退出的用户界面,为什么不让用户选择应用中的视觉效果水平与渲染速度?

答案 4 :(得分:1)

您可以使用Web Workers运行所需的所有基准测试,然后根据结果将您的检测结果存储在cookie中。 这仅适用于HTML5支持的浏览器,当然

答案 5 :(得分:0)

一些想法:

  • 对测试设置时间限制似乎是一个明显的选择。
  • 将测试结果存储在cookie中似乎也很明显。
  • 测试时测试性能不佳可能会暂停进一步的脚本
    • 并触发显示非阻塞提示UI(如现代Web浏览器中常见的保存密码提示)
    • 询问用户是否要选择进一步的脚本效果 - 并将答案存储在cookie中。
    • 当用户没有回答提示时,如果连续测试比第一次测试完成得更快,则定期重复测试并自动接受脚本提示。
  • 旁注 - 慢速网络速度也可能会被测试
    • 通过计时下载外部资源(如页面自己的CSS或JavaScript文件)
    • 并将该结果与JavaScript基准测试结果进行比较。
    • 这可能对依赖大量XHR效果和/或大量使用<img/> s的网站有用。
  • 在页面开始渲染之前,似乎很难执行DOM渲染/操作基准测试 - 因此可能会对所有用户造成非常明显的延迟。

答案 6 :(得分:0)

我提出了一个类似的问题,并以这种方式解决了它,实际上它帮助我做出了一些决定。

渲染页面后:

let now, finishTime, i = 0;
now = Date.now();//Returns the number of miliseconds after Jan 01 1970
finishTime = now + 200; //We add 200ms (1/5 of a second)
while(now < finishTime){
    i++;
    now = Date.now();
}
console.log("I looped " + i + " times!!!");

这样做之后,我在具有不同操作系统的多个浏览器上对其进行了测试,i 值给了我以下结果:

Windows 10 - 8GB 内存:

  • Chrome 上大约 1,500,000 个
  • Internet Explorer 上大约 301,327 个
  • 141,280(在运行 Lubuntu 2GB 的虚拟机上的 Firefox 上)

MacOS 8GB 内存:

  • Safari 上大约 3,000,000 次
  • Firefox 上 1,500,000 个近似值
  • 70,000(在运行 Windows XP 2GB 的虚拟机上的 Firefox 41 上)

Windows 10 - 4GB RAM(这是我的旧电脑)

  • Google Chrome 上大约 500,000 个

我以列表的形式加载了很多 div,它们根据用户的输入动态加载,这有助于我根据给定的性能限制我创建的元素数量,但是 但 JS 不是全部!,因为即使在虚拟机上运行的 Lubuntu 操作系统也很糟糕,但它在不到 2 秒的时间内加载了 20,000 个 div 元素,你可以毫无问题地滚动列表,而我花了超过 12 秒对于 IE,性能很差!

所以可能是一个好方法,但是当涉及到渲染时,那就是另一回事了,但这绝对有助于做出一些决定。

祝大家好运!