Keeping the UI Responsive: Managing Long Tasks in JavaScript
March 19, 2025• ☕️☕️ 10 min read
A task is a piece of code that is placed in a queue and is picked up by the event loop to run at an appropriate time. Running code inside script tag, parsing HTML and CSS, rendering a frame, etc are all example of tasks. Given that JavaScript is single-thread, it is not possible to run multiple tasks at the same time.
A browser can have multiple task queues: one for user interaction events (e.g., click, keydown), one for timers callbacks (e.g., setTimeout)—called macrotasks, one for requestAnimationFrame (rAF) callbacks, and one for promises (microtasks).
Once a task is done, the event loop picks up a runnable task from a queue, waits for it to complete, and then picks up the next task from any of the queues based on the priorties. If the current task takes a long time to complete, event loop can’t attend other high priority tasks, for example, rendering/updating a screen in response to some user interaction. This can lead to an unresponsive UX and a poor Interaction to Next Paint (INP) metrics.
Table of Contents
What is a long task
For a smooth UI experience, the browser should be able to render 1 frame per 16ms. (1000ms/60fps). Tasks that take more than 50ms to complete are long tasks. Long tasks can block the main thread, resulting in dropped frames, a slow and unresponsive UI, and poor Interaction to Next Paint (INP) metrics. While the event loop is busy processing long tasks, it won’t be able to process UI updates.
In Chrome DevTools, once you record a performance profile, a long task is indicated by a red triangle inside the main thread section.
Let’s look at one example where a long task is blocking the main thread.
<label>
Do heavy work
<input type="checkbox" id="check" />
</label>
<script>
// Checbox selection will NOT be responsive
check.addEventListener("change", (e) => {
block(5000);
});
// This will block the main thread for ~5 seconds
function block(milliseconds) {
const start = performance.now();
while (performance.now() - start < milliseconds) {}
}
</script>
When you click on the checkbox, the UI will not update for 5 seconds as the main thread is blocked by the long task. Once the long task is done, the UI will update. The user was trying to interact with the UI, but the event loop hadn’t had a chance to run the paint task, leading to poor Interaction to Next Paint (INP) metrics. Read more about what a good INP score means in this webdev article.
Now, let’s make it more realistic by looking at another example where each item in an array takes ~40ms to instantiate.
<label>
Do heavy work (Expensive Array)
<input type="checkbox" id="check" />
</label>
<script>
const array = new Array(100).fill(null);
check.addEventListener("change", (e) => {
for (let i = 0; i < 100; i++) {
array[i] = `Item ${i}`;
block(40);
}
});
function block(milliseconds) {
const start = performance.now();
while (performance.now() - start < milliseconds) {}
}
</script>
Once our change handler is invoked, a task of creating all array items is queued in the user interaction source queue. The event loop places this task on the execution stack for processing and eagerly waits for it to complete before handling other UI update-related tasks. Meanwhile, the UI feels laggy and unresponsive, resulting in a bad user experience.
This is clearly a problem. How can we solve this issue? Can we somehow break this long task into smaller ones and allow the event loop to prioritize user-visible updates in between? Yes, we can and that’s what we’ll see in the next section.
How to break long tasks
1. Deferring code to a separate task using setTimeout
One simple and naive way is to use setTimeout with a 0ms delay to defer a peice of work into a separate task, which will not be run in the same event loop iteration. This will allow the event loop to pick other high-priority tasks like paint/rendering (UI updates), resulting in a responsive UI. This process of deferring a piece of work into a separate task is called yielding.
<label>
Do heavy work
<input type="checkbox" id="check" />
</label>
<script>
const array = new Array(100).fill(null);
check.addEventListener("change", (e) => {
for (let i = 0; i < 100; i++) {
array[i] = `Item ${i}`;
setTimeout(() => {
// Running the block function in a separate task
// This will not run in the same event loop iteration.
block(40);
}, 0);
}
});
function block(milliseconds) {
const start = performance.now();
while (performance.now() - start < milliseconds) {}
}
</script>
Now, go ahead and try toggling the checkbox in the codepen live demo below. You will notice that the UI is responsive and checkbox is being toggled as you would expect.
The diagram below shows how breaking a long task into smaller tasks allows the event handler to run between them.
Moreover, this behavior also aligns with the Chrome performance profiler, as illustrated in the screenshot below:
Nonetheless, this is not an optimal solution, as setTimeout has a few drawbacks:
- After five nested
setTimeout()calls, the browser enforces a minimum delay of 5 milliseconds for each subsequent call. - As the deferred code gets added to the end of macrotask queue, if there are other tasks waiting, they will run before the deferred code leading to an unexpected behavior.
2. Using scheduler yield API
scheduler.yield() is a dedicated API that allows us to yield to the main thread and let the event loop pick other high priority tasks to keep the UI responsive.
Calling scheduler.yield() returns a Promise that must be awaited. Any code after the await keyword will be run in a separate/future task.
<label>
Do heavy work
<input type="checkbox" id="check" />
</label>
<script>
const array = new Array(100).fill(null);
check.addEventListener("change", async (e) => {
for (let i = 0; i < 100; i++) {
array[i] = `Item ${i}`;
await scheduler.yield();
// Running the block function in a separate task
// This will not run in the same event loop iteration.
block(40);
}
});
function block(milliseconds) {
const start = performance.now();
while (performance.now() - start < milliseconds) {}
}
</script>
With this change, our UI will be responsive again. Try playing with the demo below to see that in action:
As this API is not yet supported in all browsers, you need to conditionally check if it is available and fallback to setTimeout if it is not.
function yieldToMain () {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
// Fall back to yielding with setTimeout.
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
// and then you can just use it via `await yieldToMain()` call.
Prioritizing UI updates over non-user-visible tasks
When you don’t have fine-grained control over breaking a single long task into smaller tasks like we had in the previous example, you need to prioritize UI updates over other tasks that are not user-visible.
For example, if your submit handler includes analytics code that is not user-visible, you can defer it to a separate task. So instead of the following setup:
// The following code will run in the same event loop iteration
function submitForm() {
validateForm();
updateUI();
sendAnalytics();
}
which would run all the functions, including the analytics code, in the same event loop iteration (run to completion model), you can execute the critical UI work (validating the form and updating the UI) in a single task and postpone sending analytics in a separate task.
async function submitForm() {
// user-visible work
// This will run in the same event loop iteration
validateForm();
updateUI();
// code after await will run in a separate task
await scheduler.yield();
// non-user-visible work will run in a separate task
sendAnalytics();
}
This process allows yielding to the main thread, keeping the UI responsive, and improving Interaction to Next Paint (INP).
Summary
Long tasks can block the main thread, leading to an unresponsive UI and poor Interaction to Next Paint (INP) metrics. To address this, we can manually defer the work that isn’t user-visible to a separate task.
Instead of using setTimeout, which has a few drawbacks, we can use scheduler.yield() to yield to the main thread and keep the UI responsive. Moreover, when you don’t have fine-grained control over breaking a single long task into smaller tasks, you need to prioritize UI updates over other tasks that are not user-visible.
References
- Optimizing Long Tasks: web dev article
- Improving INP in react application
- How to improve INP: yield patterns
- Ways to break long tasks in JavaScript
Written by Amandeep Singh. Developer @ Avarni Sydney. Tech enthusiast and a pragmatic programmer.