तपाईं runtime jank, long task, र खराब INP कसरी diagnose गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

Runtime jank **main thread block गर्ने long task** बाट आउँछ — त्यो एउटै thread जसले JS, layout, paint, र input सम्हाल्छ। जब कुनै task धेरै लामो चल्छ, input process हुन सक्दैन, त्यसैले interaction जमेको जस्तो लाग्छ र **INP** बढ्छ।

## मूल model: main thread

```text
Main thread: [ event handler 180ms ]  input queued... rendered ─▶ INP = time until next paint
             └── a "long task" (>50ms) blocks everything, including responding to the click
```

INP ले प्रयोगकर्ता interaction देखि अर्को paint सम्मको ढिलाइ मापन गर्छ। यसका तीन भाग छन्: **input delay** (click गर्दा main thread व्यस्त), **processing time** (तपाईंको handler), र **presentation delay** (त्यसपछिको style/layout/paint)।

## Diagnosing

- **Performance panel** (Chrome DevTools): interaction record गर्नुहोस्, red-flag गरिएका **Long Task** (>50ms) र चौडा handler frame खोज्नुहोस्।
- field मा long task समात्न **PerformanceObserver**:

```js
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) report("longtask", entry.duration); // find real-user blockers
  }
}).observe({ type: "longtask", buffered: true });
```

## Fix

- **Long task तोड्नुहोस्** — काम chunk मा बाँड्नुहोस् र yield गर्नुहोस् ताकि input ले बीचमा interrupt गर्न सकोस्:

```js
async function process(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending?.()) await yieldToMain(); // let clicks through
  }
}
const yieldToMain = () => new Promise((r) => setTimeout(r, 0));
```

- **भारी compute Web Worker मा सार्नुहोस्** — parsing/crunching main thread बाहिर राख्नुहोस्।
- महँगा handler **Debounce/throttle** गर्नुहोस्; लामा list **virtualize** गर्नुहोस्; re-render घटाउन memoize गर्नुहोस्।
- `requestIdleCallback` वा `scheduler.postTask` priority सँग **जरुरी नभएको काम स्थगित गर्नुहोस्**।

## यो किन महत्त्वपूर्ण छ

INP नवीनतम Core Web Vital हो र सच्याउन सबैभन्दा गाह्रो किनभने यो load होइन *runtime* बारे हो। Senior हरूले एकल-thread model बाट तर्क गर्ने — long task ले input block गर्छ — र केवल "code optimize गर" भन्नुको सट्टा yielding, worker, र scheduling तिर पुग्ने अपेक्षा गरिन्छ।

मूल model: main thread

Diagnosing

Fix

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू