TTFB, час відповіді та затримка: що вимірює кожен

Що означає кожен термін

Мережева затримка, яку часто наводять як round-trip time, - це час, який пакет проводить у дорозі до сервера й назад, без жодної роботи застосунку між цим. Її визначають фізична відстань, кількість переходів і якість маршруту. Ніщо у вашому коді її не змінює.

Час до першого байта (TTFB) вимірюють від моменту, коли клієнт починає запит, до моменту, коли до нього доходить перший байт відповіді. У цей відрізок входять DNS-пошук, TCP-з'єднання, TLS-рукостискання, час у дорозі самого запиту, те, що сервер робить, щоб сформувати відповідь, і зворотна дорога. Тому TTFB завжди більший за один round trip, зазвичай у кілька разів.

Час відповіді - найрозмитіший із трьох термінів. Більшість інструментів моніторингу використовують його для загального часу виконання запиту, від першого пакета до останнього байта тіла. Деякі інструменти вживають його як синонім TTFB. Перш ніж порівнювати два числа з підписом "час відповіді", перевірте, на чому саме кожен інструмент зупинив секундомір.

Як вимірюють кожен показник

Затримку отримують з ICMP echo, який і надсилає ping, або з таймінгу TCP-рукостискання, коли ICMP заблоковано. TTFB і загальний час дає сам HTTP-клієнт. Один виклик curl виводить усі межі одразу:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Кожне значення накопичувальне від початку запиту, тож читайте їх як межі, а не як тривалості. Відніміть попереднє значення, щоб отримати довжину окремого етапу.

Яке саме число показує ваш інструмент

Кожен інструмент показує інший зріз того самого запиту, і саме тому два виміри одного сайту зазвичай розходяться:

• ping показує лише затримку в обидва боки, без жодної роботи сервера
• curl -w показує всі межі, перелічені вище, тому саме він - еталон, коли числа не збігаються
• Інструменти розробника в браузері показують TTFB як етап очікування запиту, окремо від етапу завантаження нижче
• Lighthouse і PageSpeed показують час відповіді сервера, це і є TTFB для запиту документа
• Монітори аптайму показують час відповіді, чиє визначення різниться від продукту до продукту й зазвичай включає встановлення з'єднання від тієї точки, звідки виконано перевірку
• Моніторинг реальних користувачів показує польовий TTFB, агрегований по реальних відвідувачах на реальних мережах

Як виглядає хороше число

Затримку обмежує географія. Менш ніж 30 мс - норма в межах одного метрополісу, 50-100 мс через континент, 150-250 мс між континентами. Маршрут, що вимірюється значно гірше, ніж дозволяє відстань, свідчить радше про поганий шлях, ніж про повільний сервер.

Для TTFB web.dev вважає прийнятним 800 мс або менше, а все, що понад 1,8 секунди, - поганим, тоді як аудит часу відповіді сервера в Lighthouse починає провалюватися вище 600 мс. Орієнтуйтеся на менш ніж 600 мс для запиту документа й на 200 мс як ціль для всього кешованого чи відданого статично.

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

Як читати розриви

Окремі числа важать менше за відстань між ними, бо кожен розрив вказує на іншу підсистему:

• TTFB мінус затримка в обидва боки - це приблизно те, скільки думав сервер. Якщо саме це велика частина, проблема в коді застосунку, повільному запиті чи холодному кеші
• Connect мінус DNS-пошук - це один round trip на TCP-рукостискання. Якщо він набагато більший за виміряну затримку, мережевий шлях перевантажений або неправильно прокладений
• TLS мінус connect - це вартість рукостискання, зазвичай один-два додаткових round trip, і велике значення тут указує на проблеми з ланцюгом сертифікатів або відновленням сесії
• Total мінус TTFB - це час передачі. Якщо саме він домінує, відповідь завелика або з'єднання завільне, і жодне налаштування сервера тут не допоможе
• DNS-пошук сам по собі має займати кілька мілісекунд, щойно закешований. Стабільно повільний пошук - проблема резолвера чи авторитетного nameserver'а, а не вебсервера

Те саме прочитання працює і навпаки, коли повільно лише з однієї локації. Однаковий час "роздумів" сервера всюди, з різницею повністю в затримці й передачі, означає, що сервер у порядку, а маршрут - ні. Запустіть перевірку з кількох місць, перш ніж чіпати застосунок.

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

Щоб побачити ці числа для сторінки, не збираючи їх вручну, запустіть тест швидкості сторінки, який завантажує сторінку із зовнішньої точки і розбиває завантаження на етапи. Посібник з часу відповіді сервера описує той самий вимір із командного рядка. Одноразовий запуск розповідає лише про цю конкретну мить, тож якщо число важливе, поставте на нього заплановану перевірку: HostTracker вимірює час відповіді при кожній перевірці з понад 300 точок у 158 містах, і саме це перетворює одне вимірювання на базовий рівень, відносно якого можна помітити регресію. Більше визначень у розділі про поняття моніторингу.