How to avoid long main-thread tasks
Any script that runs longer than 50 ms freezes the page. Break work into smaller pieces and defer what is not needed for the first screen.
Step by step, with screenshots: WooCommerce cart fragments: stop the AJAX call on every page →
Check your own site
Runs this check and the other 192, free, in about 45 seconds.
Or run only this check with the free Unused CSS/JS checker.
What it is
A long task is any piece of work on the browser's main thread that runs for more than 50 ms without a break, such as evaluating a large script, handling a click or recalculating layout. While it runs, the page cannot respond to taps, clicks or key presses.
Several long tasks in a row are what makes a page feel frozen while it loads, and they drive Total Blocking Time in the lab and Interaction to Next Paint for real visitors. getReport lists the long tasks from a throttled mobile Lighthouse run, with their total duration and the scripts behind them. A page is in good shape when few tasks exceed 50 ms and none runs for hundreds of milliseconds.
What a passing site looks like
- No long main-thread tasks block interactionwarning · −2 ptseffort L
Long main-thread tasks
Why it matters. A task longer than 50 ms freezes the page for that long. Several in a row are what makes a site feel unresponsive to taps and scrolls.
- Find the scripts behind the longest tasks (listed below) and defer, split or remove them.
- Yield to the browser between chunks of work (setTimeout, scheduler.yield, requestIdleCallback).
Questions people ask
Why is a long task defined as 50 ms?
Because responses within about 100 ms feel instant to people. If no task runs longer than 50 ms, the browser can always start handling new input within 50 ms and still respond inside that 100 ms budget. That reasoning comes from Google's RAIL performance model, and it is why Total Blocking Time counts only the time beyond 50 ms in each task.
How do I avoid long main-thread tasks?
Split big pieces of work into smaller ones and let the browser respond in between, for example by yielding with scheduler.yield() or setTimeout. Load less JavaScript at start-up, defer code that is not needed for the first screen, and move heavy calculations to a Web Worker. Third-party tags are often behind the longest tasks, so delay or remove them.
How do I fix long main-thread tasks in WordPress?
Find the scripts behind them first: the report names the files, which usually belong to a page builder, slider, chat widget, analytics or ad tag. Remove plugins you do not need, stop the rest loading on pages that do not use them, and use a performance plugin to delay non-essential JavaScript until the visitor interacts. Test menus, forms and checkout afterwards.