როგორ დიაგნოსტირებ runtime jank-ს, long task-ებსა და ცუდ INP-ს?

Question

IT Interview Practice · Accepted Answer

Runtime jank მოდის **long task-ებისგან, რომლებიც main thread-ს ბლოკავენ** — ერთადერთი thread, რომელიც JS-ს, layout-ს, paint-სა და input-ს ამუშავებს. როცა task ძალიან დიდხანს სრულდება, input ვერ მუშავდება, ამიტომ ინტერაქციები გაყინულად იგრძნობა და **INP** იზრდება.

## ძირითადი მოდელი: 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 ზომავს დაყოვნებას მომხმარებლის ინტერაქციიდან შემდეგ paint-მდე. მას აქვს სამი ნაწილი: **input delay** (main thread დაკავებულია, როცა აჭერ), **processing time** (შენი handler) და **presentation delay** (style/layout/paint შემდეგ).

## დიაგნოსტიკა

- **Performance panel** (Chrome DevTools): ჩაწერე ინტერაქცია, მოძებნე წითლად-მონიშნული **Long Tasks** (>50ms) და განიერი handler frame-ები.
- **PerformanceObserver** ველში long task-ების დასაჭერად:

```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 });
```

## შესწორებები

- **დაანაწევრე long task-ები** — დაანაწილე სამუშაო და დათმე კონტროლი, რომ input-მა შეძლოს ჩარევა:

```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));
```

- **გადაიტანე მძიმე გამოთვლა Web Worker-ში** — parsing/crunching main thread-ის გარეთ დაიტოვე.
- **Debounce/throttle** ძვირი handler-ები; **virtualize** გრძელი სიები; memoize ხელახალი render-ების შესამცირებლად.
- **გადადე არაგადაუდებელი სამუშაო** `requestIdleCallback`-ით ან `scheduler.postTask` პრიორიტეტებით.

## რატომ არის ეს მნიშვნელოვანი

INP არის უახლესი Core Web Vital და ყველაზე რთული გამოსასწორებელი, რადგან ის *runtime-ზეა*, არა ჩატვირთვაზე. senior-ებისგან მოსალოდნელია, რომ ერთძაფიანი მოდელიდან იმსჯელონ — long task-ები input-ს ბლოკავენ — და მიმართონ yielding-ს, worker-ებსა და scheduling-ს, არა უბრალოდ „ოპტიმიზირე კოდი“.

ძირითადი მოდელი: main thread

დიაგნოსტიკა

შესწორებები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები