मुझे बताइए कि click handler चलने और स्क्रीन पर अगला frame दिखने के बीच ब्राउज़र असल में क्या करता है।

click handler एक अकेले task की तरह पूरा चलता है। उसने जितने भी microtasks कतार में डाले, resolved promise callbacks समेत, वे सब अगले नंबर पर निपटते हैं, उससे पहले और कुछ नहीं होता। उसके बाद ही, अगर frame का समय हुआ है, ब्राउज़र requestAnimationFrame callbacks चलाता है और style, layout, paint तथा composite से गुज़रता है। कोई लंबा task या microtasks की न खत्म होने वाली कड़ी उस frame को टाल देती है, और यूज़र उस देरी को jank की तरह महसूस करता है।

handler खुद main thread पर एक task है, तो वह शुरू से आखिर तक बिना किसी रुकावट के चलता है। लौटते ही ब्राउज़र microtask queue निपटाता है, तो कोई भी await का continuation या promise then callback वहीं चल जाता है, और अगर वे और microtasks कतार में डालते रहें तो ब्राउज़र को paint करने का मौका कभी नहीं मिलता। वह queue खाली होने पर, और तभी अगर सच में frame का समय हुआ है, ब्राउज़र requestAnimationFrame callbacks चलाता है, style दोबारा निकालता है, layout करता है, paint और composite करता है। इसीलिए मैं लंबे tasks को असली दुश्मन मानता हूं। एक dashboard पर जिस पर मैंने काम किया, filter बदलने पर handler में लगभग चालीस हज़ार rows की synchronous sort होती थी, और click करीब दो सौ मिलीसेकंड तक मरा हुआ लगता था। इसे तोड़कर handler को सिर्फ input अपडेट करने देना, फिर महंगे हिस्से से पहले scheduler.yield से मौका देना, इससे frame का बजट बचा रहा और कुल काम बिल्कुल उतना ही होने के बावजूद interaction तुरंत जवाब देने लगा।