Чому ваш Time to First Byte повільний і що з цим робити

Почніть із того, що насправді вимірює TTFB

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

Звучить як серверна метрика, але це не лише серверна метрика. TTFB охоплює кілька етапів:

• DNS lookup, якщо hostname ще не розв’язано
• TCP connection setup
• TLS negotiation для HTTPS
• Час проходження запиту до сервера або CDN edge
• Очікування в черзі та обробка на сервері
• Час проходження відповіді назад до браузера

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

Це важливо, бо TTFB стоїть на початку ланцюжка завантаження. Якщо HTML-документ приходить пізно, браузер також пізно виявляє CSS, JavaScript, шрифти й зображення. Ви можете мати відмінну оптимізацію фронтенду, але сайт усе одно відчуватиметься повільним, якщо перша відповідь із документом займає 1,5 секунди.

Що вважається повільним TTFB?

Немає універсального числа, яке підходить для кожного сайту, регіону й архітектури. Але практичні пороги допомагають.

Рекомендації Google web.dev класифікують хороший TTFB як менший за 800 ms, 800–1800 ms — як такий, що потребує покращення, а понад 1800 ms — як поганий. Для добре закешованої маркетингової сторінки, що обслуговується поруч із користувачем, часто можна досягти значно кращого результату. Для складної автентифікованої панелі, яка виконує динамічну роботу, прийнятне число може бути вищим, але воно все одно має бути пояснюваним.

Важлива звичка — сегментувати це число. Глобальний середній TTFB у 900 ms може приховувати відповідь за 150 ms для користувачів поруч із вашим CDN edge і відповідь за 2200 ms для користувачів в іншому регіоні. Так само ваша головна сторінка може бути нормальною, тоді як пошук, категорії або сторінки для залогінених користувачів тихо створюють біль.

Вимірюйте не в одному місці

Не діагностуйте TTFB за одним запуском Lighthouse. Lighthouse корисний, але це один тест з одного середовища. Якщо ви тільки починаєте його інтерпретувати, почніть зі спокійного прочитання того, як читати звіт Lighthouse без паніки — головний урок у тому, щоб відокремлювати лабораторні сигнали від польової реальності.

Для TTFB вам потрібні щонайменше три погляди:

1. Інструменти розробника в браузері

Відкрийте панель Network, перезавантажте сторінку з вимкненим кешем і перегляньте основний запит документа. Розбивка часу показує фази DNS, connection, TLS, waiting і download. Фаза “waiting” часто є тим, що люди мають на увазі під часом бекенду, хоча вона може включати затримку upstream.

2. Синтетичні тести з кількох регіонів

Запускайте тести з локацій, близьких до ваших користувачів і віддалених від них. Якщо TTFB низький в одному регіоні й високий в іншому, перш ніж переписувати код застосунку, підозрюйте географію, маршрутизацію CDN, розміщення origin або покриття кешу.

3. Real user monitoring або серверні логи

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

Типові причини повільного TTFB

Ваш HTML не кешується

Це найпоширеніша проблема на контентних сайтах і сайтах електронної комерції. Статичні ресурси кешуються агресивно, але HTML-документ — те, що браузеру потрібно першим, — генерується на кожен запит.

Іноді це необхідно. Часто — ні.

Якщо публічна сторінка змінюється кілька разів на день, вона, ймовірно, не повинна вимагати свіжого рендерингу з бази даних для кожного анонімного відвідувача. Використовуйте full-page caching, edge caching, static generation або патерни stale-while-revalidate там, де це доречно.

Перевіряйте заголовки відповіді на сигнали на кшталт Cache-Control, CDN-Cache-Status, Age, Vary і Set-Cookie. Сторінка, яка надсилає унікальний cookie кожному відвідувачу, може випадково зробити себе некешованою. Якщо вам потрібен практичний спосіб міркувати про цей шар, ті самі звички налагодження з нашого посібника з редиректів і HTTP-заголовків у production напряму застосовуються до роботи з TTFB.

Ваш CDN кешує лише assets

Багато команд додають CDN і вважають, що роботу з продуктивністю завершено. Але якщо CDN обслуговує лише зображення, CSS і JavaScript, перший HTML-запит усе ще може проходити весь шлях до одного origin server.

Це може бути нормально для сайту локального бізнесу з локальними користувачами. Але це не нормально для міжнародної аудиторії. Що далі користувач від origin, то більшу затримку ви сплачуєте ще до того, як бекенд узагалі починає роботу.

