TTFB, Time to First Byte, це час від старту переходу на сторінку до моменту, коли браузер отримує перший байт відповіді від сервера. Метрика охоплює не лише обробку запиту на сервері, а й весь мережевий шлях до нього: DNS-пошук, встановлення TCP-зʼєднання, узгодження TLS і очікування відповіді. За стандартом Google TTFB вважається хорошим при значенні до 800 мілісекунд. Прийнятним рахують діапазон 800-1800 мс, поганим усе, що вище, для 75-го перцентиля реальних завантажень сторінки.
Ця межа різко відрізняється від тієї, що трапляється на українських сайтах про хостинг. Там TTFB до 200 мс називають хорошим показником, а окремі матеріали допускають 2-3 секунди як норму. Розбіжність не випадкова і не є помилкою жодної зі сторін: джерела рахують різні речі під однією назвою. Розділ нижче показує, яку саме.
Чому оцінки TTFB відрізняються в різних джерелах у десятки разів
Термін TTFB використовують для двох різних вимірювань. Перше, повний TTFB, це показник Navigation Timing API браузера: час від старту навігації до події responseStart, з урахуванням редиректів, DNS, TCP, TLS і очікування першого байта. Саме його вимірює Chrome через поле CrUX і бібліотеку web-vitals. Саме для нього діють пороги 800 і 1800 мс. Друге, час відповіді бекенда, це вужчий показник: лише обробка запиту на сервері, без мережевого шляху до користувача. Його вимірює аудит Lighthouse “Reduce initial server response time” з межею 600 мс. Панелі хостингу зазвичай показують ще вужчий зріз, час виконання скрипта самим застосунком.
Українське джерело з нормою 200 мс описує саме цей вузький зріз: скільки часу CMS чи бекенд витрачає на генерацію відповіді, без урахування шляху пакетів до відвідувача. Джерело з нормою 2-3 секунди рахує навпаки, повний час з мережею, але спирається на застарілу практику, а не на актуальний стандарт Google. Обидва тексти правильні щодо власного визначення. Незіставними між собою вони стають через різні визначення.
З чого складається TTFB
Повний TTFB розкладається на чотири послідовні етапи. Час редиректу виникає, коли запит спершу йде на іншу адресу, наприклад з http на https. Він додає повний цикл запит-відповідь ще до початку основного зʼєднання. DNS-пошук перетворює домен на IP-адресу. Для повторного візиту цей етап часто відсутній завдяки кешу браузера чи резолвера. Встановлення зʼєднання охоплює TCP-рукостискання і, для HTTPS, узгодження TLS: разом це, як правило, два цикли обміну пакетами. Останній етап, очікування відповіді, це час від відправлення запиту до першого байта. Сюди входить і обробка на сервері, і час проходження пакетів мережею в обидва боки.
| Етап TTFB | Що входить | Коли відсутній |
|---|---|---|
| Редирект | Повний цикл запит-відповідь на проміжну адресу | Прямий запит без переадресації |
| DNS-пошук | Перетворення домену на IP-адресу | Запис вже в кеші браузера чи резолвера |
| Зʼєднання і TLS | TCP-рукостискання і узгодження шифрування | Повторне використання наявного HTTP/2 чи HTTP/3 зʼєднання |
| Очікування відповіді | Обробка запиту сервером і мережевий шлях байта назад | Присутнє завжди |
Скільки мілісекунд забирає сама відстань до сервера
Частину TTFB визначає не сервер, а фізика поширення сигналу у волоконному кабелі, приблизно 200000 км за секунду, що відповідає коефіцієнту заломлення скла близько 1,5. Це дає нижню межу затримки, яку не здолає жодна оптимізація коду. Для класичного зʼєднання TCP плюс TLS 1.3 потрібно щонайменше три цикли обміну пакетами до першого байта відповіді. Перший цикл встановлює TCP, другий узгоджує TLS, третій передає сам HTTP-запит і початок відповіді.
Розрахунок за координатами міст показує різницю наочно. Відстань по прямій від Києва до Варшави становить приблизно 690 км. До Франкфурта, поширеного вузла європейського хостингу, приблизно 1550 км. До Ашберна у Вірджинії, одного з головних дата-центрів США, приблизно 7850 км. Поділивши відстань на швидкість поширення сигналу, отримуємо теоретичний мінімум одного циклу обміну: близько 7 мс для Варшави, 16 мс для Франкфурта, 78 мс для Ашберна. Помноживши на три цикли, потрібні до першого байта, отримуємо фізичну нижню межу TTFB ще до будь-якої обробки на сервері.
| Локація сервера | Відстань від Києва | Мінімум на 1 цикл обміну | Фізичний мінімум TTFB (3 цикли) |
|---|---|---|---|
| Варшава | ~690 км | ~7 мс | ~21 мс |
| Франкфурт | ~1550 км | ~16 мс | ~47 мс |
| Ашберн, США | ~7850 км | ~78 мс | ~235 мс |
Реальні мережеві маршрути довші за пряму лінію через відсутність прямого кабелю і додаткові вузли. Фактична затримка звичайно перевищує розрахунок в 1,3-2 рази. Висновок з таблиці прямий: заявлені 200 мс як універсальна норма фізично недосяжні для сайту на сервері у США відносно українського відвідувача, незалежно від якості коду. Той самий сайт на сервері у Варшаві чи Франкфурті вкладається в цю межу з запасом.
TTFB і Core Web Vitals
TTFB не входить до складу Core Web Vitals: цей статус мають Largest Contentful Paint, Interaction to Next Paint і Cumulative Layout Shift. Проте TTFB передує кожній із цих метрик, бо жоден піксель контенту не зʼявиться раніше, ніж браузер отримає перший байт розмітки. Високий TTFB автоматично зсуває нижню межу LCP. Якщо перший байт прийшов через 1,5 секунди, найбільший контентний елемент фізично не може відмалюватись раніше цієї позначки.
Залежність несиметрична для різних архітектур. Сайт, що рендериться на сервері й одразу віддає готову розмітку, отримує пряму вигоду від низького TTFB: контент зʼявляється майже одразу після першого байта. Односторінковий застосунок, що довантажує JavaScript і будує розмітку в браузері, залежить від TTFB менше. Навіть швидка відповідь сервера не врятує повільний рендеринг на клієнті, якщо скрипти важкі.
Як виміряти TTFB правильно
Польові дані, зібрані з реальних відвідувачів через Chrome User Experience Report, показують TTFB так, як його бачить аудиторія сайту, включно з повільними мережами і віддаленими регіонами. Лабораторні дані, отримані одним прогоном Lighthouse чи PageSpeed Insights з одного дата-центру, відображають умови конкретного тесту і часто відрізняються від польових. Для перевірки власного сайту зручні три інструменти. Перший, вкладка Network у Chrome DevTools з рядком “Waiting for server response”. Другий, розділ Core Web Vitals у Google Search Console з польовими даними за 28 днів. Третій, бібліотека web-vitals із функцією onTTFB для вимірювання просто в коді сторінки.
Чому Lighthouse і панель хостингу показують різні цифри для одного сайту
Розбіжність з розділу вище повторюється на практиці щоразу, коли власник сайту звіряє два звіти. Lighthouse і GTmetrix виводять окремий аудит часу відповіді бекенда з межею 600 мс. Цей аудит навмисно ігнорує мережевий шлях до користувача, бо тестує лише локальну обробку запиту сервером. Панель хостингу найчастіше показує ще вужчий показник, час виконання скрипта на боці застосунку, без TCP і TLS. Жоден із цих звітів не бреше: обидва вимірюють вужчий фрагмент того самого шляху. Порівнювати варто лише показники з однаковим визначенням, польовий TTFB з польовим, лабораторний з лабораторним.
Як знизити TTFB
Розташування сервера ближче до аудиторії дає найбільший ефект за розрахунком вище. Перенесення хостингу з США до Європи здатне зрізати понад 150 мс лише за рахунок фізичної відстані. CDN з крайовими вузлами в регіоні аудиторії досягає того самого результату без переїзду основного сервера, а сучасні CDN додатково додають підтримку HTTP/3 і TLS 1.3, що скорочує кількість циклів обміну до узгодження зʼєднання. Кешування статичного і напівстатичного контенту на рівні сервера чи CDN усуває звернення до бази даних при кожному запиті. Для сторінок, що змінюються рідко, підходить стратегія stale-while-revalidate: застарілу версію віддають миттєво, а оновлюють у фоні.
Прибирання зайвих редиректів усуває цілий цикл запит-відповідь ще до основного зʼєднання. Перехід з http на https варто закривати заголовком Strict-Transport-Security і списком HSTS preload, а не ланцюжком редиректів. Заголовок Server-Timing дає змогу побачити, скільки часу займають запити до бази даних і рендеринг на сервері окремо від мережевої частини. Це перетворює здогад на вимірювання. Технологія 103 Early Hints дозволяє серверу надіслати браузеру підказки про критичні ресурси, поки основна відповідь ще формується. Частина роботи паралелиться, замість того щоб виконуватись послідовно.
Обмеження: коли низький TTFB не рятує швидкість сторінки
Низький TTFB не гарантує швидке завантаження сторінки для відвідувача. Якщо після першого байта браузер має завантажити важкі render-blocking стилі чи скрипти, LCP все одно затримається, попри миттєву відповідь сервера. Односторінкові застосунки з великим обсягом клієнтського JavaScript отримують від зниження TTFB менше приросту, ніж сайти з серверним рендерингом. Інвестиції варто зважувати проти архітектури конкретного проєкту. Для інтернет-магазину з десятками зовнішніх скриптів аналітики зниження TTFB на 100 мс матиме менший ефект на сприйняту швидкість, ніж прибирання зайвих сторонніх підключень.
