Make Uxify one of your go-to sources on Google
What are Long Tasks?
A long task is any piece of work that keeps the browser’s main thread busy for longer than 50 milliseconds without a break. While it’s running, the browser can’t do anything else. It can’t respond to a tap, can’t open a menu and can’t update what’s on the screen.
Most long tasks are JavaScript: a big script running on page load, a heavy click handler, or a third-party tag doing its thing in the background. They can also come from the browser itself, like expensive reflows and re-renders on a complex page.
Long tasks are closely tied to the event loop. The browser works through tasks one at a time, so a single long one holds up everything queued behind it, including whatever the visitor just tried to do.
What this means for revenue
Long tasks are why a page can look ready and still feel broken. Everything is on screen, the shopper taps “Add to cart,” and nothing happens for a beat. So they tap again. Then they end up with two items in the cart, or they leave.
They’re the main thing standing between you and a good Interaction to Next Paint (INP), the Core Web Vitals metric for responsiveness. Google considers INP good at 200 milliseconds or less, and a few long tasks in the wrong place can push you well past that.
The tricky part is that long tasks rarely come from one place. A chat widget here, an analytics tag there, a review app, a personalization script. Each one might be fine on its own, but together they keep the main thread busy right when shoppers are trying to interact. And they hit mobile hardest, since slower phone processors take longer to run the same code.
How Uxify helps
Reality measures INP from real visitors in every session, so you can see which pages and interactions are being held up, and on which devices. Ask Uxi can dig into those numbers and help you figure out where to look first. And INProve takes on long tasks directly: it frees up the main thread right before a user interaction and reschedules heavy scripts, so clicks and taps get processed first. No code changes, and no waiting on a refactor of a third-party script you don’t even control.
Long Tasks FAQs
What counts as a long task?
Any task that blocks the main thread for more than 50 milliseconds. A task that runs for 51 ms counts, and so does one that runs for two seconds, though the second one is obviously a much bigger problem.
What’s the difference between long tasks and Total Blocking Time?
Long tasks are individual events. Total Blocking Time (TBT) is a lab metric that adds up the blocking part of every long task during page load, meaning the time past the first 50 ms of each one. So a 120 ms task adds 70 ms of blocking time. Because Lighthouse can’t measure real interactions, it uses TBT as its stand-in for responsiveness, and it carries the biggest weight in the Lighthouse performance score at 30%.
How do I find long tasks on my site?
For quick debugging, record a page load in the Performance panel of Chrome DevTools. Long tasks are marked with a red corner, so they’re easy to spot. For real-user data, browsers can report them through the Long Tasks API, though it doesn’t work in every major browser yet. That’s where field data from a tool like Reality fills the gap, by showing you the INP impact your actual visitors feel.
How do you fix long tasks?
The usual approach is to break big tasks into smaller chunks so the browser can handle input in between, delay or remove scripts that aren’t needed right away, and move heavy work off the main thread with web workers where possible. Google’s guide on optimizing long tasks covers the developer side in detail. For third-party scripts you can’t edit, an agent like INProve can reschedule the work for you.