Добре налаштування CDN для TTFB зазвичай означає:

• Кешувати публічний HTML там, де це безпечно
• Поважати навмисні правила обходу для автентифікованих або персоналізованих сторінок
• Уникати зайвих заголовків Vary, які надто дрібно розщеплюють кеш
• Використовувати purging або revalidation кешу замість повного вимкнення кешу
• Переконатися, що edge locations справді віддають hits, а не пересилають кожен запит далі

CDN — не магія. Це шар кешу й маршрутизації. Ставтеся до нього саме так.

Ваш сервер робить забагато перед відповіддю

Повільний шлях на бекенді може складатися з багатьох невеликих затримок: запити до бази даних, API calls, рендеринг шаблонів, перевірки feature flags, автентифікація, персоналізація, логування й cold starts.

Найгірший патерн — послідовна робота залежностей. Наприклад:

1. Отримати дані сторінки
2. Потім отримати пов’язані товари
3. Потім отримати ціни
4. Потім викликати сервіс рекомендацій
5. Потім відрендерити HTML

Якщо кожен крок чекає на попередній, TTFB швидко зростає. Паралельте незалежну роботу, прибирайте некритичні виклики з першої відповіді й кешуйте дорогі результати.

Корисне правило: якщо користувач не може побачити або використати результат негайно, він, імовірно, не повинен блокувати перший байт.

Запити до бази даних повільні або непередбачувані

Бази даних часто спричиняють проблеми TTFB, бо добре поводяться в розробці й погано — під реальним трафіком. Відсутні індекси, великі joins, N+1 queries, lock contention і надмірні набори результатів — усе це проявляється як “сервер повільний”.

Не вгадуйте тут. Збирайте timings запитів для повільних requests. Дивіться на p95 і p99, а не лише на середні значення. Сторінка, яка зазвичай відповідає за 120 ms, але іноді блокується на 4 секунди, усе одно створюватиме поганий користувацький досвід.

Поширені виправлення:

• Додавання або виправлення індексів
• Усунення патернів N+1 query
• Кешування даних із великою кількістю читань
• Пагінація великих запитів
• Винесення reporting або analytics queries з часу обробки request
• Встановлення розумних timeouts для downstream calls

Ваш застосунок має cold starts

Serverless і контейнеризовані платформи можуть бути чудовими, але cold starts можуть шкодити TTFB, коли трафік нерівномірний або регіони недозабезпечені ресурсами.

Якщо ваш перший запит після простою значно повільніший за наступні, дослідіть cold starts. Можливо, вам потрібні provisioned concurrency, менші bundles, менше startup dependencies, warmer functions або інша форма деплою для routes, чутливих до затримки.

Це не аргумент проти serverless. Це аргумент проти удавання, що runtime model невидима.

Редиректи марнують перший запит

Редирект додає ще один цикл request-response перед тим, як браузер отримує фінальний документ. Один редирект з http:// на https:// може бути неминучим для старих посилань, але ланцюжки марнотратні.

Поширені ланцюжки:

• http://example.com → https://example.com → https://www.example.com
• нормалізація trailing slash після нормалізації протоколу
• geo або language redirects перед cache lookup
• старі campaign links, які проходять через кілька URLs

Виправляйте вихідні посилання, де можливо, об’єднуйте правила редиректів і робіть canonical URLs прямими. Час редиректу не завжди відображається як TTFB для фінального запиту, але користувач усе одно за нього платить.

Практична послідовність налагодження

Коли TTFB виглядає повільним, використовуйте цей порядок. Він допомагає уникнути типової помилки — оптимізувати код застосунку до того, як підтверджено поведінку кешу й маршрутизації.

Step 1: Тестуйте основний документ, а не лише всю сторінку

Знайдіть запит до HTML-документа. Запишіть загальний TTFB і розбивку timings. Повторіть із кешем браузера та без нього. Якщо релевантно, протестуйте публічну сторінку, динамічну сторінку й сторінку для залогіненого користувача.

Step 2: Порівняйте регіони

Запустіть той самий URL з кількох географічних локацій. Якщо повільні регіони корелюють із відстанню до origin, пріоритезуйте CDN і edge caching. Якщо кожен регіон повільний, дивіться на обробку бекенду й capacity origin.

Step 3: Перевірте заголовки відповіді

Шукайте заголовки кешу, cookies, Age, статус CDN і Vary. Відсутній заголовок Age або повторні cache misses — це підказки. Широкий заголовок Vary: Cookie на публічному HTML часто вбиває кеш.

