requestIdleCallback

`requestIdleCallback` schedules low-priority JavaScript work for periods when the browser considers the main thread idle. It is useful for deferrable tasks that should not compete with user-visible work, but it should not be used for work with a strict deadline.

`requestIdleCallback(callback, options)` asks the browser to invoke a callback during an idle period. The callback receives an `IdleDeadline` object that exposes `timeRemaining()` and `didTimeout`, allowing the code to decide whether there is enough budget to continue.

Without a timeout, an idle callback may be postponed for an unpredictable amount of time when the browser remains busy. Passing `timeout` establishes a maximum delay after which the callback becomes eligible to run even if the browser has not found a normal idle period; when this happens, `deadline.didTimeout` is `true`.

Idle callbacks should perform small, interruptible pieces of nonessential work. A callback that consumes a large amount of CPU time can still block rendering and input because JavaScript executes on the main thread. For larger workloads, split processing into chunks and reschedule unfinished work.

The API is different from a normal timer: `setTimeout` requests execution after a delay, whereas `requestIdleCallback` lets the browser choose an idle opportunity. It is therefore better suited to work such as noncritical bookkeeping, deferred analytics preparation, or background cleanup than to UI updates that need predictable timing.

Key points

• Schedules low-priority work during browser idle periods.
• Use `deadline.timeRemaining()` to avoid overrunning the available idle budget.
• Use `timeout` when deferred work must not wait indefinitely.
• `didTimeout` indicates that the timeout caused the callback to run.
• Long idle callbacks can still block rendering and input because they run on the main thread.

Interview questions

What problem does `requestIdleCallback` solve?

It lets an application defer nonessential JavaScript until the browser has spare main-thread capacity. This can reduce competition between background work and user-visible operations such as input handling and rendering. It is appropriate when the work can safely wait. It should not be treated as a general replacement for timers or rendering callbacks.

What are `timeRemaining()` and `didTimeout` used for?

`timeRemaining()` reports the approximate amount of time left in the current idle period, so code can stop processing before the browser needs the main thread for other work. `didTimeout` indicates that the callback is running because its requested timeout has expired. Together they support chunking work while also allowing a deadline to prevent indefinite postponement. Code should account for both conditions when deciding whether to continue processing.

When would you add a `timeout` option?

A timeout is useful when work is deferrable but still needs a bounded maximum wait. Without it, repeated periods of main-thread activity can postpone an idle callback for a long time. Once the timeout expires, the browser can run the callback even without a normal idle opportunity, and `didTimeout` reports that condition. The callback should then still avoid doing an unnecessarily large amount of synchronous work.

Why can `requestIdleCallback` still hurt performance?

An idle callback is still JavaScript running on the main thread, so a long callback can delay subsequent browser work. An application can also schedule too much background work and repeatedly consume idle opportunities that would otherwise be available for responsiveness. The usual mitigation is to make tasks incremental, check the available deadline, and reschedule unfinished work. For critical rendering or interaction paths, a different scheduling mechanism may be more appropriate.