我认为setInterval本质上不会给您带来重大的性能问题。我怀疑这种声誉可能来自更早的时代，当时 CPU 的功能不那么强大。

然而，有一些方法可以提高性能，这样做可能是明智的：

1. 将函数传递给setInterval，而不是字符串。
2. 设置尽可能少的间隔。
3. 使间隔持续时间尽可能长。
4. 让每次运行的代码尽可能简短。

不要过早地优化——不要在没有问题的情况下让自己的生活变得困难。

但是，您可以在特定情况下做的一件事是onhashchange在支持它的浏览器中使用该事件，而不是超时。

我宁愿说情况恰恰相反。使用setTimeout和setInterval正确的，可以大刀阔斧的减少浏览器的CPU占用率。例如，使用or循环setTimeout代替使用不仅会降低 CPU 使用的强度，还会保证浏览器有机会更频繁地更新 UI 队列。因此长时间运行的进程不会冻结和锁定用户体验。forwhile

但总的来说，setInterval在您的网站上大量使用可能会减慢速度。20 个同时运行的间隔或多或少的繁重工作会影响表演。然后再说一遍..你真的可以搞砸任何我想这不是问题的部分setInterval。

..顺便说一句，你不需要像那样检查哈希。有一些事件：

onhashchange

当哈希值发生变化时会触发。

window.addEventListener('hashchange', function(e) {
    console.log('hash changed, yay!');
}, false);

不，setInterval它本身并不是 CPU 密集型的。如果你有很多间隔在很短的周期内运行（或者一个非常复杂的操作在一个中等长的间隔上运行），那么这很容易成为 CPU 密集型的，这取决于你的间隔正在做什么以及他们这样做的频率。

我不希望每隔 100 毫秒检查一次 URL 会出现任何问题，尽管我个人会将时间间隔增加到 250 毫秒，只是因为我不希望这两者之间的差异对典型的人来说是明显的用户，因为我通常尝试使用最长的超时间隔，我认为我可以逃脱，特别是对于大多数时间预计会导致无操作的事情。

在“CPU 密集型”术语下有一些营销活动。它的真正含义是“比某些替代方案更占用 CPU”。它不是“CPU 密集型”，因为“像游戏或压缩算法那样使用大量 CPU 能力”。

解释 ：

一旦浏览器让出控制权，它就会依赖来自底层操作系统和硬件的中断来接收控制权并发出 JavaScript 回调。这些中断之间有更长的持续时间允许硬件进入低功耗状态，从而显着降低功耗。默认情况下，Microsoft Windows 操作系统和基于 Intel 的处理器对这些中断使用 15.6 毫秒的分辨率（每秒 64 个中断）。这允许基于 Intel 的处理器进入其最低功耗状态。由于这个原因，在使用 HTML4 浏览器（包括早期版本的 Internet Explorer 和 Mozilla Firefox）时，Web 开发人员在使用 setTimeout(0) 时，传统上只能实现每秒 64 次回调。

在过去的两年中，浏览器试图通过更改节能的 Windows 系统设置并防止硬件进入低功耗状态，来增加 JavaScript 开发人员可以通过 setTimeout 和 setInterval API 接收的每秒回调数。HTML5 规范已经达到了推荐每秒 250 个回调的极端。这种高频率会导致功耗增加 40%，从而影响电池寿命、运营费用和环境。另外，这种方式并没有解决提高CPU效率和调度的核心性能问题。

来自http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html

在你的情况下不会有任何问题。但是如果你在画布上做一些巨大的动画或者使用 webgl ，那么就会有一些 CPU 问题，因此你可以使用 requestAnimationFrame。

请参阅此链接关于 requestAnimationFrame