TTFB: Що це таке?

TTFB, це та абревіатура, яку постійно згадують в аудитах швидкості сайту, PageSpeed Insights, GTmetrix, і будь-хто, хто хоч раз намагався розібратися, чому сайт “повільний”, неодмінно на неї натикається. Але тут є нюанс, який чомусь рідко пояснюють до кінця: показник справді важливий, але не настільки вирішальний, як його часто подають, і про це навіть прямо говорив представник Google.

Що таке TTFB

Time to First Byte, це час, який минає від моменту, коли браузер надсилає запит на сторінку, до моменту, коли він отримує від сервера перший байт відповіді. Простими словами, це не час повного завантаження сторінки, а лише момент, коли сервер взагалі почав відповідати. Це радше старт забігу, а не фінішна пряма, тому TTFB нічого не говорить про те, коли реально прогрузиться основний контент, зображення чи скрипти.

З чого складається цей час

• DNS-пошук. Час, потрібний для перетворення доменного імені в конкретну IP-адресу сервера.
• TCP і TLS-рукостискання. Встановлення з’єднання між браузером і сервером, включно з узгодженням шифрування для захищеного HTTPS-з’єднання.
• Обробка запиту на сервері. Час, потрібний backend-коду, базі даних чи CMS, щоб згенерувати саму сторінку.
• Передача першого байта. Момент, коли сервер починає фактично відправляти дані назад браузеру.

Які значення вважаються хорошими

За офіційними рекомендаціями Google у межах Core Web Vitals, показник до 800 мілісекунд вважається хорошим, від 800 до 1800 мілісекунд потребує покращення, а понад 1800 мілісекунд вважається поганим результатом. Варто зауважити, що в деяких старіших матеріалах і навіть інструментах досі фігурує інший орієнтир, 200 мілісекунд, це залишок ще з попередніх версій рекомендацій PageSpeed, тому якщо бачите розбіжність між джерелами, орієнтуйтеся саме на актуальний поріг 800 мілісекунд з документації web.dev.

Той нюанс, про який мовчить більшість матеріалів

Тут криється контрінтуїтивний, але важливий момент. Джон Мюллер з Google прямо коментував цю тему, і його позиція дещо відрізняється від того, як TTFB часто подають в SEO-статтях:

TTFB (time-to-first-byte) optimization is not an indicator of good user experience.

Він пояснював, що Google оцінює загальну картину завантаження сайту, а не окремі проміжні метрики самі по собі. Тобто відмінний TTFB ще не гарантує гарного досвіду користувача, якщо після отримання першого байта сторінка все одно довго рендериться через важкі скрипти чи неоптимізовані зображення. TTFB, це необхідна, але не достатня умова швидкого сайту.

Як виміряти власний TTFB

Найпростіше скористатися вкладкою “Мережа” в інструментах розробника Chrome, там TTFB видно прямо в деталях конкретного запиту. Для глибшого аналізу з різних географічних точок підійдуть WebPageTest чи GTmetrix, а Google PageSpeed Insights одразу покаже показник у контексті інших метрик Core Web Vitals.

Як реально знизити TTFB

• CDN. Мережа доставки контенту кешує статичні дані ближче географічно до конкретного користувача, скорочуючи мережеву затримку.
• Кешування на рівні сервера. Уникає повторної важкої генерації тієї самої сторінки для кожного нового запиту.
• Оновлення хостингу. Слабкий, перевантажений чи погано налаштований сервер, одна з найпоширеніших причин високого TTFB.
• Оптимізація запитів до бази даних. Неефективні SQL-запити чи застаріла версія PHP суттєво уповільнюють саме етап обробки запиту на сервері.
• Скорочення ланцюжків редиректів. Кожен додатковий редирект додає окремий цикл DNS і TCP-з’єднання ще до того, як почнеться завантаження фінальної сторінки.

Наостанок

TTFB, це важлива, але лише початкова частина загальної картини швидкості сайту, момент, коли сервер узагалі почав відповідати, а не показник того, наскільки швидко сторінка стане повністю функціональною для користувача. Оптимізувати його варто, але не варто й переоцінювати, як прямо зазначав представник Google, гарний TTFB сам по собі ще не гарантує гарного досвіду користувача, якщо решта етапів завантаження лишаються повільними.