I did some testing on the different ways that setInterval() can go wrong in Javascript across different browsers. Here is the result in table form using a 1hz test.

"Creep" means the intervals creep forward over time.

"Accuracy" means how many ms late from 1000ms the call occurred.

Tests were done on OSX and Windows in Virtual Box.

Browser	Accuracy	Creep	Switch Tabs	Page obscured
Chrome	late by 1-10ms	Yes	Slows	No effect
Safari	late by 1-10ms	Yes	Slows	Slows to 0.5hz
Firefox	late by 0-2ms	No	No Change	No change
IE10	late by 1-20ms	Yes	No change	No change

This is an interesting result in that Apple has gone nuclear against battery power and cpu hungry web pages with Safari, by heavily throttling their access to interval timers unless they are "in use". Chrome to some extent does the same thing but does not recognise invisible windows as needing to be throttled.

All browsers except Firefox have a poor attitude to creep. You would expect that set INTERVAL even though delivery is not guaranteed should be a metronome in concept, but it is not. It is more like a string of setTimeout() calls.

If you place the timing in a web worker, then the accuracy worsens but the problem with the subtraction of performance when the tab is not in focus, or the tab is covered, goes away, at least, currently.

If you use the visibility API you can detect when the tab is changed and the slowdown will start however you cannot get an event when the window is covered by another one (Safari).

The simple test code from a stackoverflow piece on the problem.

var start = +new Date();
var count = 0;
setInterval(function () {
    console.log((new Date() - start) % 1000,
    ++count,
    Math.round((new Date() - start)/1000))
}, 1000);
 

This stack overflow bit shows the current confusion. You must assume that some users will be on Javascript engines that pull the rug out from under your code either because of Creep, throttling, inaccuracy or all three. The best you can do is notice the problem and decide what to do.