Як покращити чуйність сайту: усунення 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 Tasks
- Chrome DevTools: Performance tab, трек Main, кольорові смуги.
- PerformanceObserver у production для збору польових даних.
- Бібліотека web-vitals для вимірювання INP у реальних умовах.
Як усунути Long Task: огляд методів
| Метод | Підтримка браузерів | Затримка перепланування | Зручність |
|---|---|---|---|
setTimeout(fn, 0) |
Всі | Мінімум 4 мс | Вимагає ручного чанкування |
scheduler.yield() |
Chrome 115+, Edge 115+ | ~0 мс (пріоритетне) | Вбудований yield |
requestIdleCallback |
Більшість мобільних і десктоп | Адаптивна | Тільки для некритичних |
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). Типовий результат:
| Метрика | До оптимізації | Після оптимізації |
|---|---|---|
| TBT | 1–3 с | <300 мс |
| INP | 400–600 мс | <200 мс |
Покращення INP мінімум на 30% — підтверджено досвідом більш ніж 30 проєктів.
Що входить в роботу та терміни
- Аудит профілювання: збір Long Task через DevTools та production-моніторинг, аналіз call stack. (2–3 дні)
- Code splitting та чанкування: розбивка великих chunks, lazy loading модулів.
- Винесення важких обчислень у Web Workers з побудовою WorkerPool.
- Віртуалізація довгих списків через react-virtual або аналоги.
- Оптимізація React-компонентів: startTransition, useDeferredValue, мемоізація.
- Повторний замір та звіт: порівняння INP/TBT до та після, рекомендації.
Повний цикл оптимізації для складного SPA — 2–4 тижні. Для простих сайтів із серверним рендерингом — 3–7 днів.
Скільки часу займає оптимізація?
Діагностика — 2–3 дні, повний цикл — від 2 до 4 тижнів для SPA, 3–7 днів для простих сайтів. Вартість аудиту — від $300, оптимізації під ключ — від $2000. Економія на серверних ресурсах може досягати $1500 на місяць.
Пропонуємо оптимізацію під ключ. Заповніть форму — ми оцінимо проект безкоштовно. Термін виконання від 2 днів. Пишіть нам для консультації. Отримайте безкоштовний аудит Long Tasks з рекомендаціями та планом оптимізації вже сьогодні.