Step 4: Перевірте timing origin

Додайте інструментацію server timing. Заголовок Server-Timing може показувати фази бекенду, такі як час бази даних, час рендерингу й час upstream API. Навіть прості мітки корисні:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Тепер timings у браузері можуть показати, чи сервер витратив 300 ms на реальну роботу, чи затримка сталася до того, як запит дістався вашого застосунку.

Step 5: Виправте найбільшу підтверджену затримку

Це звучить очевидно, але команди часто виправляють те, що знайоме, а не те, що виміряно. Якщо домінують cache misses — виправляйте кешування. Якщо домінує база даних — виправляйте запити. Якщо TLS і connection setup домінують для глобальних користувачів — виправляйте маршрутизацію, покриття CDN або географію origin.

Фронтенд-робота все ще важлива. Шрифти, зображення й JavaScript впливають на те, що відбувається після прибуття HTML. Але вони не замінюють швидку першу відповідь. Якщо ви також працюєте над продуктивністю рендерингу, web fonts залишаються одним із найпростіших виграшів на багатьох сайтах, бо вони впливають на те, як швидко текст стає придатним для використання після прибуття документа.

Виправлення, які зазвичай працюють

Кешуйте публічний HTML на edge

Для маркетингових сторінок, документації, блогів, landing pages і сторінок категорій edge caching часто дає найбільше покращення TTFB. Використовуйте короткі TTL, якщо контент часто змінюється. Використовуйте stale-while-revalidate, якщо трохи застарілий контент прийнятний, поки кеш оновлюється у фоні.

Будьте обережні з персоналізацією. Якщо сторінка варіюється за валютою, мовою, станом логіну або experiment group, визначте ці варіанти явно. Випадкова per-user variation руйнує ефективність кешу.

Винесіть некритичну роботу з request path

Надсилання email, analytics enrichment, generation рекомендацій, webhook calls і важке логування рідко мають блокувати перший байт. Помістіть їх у queues або запускайте після того, як відповідь розпочато.

Скоротіть ланцюжки залежностей бекенду

Паралельте незалежні виклики. Кешуйте responses від повільних APIs. Встановлюйте timeouts. Проєктуйте fallback content для сервісів, які корисні, але не критичні.

Повільний віджет рекомендацій не повинен затримувати всю сторінку товару.

Розмістіть обчислення ближче до користувачів

Якщо ваші користувачі глобальні, а origin в одному регіоні, затримка є структурною. CDN caching може приховати значну її частину для публічного контенту. Для динамічного контенту розгляньте regional deployments, edge rendering для відповідних routes або перенесення APIs ближче до аудиторії.

Нехай редиректи будуть нудними

Канонікалізуйте URLs в один hop. Оновіть внутрішні посилання, щоб користувачі й crawlers переходили прямо до фінального місця призначення. Аудитуйте старі campaign URLs і міграції платформ. Редиректи легко ігнорувати, бо вони невидимі, коли працюють, але вони все одно коштують часу.

Чого не варто робити

Не женіться за ідеальним числом TTFB для кожного route. Автентифікований звіт, який виконує реальні обчислення, не поводитиметься як закешований допис у блозі.

Не використовуйте середній TTFB як єдину метрику. Percentiles важливі. Географія важлива. Тип сторінки важливий.

Не припускайте, що CDN означає, що ваш HTML закешовано. Перевірте це.

І не розглядайте TTFB окремо від продуктових рішень. Персоналізація, експерименти, real-time inventory і third-party services мають вартість у затримці. Деякі з них того варті. Деякі — просто звичка.

<!-- tool-cta:start -->

💡 Спробуйте це: Під час діагностики TTFB Get Headers показує стан кешу, серверні таймінги та перенаправлення, які часто пояснюють, звідки виникає затримка.

<!-- tool-cta:end -->

Спокійна версія плану

Повільний TTFB зазвичай можна виправити, щойно ви перестанете сприймати його як розмиту “серверну проблему”. Виміряйте запит документа. Сегментуйте за регіоном і типом сторінки. Перевірте заголовки. Порівняйте client timing з origin timing. Потім виправте найбільше підтверджене вузьке місце.

Більшості сайтів не потрібна екзотична архітектура. Їм потрібно менше уникненних cache misses, менше блокувальної роботи на бекенді, чистіші редиректи й чіткіше розуміння того, що має відбутися до відправлення першого байта.