Усунення Long Tasks: як оптимізувати INP та чуйність сайту

Як покращити чуйність сайту: усунення Long Tasks та оптимізація INP

Уявіть: користувач клікає на кнопку, а інтерфейс завмирає на півсекунди. Це Long Task — задача в main thread браузера тривалістю понад 50 мс. INP (Interaction to Next Paint) — метрика Core Web Vitals — безпосередньо страждає від таких задач. За даними Interaction to Next Paint (INP), затримки понад 200 мс знижують конверсію до 3%. Розуміння циклу подій (event loop) та мікрозадач допомагає ефективно планувати виконання; використання requestAnimationFrame для анімацій уникає зайвих рефловів та репайнтів. Наша команда спеціалізується на виявленні та усуненні Long Tasks у складних SPA. За 5+ років роботи ми оптимізували понад 30 проєктів, домігшись зниження INP з >500 мс до <200 мс. Замовники відзначають зростання залученості та зниження відмов після оптимізації. Крім того, зменшення TBT (Total Blocking Time) прямо економить ресурси сервера, знижуючи витрати на підтримку до $1500 на місяць.

Чому Long Tasks блокують інтерфейс?

Кожна Long Task довша за 50 мс блокує обробку користувацького введення: клік, скрол, натискання клавіші. INP фіксує найгіршу затримку відгуку на взаємодію. Усунення Long Tasks — прямий шлях до покращення Core Web Vitals і зростання конверсії. Ми гарантуємо покращення INP мінімум на 30% після оптимізації.

Як знайти Long Task в production?

Відкриваємо Chrome DevTools → вкладка Performance → починаємо запис → імітуємо завантаження або взаємодію → зупиняємо. На треці Main видно червоні трикутники на задачах довших за 50 мс. Клікаємо по задачі — в нижній панелі call tree показує, які функції були викликані та скільки часу зайняла кожна. Ключові метрики: Total Blocking Time (сума (duration - 50ms) по всіх Long Tasks), частки Scripting, Rendering, Painting.

Для production-профілювання використовуємо PerformanceObserver. Він відправляє дані про Long Tasks на сервер для аналізу. Ось приклад відправки:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    navigator.sendBeacon('/api/longtasks', JSON.stringify({
      duration: entry.duration,
      startTime: entry.startTime,
      url: location.href,
      userAgent: navigator.userAgent,
    }));
  }
});
observer.observe({ type: 'longtask', buffered: true });

Як усунути Long Task: огляд методів

scheduler.yield() забезпечує мінімальну затримку та автоматично передає управління при настанні подій введення. Він у 5 разів ефективніший за setTimeout за рахунок пріоритезації взаємодій.

Практичні патерни оптимізації

Як розбити задачу на чанки з scheduler.yield?

Найпряміший спосіб усунути Long Task — розбити її на частини і між частинами передавати управління браузеру. Сучасний підхід через scheduler.yield() (Chrome 115+):

async function processLargeArrayModern(items) {
    const CHUNK_SIZE = 100;
    for (let i = 0; i < items.length; i += CHUNK_SIZE) {
        const chunk = items.slice(i, i + CHUNK_SIZE);
        chunk.forEach(processItem);
        if (i + CHUNK_SIZE < items.length) {
            await scheduler.yield();
        }
    }
}

Поліфіл для браузерів без scheduler.yield() використовує MessageChannel — затримка ~0 мс.

Чому варто виносити обчислення в Web Workers?

Важкі обчислення, що не працюють з DOM (парсинг JSON, криптографія, складні сортування), виносимо в Worker. Приклад WorkerPool:

// main.js
class WorkerPool {
  constructor(workerScript, poolSize = navigator.hardwareConcurrency || 4) {
    this.workers = Array.from({ length: poolSize }, () => new Worker(workerScript));
    this.queue = [];
    this.available = [...this.workers];
  }

  run(type, payload) {
    return new Promise((resolve, reject) => {
      const task = { type, payload, resolve, reject };
      if (this.available.length > 0) {
        this._dispatch(task);
      } else {
        this.queue.push(task);
      }
    });
  }

  _dispatch({ type, payload, resolve, reject }, worker = this.available.pop()) {
    worker.onmessage = ({ data }) => {
      resolve(data.result);
      this.available.push(worker);
      if (this.queue.length > 0) this._dispatch(this.queue.shift());
    };
    worker.onerror = reject;
    worker.postMessage({ type, payload });
  }
}

const pool = new WorkerPool('/heavy-worker.js', 2);
const sortedProducts = await pool.run('SORT_PRODUCTS', products);

React: startTransition і useDeferredValue

React 18 дозволяє явно розмежувати термінові та нетермінові оновлення. startTransition для некритичних оновлень стану:

import { startTransition, useState } from 'react';

function SearchPage() {
  const [inputValue, setInputValue] = useState('');
  const [searchQuery, setSearchQuery] = useState('');

  function handleInput(e) {
    const value = e.target.value;
    setInputValue(value);
    startTransition(() => setSearchQuery(value));
  }

  return (
    <>
      <input value={inputValue} onChange={handleInput} />
      <SearchResults query={searchQuery} />
    </>
  );
}

useDeferredValue для списків: відкладає оновлення фільтра.

Як віртуалізація списків прискорює рендеринг?

Рендеринг тисяч DOM-елементів — одна велика Long Task. Віртуалізація рендерить лише видимі елементи. Приклад з @tanstack/react-virtual:

import { useVirtualizer } from '@tanstack/react-virtual';

function VirtualList({ items }) {
  const parentRef = useRef(null);
  const virtualizer = useVirtualizer({
    count: items.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 72,
    overscan: 5,
  });

  return (
    <div ref={parentRef} style={{ height: '600px', overflow: 'auto' }}>
      <div style={{ height: virtualizer.getTotalSize() }}>
        {virtualizer.getVirtualItems().map(virtualItem => (
          <div
            key={virtualItem.key}
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              transform: `translateY(${virtualItem.start}px)`,
            }}
          >
            <ListItem item={items[virtualItem.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

Вимірювання результату

До та після оптимізації вимірюємо в лабораторних умовах (Lighthouse, 4× CPU throttle, 3G) та в польових (INP через web-vitals). Типовий результат:

Покращення INP мінімум на 30% — підтверджено досвідом більш ніж 30 проєктів.

Що входить в роботу та терміни

1. Аудит профілювання: збір Long Task через DevTools та production-моніторинг, аналіз call stack. (2–3 дні)
2. Code splitting та чанкування: розбивка великих chunks, lazy loading модулів.
3. Винесення важких обчислень у Web Workers з побудовою WorkerPool.
4. Віртуалізація довгих списків через react-virtual або аналоги.
5. Оптимізація React-компонентів: startTransition, useDeferredValue, мемоізація.
6. Повторний замір та звіт: порівняння INP/TBT до та після, рекомендації.

Повний цикл оптимізації для складного SPA — 2–4 тижні. Для простих сайтів із серверним рендерингом — 3–7 днів.

Скільки часу займає оптимізація?

Діагностика — 2–3 дні, повний цикл — від 2 до 4 тижнів для SPA, 3–7 днів для простих сайтів. Вартість аудиту — від $300, оптимізації під ключ — від $2000. Економія на серверних ресурсах може досягати $1500 на місяць.

Пропонуємо оптимізацію під ключ. Заповніть форму — ми оцінимо проект. Термін виконання від 2 днів. Пишіть нам для консультації. Отримайте аудит Long Tasks з рекомендаціями та планом оптимізації вже сьогодні.