Скоротіть час до отримання першого байта від сервера

Час до першого байта (TTFB) — це один із найважливіших показників продуктивності сайту, який безпосередньо впливає на швидкість відображення контенту, Core Web Vitals і навіть позиції в пошуку. Коли сервер довго «думає», користувач чекає, а браузер просто стоїть у черзі.

У 2026 році Google продовжує орієнтуватися на полеві дані CrUX, де хороший TTFB — до 0,8 секунди на 75-му перцентилі. Багато сайтів досі перевищують цю межу через неоптимізований бекенд, неправильне кешування або географічну відстань. Нижче — глибокий розбір, як реально скоротити цей показник.

Ми розберемо механізм формування TTFB, типові причини затримок, практичні методи оптимізації на рівні хостингу, коду, протоколів і мережі, а також помилки, які часто нівелюють усі зусилля.

Що саме входить у час до першого байта

TTFB — це інтервал від моменту, коли браузер починає навігацію (або надсилає запит), до отримання першого байта відповіді. Він включає кілька етапів: редиректи, DNS-пошук, встановлення TCP-з’єднання, TLS-handshake, обробку запиту на сервері та повернення першого байта.

Важливо розрізняти «повний» Navigation TTFB (той, що бачить Google у CrUX) і «серверну» частину (Waiting for server response у DevTools). Остання показує лише час обробки на origin, тоді як повний показник ураховує мережу. Саме тому лабораторні тести часто дають кращі цифри, ніж реальні користувачі з інших регіонів.

Високий TTFB тягне за собою всі наступні метрики: FCP, LCP, навіть INP. Якщо перший байт приходить через 1,2–1,5 секунди, шанси вкластися в хороші Core Web Vitals різко падають. Особливо болісно це відчувається на мобільних мережах із високою затримкою.

Як правильно виміряти TTFB у 2026 році

Почніть із Chrome DevTools: вкладка Network → Timing. Там видно розбивку на DNS, Connect, SSL, Waiting (TTFB) і Content Download. Для більш точних даних використовуйте curl з прапорцями:

curl -w “dns: %{time_namelookup}nconnect: %{time_connect}ntls: %{time_appconnect}nttfb: %{time_starttransfer}n” -o /dev/null -s https://your-site.com/

Це дозволяє розділити мережеві та серверні затримки. Для полевих даних дивіться Chrome User Experience Report або Search Console. PageSpeed Insights показує як lab, так і field, але саме field важливіший.

Корисні сервіси: WebPageTest (з кількох локацій), DebugBear, Cloudflare Analytics або власний RUM. Вимірюйте окремо статичні та динамічні сторінки, різні географії та типи пристроїв. Один показник «середній TTFB» майже нічого не каже — дивіться p75 і p95.

Головні причини високого TTFB

Найчастіше проблема криється не в одному місці, а в комбінації факторів. Ось найпоширеніші у 2026 році:

• Повільний або перевантажений хостинг (shared-тарифи з «шумними сусідами»).
• Відсутність або неправильне кешування HTML на рівні сервера чи CDN.
• Важкі запити до бази даних, N+1 проблеми, відсутність індексів.
• Ланцюжки редиректів (http → https → www → мова).
• Застарілі протоколи (HTTP/1.1, TLS 1.2) і відсутність session resumption.
• Географічна відстань між користувачем і origin-сервером.
• Синхронні виклики зовнішніх API на критичному шляху.
• Холодні старти (особливо на serverless і деяких PHP-FPM конфігураціях).

У реальних кейсах часто виявляється, що 60–70 % TTFB припадає саме на серверну обробку, а решта — на мережу. Якщо origin у Європі, а користувач у Азії чи Південній Америці, навіть ідеальний бекенд дасть 300–500 мс лише на RTT.

Оптимізація на рівні сервера та бекенду

Перший і найефективніший крок — зробити так, щоб сервер якомога швидше починав віддавати відповідь. Для PHP-сайтів (WordPress, Laravel тощо) критично важливий page cache. FastCGI Cache у Nginx або Varnish можуть знизити серверну частину TTFB з 400–800 мс до 20–50 мс на cache hit.

