Main thread blocking
JavaScript hogging the single thread that also handles clicks and painting, so the page ignores you until it finishes.
See it
What it is
The browser gives your page one thread for almost everything: running JavaScript, computing style and layout, painting, and handling clicks, taps, and keystrokes. Those jobs take turns. While a chunk of JS is running, nothing else on that thread can happen, so the page cannot repaint, cannot animate, and cannot respond to input. That is main thread blocking, and it is why a page can look finished but ignore you.
Usual suspects: parsing and executing a fat JS bundle, hydration on a server-rendered page, a big JSON.parse, sorting or filtering thousands of rows in a click handler, and third-party tags doing work you never asked for. The fixes: ship less JS, break work into chunks that yield back to the browser (await a scheduler.yield or a setTimeout of 0 between batches), push pure computation into a Web Worker, and defer non-urgent work to requestIdleCallback.
The trap is testing on your laptop. An M-series machine chews through a bundle a mid-range Android phone will choke on for four seconds. Profile with 4x or 6x CPU throttling in DevTools, or your users will experience a page you have literally never seen.
Ask AI for it
Find and fix main thread blocking in this code. Locate any synchronous work over roughly 50ms: large loops, JSON parsing, sorting or filtering big arrays, layout reads inside loops, and heavy work inside event handlers. Refactor it by chunking the loop and yielding between batches (await a promise wrapping setTimeout 0, or scheduler.yield where supported), moving pure computation into a Web Worker with a message-based API, and wrapping non-urgent work in requestIdleCallback. Keep behavior identical and show a before and after estimate of the longest uninterrupted task.