Long task
Any uninterrupted stretch of main-thread work over 50ms, script plus the layout it drags along, long enough for a tap to feel ignored.
See it
What it is
A long task is any single piece of main-thread work that runs for more than 50 milliseconds without letting go. Not only JavaScript: the style recalculation, layout, and paint the script triggers inside that same turn of the event loop all count toward the same task, which is why a 'tiny' function that touches offsetHeight can show up as a 200ms bar. The 50ms line is not arbitrary: if the browser is busy longer than that, a tap arriving mid-task waits, and the delay crosses into 'felt'. In the Chrome DevTools performance panel they are the bars with the red corner flag; in code you catch them with a PerformanceObserver watching the 'longtask' entry type.
Long tasks are the unit of measurement behind the responsiveness metrics. Total Blocking Time sums the part of each long task past 50ms, and INP is usually bad because a long task sat between the user and the next paint. Hunt them by recording a profile, sorting by self-time, and asking what one function is doing for 300ms straight.
The gotcha in fixing them: splitting a long task into three smaller function calls does nothing, because it is still one uninterrupted turn of the event loop. You have to actually yield, handing control back so the browser can paint and flush input between chunks. Same total CPU, dramatically better feel.
Ask AI for it
Instrument this page for long tasks and then reduce them. First add a PerformanceObserver for entry type 'longtask' that logs duration and attribution to the console in development only. Then take the worst offender and rewrite it as a yielding loop: process items in batches of a fixed size, and between batches await a promise that resolves in a setTimeout of 0 (or scheduler.yield where available) so the browser can paint and handle input. Target no single task over 50ms and report the longest task before and after.