Performance
perf/yield-long-tasks
Main-thread work over 50 ms is split and yields, and event handlers do the visible update first (INP 200 ms or less).
moderatemanualfe-core-web-vitals
Why
While a long task runs, the page cannot paint the result of a click or key press. INP measures that delay for the slowest interactions; "good" is 200 ms or less at the 75th percentile. Big re-renders, JSON parsing, analytics and validation inside a handler are the usual causes.
Fix
In a handler, update the UI first, then yield and do the rest (saving, analytics, recalculation). Split loops over large data into chunks and yield between them with scheduler.yield() where it exists and a setTimeout fallback. Move pure computation to a Web Worker. Measure with the DevTools Performance panel and the web-vitals attribution build.
Examples
const yieldToMain = () => (globalThis.scheduler?.yield ? scheduler.yield() : new Promise((r) => setTimeout(r, 0)))
button.addEventListener('click', async () => {
showSpinner() // visible update first
await yieldToMain()
await saveAndTrack() // the rest after the next paint
})Sources
Facts
- Id
perf/yield-long-tasks- Severity
- moderate
- Check
- manual a person reviews it; the report lists it as a checklist
- Applies to
jsxvuesvelteastrohtml- Taught by the skill
fe-core-web-vitalsCore Web Vitals- Since version
- 0.1.0
Read it in the terminal
npx github:dawidolko/frontend-skills explain perf/yield-long-tasks