在运行时确定浏览器是否太慢而无法优雅地处理复杂的 JavaScript/CSS 的最佳方法是什么？

Question

我正在考虑逐步启用/禁用页面上的 JavaScript（和 CSS）效果 - 取决于浏览器的速度有多快/有多慢。

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

有没有此类事情的例子？

衡量这一点的最佳方法是什么 - 考虑到诸如繁忙 CPU 上的暂时减速之类的情况？

注释：

• 我对浏览器/操作系统检测不感兴趣。
• 目前，我对带宽测量不感兴趣——只对浏览器/CPU 性能感兴趣。
• 测量可能有趣的事情：
  • 基本 JavaScript
  • DOM 操作
  • DOM/CSS 渲染
• 我希望以尽可能少地影响页面渲染速度的方式来执行此操作。

顺便说一句：为了不让用户因不一致的行为而感到困惑/恼怒 - 当然，这需要屏幕上的通知来允许用户选择加入/退出整个性能调整过程。

[更新：我错过了一个相关问题：根据用户计算机的性能禁用JavaScript功能。谢谢Android！]

Answer 1

并不是要在这里扫兴，但在我看来，这目前还不可能以任何有意义的方式实现。

造成这种情况的原因有几个，主要是：

1. 无论您做什么测量，如果它有任何意义，都必须测试浏览器/CPU 的最大潜力，而您无法做到这一点并维护任何类型的性能。合理的用户体验

2. 即使可以，这也将是一个毫无意义的快照，因为您不知道测试运行时除了浏览器之外的其他应用程序对 CPU 造成的负载类型，并且无论用户访问您的网站时是否会继续这种情况。

3. 即使你能做到这一点，每个浏览器都有自己的优点和缺点，这意味着，你必须测试每个 dom 操作函数才能知道浏览器完成它的速度，没有“通用”或“根据我的经验，这是有意义的，即使有，dom 操作命令执行的速度也是基于 dom 中当前内容的上下文，当您操作它时，它会发生变化。

您能做的最好的事情就是

1. 让您的用户决定他们想要什么，并让他们在后悔时可以轻松更改该决定

   或者更好

2. 情况下轻松更改该决定

   选择为他们提供一些您可以合理确定大部分目标受众能够喜欢的东西.

稍微偏离主题，但遵循以下思路：如果您的用户不是其社交圈中的技术领导者（就像这里的大多数用户一样，但世界上的大多数人不是），请不要给他们太多选择，即。任何并非绝对必要的选择 - 他们不想要它，并且在为时已晚之前他们不了解其决定的技术后果。

Answer 2

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

您可以按优先顺序应用功能，在每一项功能之后，如果已经过了一定时间，则放弃其余的功能。

确保最昂贵的功能排在最后，您将根据浏览器的速度向用户提供适当的功能选择。

Answer 3

您可以尝试对一些基本操作进行计时 - 看看 Steve Souder 的 Episodes 和 Yahoo 的 boomerang，了解在浏览器端计时的好方法。然而，弄清楚这些指标与可接受的性能水平/有益的用户体验之间的关系将相当复杂。

如果您要提供一个 UI 来让用户选择加入/退出，为什么不让用户选择应用程序中的美观程度与渲染速度呢？

Answer 4

看一下 Google 的一些（受版权保护的！）基准 V8：

• http://v8.googlecode.com/svn/data/benchmarks/ v4/regexp.js

• http://v8.googlecode.com/svn/data/benchmarks/v4/splay.js

我选择了其中的几个更简单的方法可以让您了解您可以自己创建的类似基准来测试功能集。只要在最慢的系统上将测试的运行时间从开始记录的时间到完成记录的时间保持在 100 毫秒以内（这些 Google 测试远大于此值），您就应该获得所需的信息，而无需有损用户体验。虽然 Google 基准测试关心更快系统之间的粒度，但您却不关心。您需要知道的是哪些系统需要比 XX 毫秒更长的时间才能完成。

您可以测试的内容包括正则表达式操作（与上面类似）、字符串连接、页面滚动、任何导致浏览器重绘或回流的内容等。

Answer 5

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

Answer 6

一些想法：

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

Answer 7

我遇到了类似的问题，我就这样解决了，事实上它帮助我做出了一些决定。

渲染页面后，我这样做：

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 RAM:

• 1,500,000 aprox on Chrome
• 301,327 aprox on Internet Explorer
• 141,280（在运行 Lubuntu 的虚拟机上的 Firefox 上，给定 2GB）

MacOS 8GB RAM：

• Safari 上约 3,000,000
• Firefox 70,000 上约 1,500,000
• （在运行 Windows XP 的虚拟机上的 Firefox 41，给定 2GB）

Windows 10 - 4GB RAM（这是旧版）我拥有的计算机）

• Google Chrome 上有 500,000 aprox

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

所以这可能是一个好方法，但是说到渲染，那就是另一个故事了，但这绝对可以帮助做出一些决定。

祝大家好运！