Оптимізуйте базу даних: додайте індекси, уникайте SELECT *, використовуйте eager loading замість N+1, винесіть важкі обчислення в черги. Профілюйте запити (EXPLAIN, slow query log). У багатьох проєктах одна повільна вибірка дає +200–400 мс до кожного запиту.

Оновіть runtime: PHP 8.3/8.4 значно швидший за 7.x і навіть 8.0. Увімкніть OPcache, JIT (де доречно), keep-alive до upstream. Для Node.js і Python — уникайте блокуючих операцій на критичному шляху, використовуйте streaming там, де можливо.

Налаштуйте веб-сервер: у Nginx — worker_processes auto, keepalive, http2/http3, pre-compressed assets (gzip_static, brotli_static). TLS 1.3 + session tickets суттєво скорочують handshake для повторних відвідувачів.

CDN, edge-кешування та сучасні протоколи

CDN — найпотужніший інструмент для глобального TTFB. Edge-ноди ближче до користувача зменшують мережеву частину, а кешування HTML на edge може взагалі прибрати origin з рівняння. Cloudflare, Fastly, Bunny, KeyCDN дають TTFB 20–80 мс на cache hit майже з будь-якої точки світу.

Важливо правильно налаштувати Cache-Control: s-maxage для CDN, stale-while-revalidate для балансу свіжості та швидкості. Для WordPress працює Cloudflare APO або аналоги — вони кешують HTML з урахуванням cookies і query-параметрів.

HTTP/3 (QUIC) і TLS 1.3 зменшують кількість round-trip і краще поводяться на нестабільних мобільних мережах. 103 Early Hints дозволяє браузеру починати завантаження критичних ресурсів, поки сервер ще готує повну відповідь. Speculation Rules API у сучасних браузерах може довести TTFB до майже нуля для наступних сторінок через prerender.

Поширені помилки, які зводять оптимізацію нанівець

Багато хто вмикає кешування плагіном, але залишає виключення для залогінених користувачів, адмінки або сторінок з персоналізацією — і cache hit rate падає нижче 30 %. Або ставить CDN, але не налаштовує правильні заголовки, і edge просто проксує все на origin.

Інша класика — ланцюжки редиректів. Кожен додатковий hop додає повний RTT. Рішення: HSTS preload + канонічні правила на рівні CDN або веб-сервера. Також часто забувають про cold starts на serverless або після деплою — потрібен prewarming.

Синхронні сторонні сервіси (платежі, рекомендації, аналітика) на критичному шляху — ще одна пастка. Краще виносити їх у асинхронні виклики або окремі fetch після першого байта. І нарешті — вимірювання тільки з однієї локації. Те, що виглядає добре з Києва, може бути погано з Торонто чи Сіднея.

Коли варто змінювати хостинг або архітектуру

Якщо після кешування, оптимізації запитів і CDN TTFB на uncached сторінках все одно тримається вище 400–500 мс — проблема в інфраструктурі. Shared-хостинг із десятками сайтів на одному сервері рідко дає стабільні результати. Managed WordPress, container-based або якісний VPS/dedicated із SSD/NVMe і достатньою кількістю CPU/RAM дають помітний стрибок.

Для глобальної аудиторії іноді доводиться розглядати multi-region origin або edge-функції (Cloudflare Workers, Vercel Edge, Fastly Compute). Streaming SSR і Partial Prerendering (як у сучасних Next.js) дозволяють відправляти перший байт раніше, не чекаючи повної генерації сторінки.

Якщо сайт критично залежить від бази даних і обсяг даних росте — варто дивитися в бік read-replicas, in-memory кешів (Redis) і розділення hot/cold даних.

Ключові інсайти

Скорочення TTFB — це не одна «чарівна кнопка», а послідовна робота з усіма шарами: мережа → протоколи → кешування → серверна обробка → код. Найбільший ефект зазвичай дають page/edge cache + CDN + усунення редиректів і важких запитів.

Вимірюйте в полі, розбивайте показник на складові, пріоритезуйте за впливом. У 2026 році технології (HTTP/3, Early Hints, Speculation Rules, edge compute) дають більше можливостей, ніж п’ять років тому, але базові принципи залишаються тими самими: менше роботи на критичному шляху і ближче до користувача.

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