Оптимізація Total Blocking Time (TBT) сайту під ключ

Оптимізація Total Blocking Time (TBT) сайту під ключ

Високий Total Blocking Time — головна причина поганого INP (Interaction to Next Paint) і, як наслідок, втрати конверсії. Ми бачимо це на кожному другому аудиті: сайти з React та Next.js нерідко показують TBT понад 500 мс, що безпосередньо погіршує користувацький досвід. Наша команда з 5+ років досвіду в оптимізації Core Web Vitals знає, як знизити TBT до зеленої зони — менше 200 мс на десктопі та 300 мс на мобільному пристрої з троттлінгом CPU 4×.

TBT складається з довгих задач (Long Tasks), кожна з яких триває понад 50 мс. Якщо виконати три задачі по 80 мс, блокування складе 90 мс. Кожна така мілісекунда відкладає відмальовку наступного кадру, збільшуючи час до повної інтерактивності. Зниження TBT на 100 мс може покращити INP на 30–50%, що підтверджують польові виміри https://web.dev/articles/inp.

Ми пропонуємо комплексну оптимізацію TBT під ключ: від діагностики до впровадження моніторингу. Замовте аудит — і ми підготуємо план з термінами та оцінкою ефекту без оплати.

Як діагностувати причини високого TBT?

Перший крок — знайти Long Tasks. Chrome DevTools, вкладка Performance: записуємо завантаження сторінки, дивимося червоні смуги над main thread. Програмно використовуємо Long Task API:

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log({ name: entry.name, duration: entry.duration, startTime: entry.startTime, attribution: entry.attribution, }); } }); observer.observe({ type: 'longtask', buffered: true }); // Дані можна відправляти в аналітику через fetch з keepalive 

attribution покаже, в якому фреймі або скрипті виникла задача. Це перший крок до точкової оптимізації.

Причина №1: важкий JavaScript при старті

Найчастіша причина високого TBT — великий JS-бандл, який парситься та виконується синхронно при завантаженні. Кожен мегабайт JS потребує ~1 секунди парсингу на середньому мобільному пристрої. Рішення — code splitting + lazy loading:

const HeavyChart = lazy(() => import('./HeavyChart')); const DataTable = lazy(() => import('./DataTable')); function Dashboard() { const [showChart, setShowChart] = useState(false); return ( <div> <button onClick={() => setShowChart(true)}>Показати графік</button> {showChart && ( <Suspense fallback={<Skeleton />}> <HeavyChart /> </Suspense> )} </div> ); } 

Для роутів — React.lazy + react-router. Code splitting знижує TBT у 2–3 рази, оскільки initial chunk стає менше 150 kB gzip.

Причина №2: синхронні сторонні скрипти

Google Tag Manager, чати, пікселі рекламних мереж — кожен сторонній скрипт може створювати Long Tasks. Діагностика в Chrome DevTools: Performance → Bottom-up → групування за доменом. Рішення:

<!-- Використовуємо async або defer: --> <script src="https://widget.example.com/chat.js" async></script> <!-- Або відкладене завантаження після взаємодії: --> <script> function loadChat() { const s = document.createElement('script'); s.src = 'https://widget.example.com/chat.js'; document.head.appendChild(s); } ['click', 'scroll', 'keydown'].forEach(event => { window.addEventListener(event, loadChat, { once: true }); }); </script> 

Для GTM: відкладений запуск тригера «DOM Ready» замість «Page View» для некритичних тегів.

Причина №3: важкі обчислення в main thread

Сортування великих масивів, складні DOM-маніпуляції — все це блокує main thread. Web Worker вивантажує обчислення в окремий потік:

// worker.js self.onmessage = function(e) { const { data, operation } = e.data; let result; switch (operation) { case 'sort': result = heavySort(data); break; case 'filter': result = complexFilter(data); break; } self.postMessage(result); }; // main.js const worker = new Worker('/worker.js'); worker.postMessage({ data: largeArray, operation: 'sort' }); worker.onmessage = (e) => setTableData(e.data); 

Для розбивання довгих синхронних циклів використовуйте scheduler.yield() (Chrome 94+) або поліфіл через setTimeout.

Причина №4: важкий hydration в SSR/SSG

Next.js, Nuxt, Gatsby — при hydration фреймворк повторно обходить весь DOM. Рішення: Partial hydration (Islands architecture), Progressive hydration, React 18 startTransition:

import { startTransition } from 'react'; function SearchResults() { const [results, setResults] = useState([]); function handleSearch(newQuery) { startTransition(() => setResults(fetchResults(newQuery))); } } 

Як виміряти TBT у польових умовах?

TBT не можна виміряти в браузері безпосередньо, але INP — його production-аналог. Використовуємо web-vitals:

npm install web-vitals 

import { onINP } from 'web-vitals'; function sendToAnalytics(metric) { navigator.sendBeacon('/api/vitals', JSON.stringify({ name: metric.name, value: metric.value, rating: metric.rating, id: metric.id, url: location.href })); } onINP(sendToAnalytics); 

Налаштовуємо алерти при виході INP за межі зеленої зони.

Порівняння методів оптимізації TBT

Що робити, якщо TBT залишається високим?

Якщо після базових оптимізацій TBT все ще високий, рекомендуємо провести профілювання за допомогою Chrome DevTools та визначити додаткові Long Tasks. Іноді причиною є неоптимальне використання фреймворку або занадто великі зображення. У таких випадках варто звернутися до фахівців.

Що входить у роботу

• Діагностика TBT та Long Tasks зі звітом за джерелами блокування
• План оптимізації з конкретними кроками та оцінкою ефекту
• Впровадження code splitting, lazy loading, Web Workers
• Оптимізація сторонніх скриптів та hydration
• Налаштування польового моніторингу INP з алертами
• Передача документації та доступів до інструментів
• Безкоштовна консультація та підтримка 2 тижні після здачі

Терміни та вартість

Діагностика та складання плану — 1–2 робочих дні (2000 грн). Code splitting + ліниве завантаження типового React-додатку — 3–5 робочих днів (від 5000 грн). Повний цикл: діагностика, оптимізація, налаштування моніторингу INP у продакшні — 1,5–3 тижні від 8000 грн. Вартість розраховується індивідуально після аудиту.

Зв'яжіться з нами — ми оцінимо ваш проект та підготуємо план оптимізації TBT з гарантією результату.