WordPress main-thread yielding and the Core Web Vitals
No yielding API, requestIdleCallback(), scheduler.yield(), isInputPending(), or scheduler.postTask(): how JavaScript-heavy sites break up long tasks and keep Interaction to Next Paint (INP) fast.
On WordPress, 65.4% of sites call no main-thread yielding API. 32.1% use requestIdleCallback() and 2.6% use scheduler.yield(). Across all WordPress sites, 100% without a yielding API have a good INP, compared with 100% for scheduler.yield() and 100% for requestIdleCallback(). Sites without a yielding API load a median of 36 scripts, while scheduler.yield() sites load 35 scripts. Even with that workload, scheduler.yield() holds median Total Blocking Time to 7 ms, against 121 ms for requestIdleCallback().
INP pass rate
Sites with requestIdleCallback() have a good INP most often at 100%, followed by scheduler.yield() at 100% and no yielding API at 100%. Both isInputPending() and scheduler.postTask() appear on fewer than 50 sites across the dataset. Pages with little JavaScript do not need a yielding helper, so the raw pass rates mostly reflect how much script each page loads.
Main-thread yielding usage
34.6% of WordPress sites call a main-thread yielding API, while 65.4% run scripts without one. Among the sites that yield, 32% (20,295 sites) use requestIdleCallback() and 3% (1,622 sites) use scheduler.yield().
JavaScript workload by yielding strategy
Yielding APIs appear on pages with heavy JavaScript bundles. Sites with no yielding API load a median of 36 scripts and spend 550 ms in CPU scripting (41 ms Total Blocking Time). Sites using requestIdleCallback() load 51 scripts and spend 1194 ms in scripting, which pushes median Total Blocking Time to 121 ms. Sites using scheduler.yield() load a median of 35 scripts (421 ms scripting). Breaking up those tasks keeps median Total Blocking Time at 7 ms, and 100% have a good INP.
INP pass rate by total script count
Six in ten scheduler.yield() sites load 66 or more scripts. On those heavy pages, 99% of scheduler.yield() sites have a good INP with a 131 ms median Total Blocking Time. Sites on requestIdleCallback() drop to 100% (308 ms TBT), and sites without yielding sit at 100% (261 ms TBT).
| Scripts on page | scheduler.yield() | requestIdleCallback() | No yielding API |
|---|---|---|---|
| 1 to 15 scripts | 100% 244 sites | 100% 552 sites | 100% 3,885 sites |
| 16 to 35 scripts | 100% 584 sites | 100% 4,719 sites | 99% 16,044 sites |
| 36 to 65 scripts | 99% 444 sites | 100% 8,651 sites | 100% 15,508 sites |
| 66 or more scripts | 99% 350 sites | 100% 6,372 sites | 100% 5,916 sites |
Main-thread yielding per framework
On jQuery, 65% of sites use no yielding API and 33% use requestIdleCallback().
jQuery 60,310 sitesNo yielding API (none) 65%requestIdleCallback() 33%100%
React 2,233 sitesrequestIdleCallback() 62%No yielding API (none) 32%100%
Vue 4,844 sitesNo yielding API (none) 74%requestIdleCallback() 24%99%
Alpine 380 sitesNo yielding API (none) 48%requestIdleCallback() 47%99%Main-thread yielding or the framework
Does the framework explain the yielding pass rate?
On jQuery, 100% of sites without a yielding API have a good INP, compared with 100% for scheduler.yield() and 100% for requestIdleCallback(). On Vue, 99% of sites without a yielding API have a good INP, against 100% for requestIdleCallback().
Why scheduler.yield() resumes faster than setTimeout or requestIdleCallback()
When a script yields with setTimeout(fn, 0) or requestIdleCallback(), the remaining work goes to the back of the task queue. Any queued timer, third-party tracker, or network callback runs before your function continues. scheduler.yield() pauses the current task so the browser can handle input and paint the next frame, then resumes your code ahead of regular tasks. On script-heavy sites (35 median scripts), that holds median Total Blocking Time to 7 ms, against 121 ms on sites using requestIdleCallback().
Understanding main-thread yielding
Break up long JavaScript tasks (over 50 ms) with await scheduler.yield(), and fall back to setTimeout(resolve, 0) in browsers that do not support it yet. Keep requestIdleCallback() for background work like analytics batching, never inside an interaction handler. Across this dataset, sites with no yielding API score 100% good INP because they only load a median of 36 scripts (41 ms Total Blocking Time). Sites using scheduler.yield() load a median of 35 scripts. On pages with 66 or more scripts, scheduler.yield() reaches 99% good INP and 131 ms TBT, ahead of requestIdleCallback() at 100% good INP (308 ms TBT) and 261 ms TBT without yielding.
By Arjen Karel · 63,295 crawled WordPress sites (17,005 with desktop Chrome field data, 63,291 sites with main-thread yielding, October 2026). How we measured.