Час відгуку сервера: невидимий убивця конверсії, якого ви годуєте щомісячним платежем

Уявіть: ви заходите до кав'ярні, робите замовлення, а бариста просто стоїть і дивиться на вас. Секунду. Дві. П'ять. Ви ще не пішли? Браво, у вас терпіння святого. А тепер перенесіть цю сцену у браузер. Користувач натискає на посилання, а ваш сервер мовчить - думає, пригадує, шукає. Це і є час відгуку сервера, або TTFB (Time To First Byte). І поки він "думає", ваші гроші йдуть конкурентам. Google вимірював це ще у 2012 році: затримка у 400 мс зменшувала кількість пошуків на 0,59%. Здавалося б - дрібниця. Але помножте на мільйони запитів, і дрібниця перетворюється на катастрофу.

Що таке TTFB і чому він важливіший за красивий дизайн

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

Якщо TTFB повільний - все інше не має значення. Ви можете мати ідеально стиснуті картинки, мініфікований CSS та lazy loading на кожному елементі - але сервер, який відповідає за 2 секунди, знищить усі ваші зусилля з оптимізації фронтенду.

Google чітко визначає пороги у своїх Core Web Vitals:

Зверніть увагу: 600 мс - це менше секунди. Але для браузера це вічність. Amazon ще у 2006 році підрахував, що кожні 100 мс затримки коштують їм 1% продажів. З того часу користувачі стали ще нетерплячішими.

Де ховаються мілісекунди: анатомія повільного відгуку

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

1. Повільна база даних. Запит до MySQL без індексу на таблиці з 500 000 рядків - це як шукати одну книгу у бібліотеці, де всі полиці перемішані. Замість 5 мс ви отримуєте 800 мс на один запит. А на сторінці їх може бути 20-30.
2. Відсутність серверного кешу. PHP генерує HTML з нуля при кожному зверненні? Це як готувати піцу з тіста щоразу, коли хтось замовляє один і той самий "Маргарита". Безглуздо.
3. Географічна відстань. Сервер у Франкфурті, а більшість аудиторії - у Києві. Фізика нікуди не дівається: світло у оптоволокні проходить приблизно 200 км за мілісекунду. Додайте маршрутизацію - і ось вам зайвих 50-80 мс.
4. Перевантажений shared-хостинг. Коли 200 сайтів ділять один процесор, ваш TTFB стає лотереєю. О третій ночі - 150 мс. О десятій ранку, коли сусід запустив імпорт каталогу - 1200 мс.
5. Неоптимізований бекенд. Плагіни WordPress, що роблять зовнішні HTTP-запити при кожному завантаженні сторінки. Або фреймворк, що ініціалізує 300 класів до того, як віддати простий JSON.

"Ви не можете оптимізувати те, чого не вимірюєте. А більшість власників сайтів навіть не знають, що таке TTFB, поки не побачать червону позначку у PageSpeed Insights." - Іллія Грігорик, автор книги "High Performance Browser Networking" та інженер Google.

Вимірюйте, перш ніж лікувати

Ось вам правило номер один: ніколи не оптимізуйте наосліп. Я бачив десятки випадків, коли люди витрачали тижні на стиснення зображень, а проблема була у повільному DNS-резолвінгу, що додавав 300 мс ще до першого з'єднання.

Інструменти, які дадуть вам реальну картину:

• WebPageTest.org - безкоштовний, дозволяє вибрати локацію тесту та побачити waterfall-діаграму кожного запиту
• curl з прапорцем -w - одна команда у терміналі: curl -o /dev/null -w "TTFB: %{time_starttransfer}n" https://your-site.com
• Chrome DevTools - вкладка Network, колонка "Waiting (TTFB)" для кожного запиту
• GTmetrix - зручна візуалізація та історія вимірювань, щоб відстежувати тренд

Важливий нюанс: вимірюйте з різних точок. TTFB у 100 мс із вашого офісу нічого не означає, якщо з Варшави він 900 мс. Реальний користувач - не ваш localhost.

Практичний рецепт: як скинути TTFB з 1.5 секунди до 200 мс

Нещодавно я допомагав одному інтернет-магазину на WooCommerce. Їхній TTFB стабільно показував 1400-1800 мс. Сайт працював на VPS з 2 ГБ RAM у Нідерландах. Аудиторія - переважно Україна та Польща. Ось що ми зробили крок за кроком.

Крок 1: Діагностика бази даних. Увімкнули slow query log у MySQL з порогом 0.5 секунди. Виявили 14 запитів без індексів, що виконувалися при кожному завантаженні сторінки каталогу. Після додавання потрібних індексів середній час запиту впав з 600 мс до 40 мс.

Крок 2: Серверний кеш. Встановили Redis як object cache для WordPress. WooCommerce активно використовує transients - тимчасові дані у базі. Redis зберігає їх у оперативній пам'яті. Результат: ще мінус 300 мс.

Крок 3: PHP-тюнінг. Перевірили - OPcache був увімкнений, але з дефолтними налаштуваннями. Збільшили opcache.memory_consumption з 128 до 256 МБ, opcache.max_accelerated_files до 20 000. Мінус ще 80 мс.

Крок 4: Сторінковий кеш. Налаштували Nginx FastCGI Cache для сторінок каталогу. Для незалогінених користувачів (а це 92% трафіку) HTML віддається напряму з Nginx, без звернення до PHP взагалі. TTFB для цих сторінок впав до 30-50 мс.

Крок 5: CDN. Підключили Cloudflare з точкою присутності у Варшаві. Для статики це очевидний вибір, але ми також увімкнули Argo Smart Routing - і динамічні запити стали швидшими на 50-70 мс завдяки оптимізованій маршрутизації.

Підсумковий TTFB: 140-200 мс для 92% відвідувачів, 350-400 мс для залогінених. Конверсія зросла на 12% за перший місяць. Без жодних змін у дизайні чи контенті.

Хостинг-план і TTFB: що ви реально купуєте за свої гроші

Коли хостинг-провайдер обіцяє вам "надшвидкі NVMe-диски" та "потужні процесори" - це маркетинг. Реальне питання: який TTFB ви отримаєте під навантаженням? І ось тут починається цікаве.

Я протестував однаковий WordPress-сайт (тема Flavflavor flavor - ладно, стандартна тема Twenty Twenty-Four з 10 тестовими записами) на різних типах хостингу з однієї точки у Берліні:

Бачите закономірність? Тюнінгований дешевий VPS бив преміум shared-хостинг навіть без кешу. А з кешем - взагалі наближався до managed-рішень за п'ятикратну ціну. Але є нюанс: хтось має витратити 3-5 годин на цей тюнінг. Якщо ви не хочете - managed-хостинг окупається миттєво.

Те, про що рідко говорять: TTFB і SEO у 2025 році

Google офіційно включив TTFB як діагностичну метрику Core Web Vitals. Це не прямий фактор ранжування - прямим фактором залишається LCP (Largest Contentful Paint). Але ось фокус: LCP фізично не може бути швидким, якщо TTFB повільний. Це як намагатися пробігти стометрівку, стоячи по коліна у болоті на старті.

У березні 2025 року команда Chrome опублікувала дослідження: 78% сайтів з поганим LCP мали TTFB понад 600 мс. Кореляція не означає причинність, але тут зв'язок прямий як стовп: сервер повільно віддає HTML - браузер пізно починає рендеринг - користувач пізно бачить контент.

Ще один аспект, який ігнорують: crawl budget. Googlebot має обмежений час на сканування вашого сайту. Якщо кожна сторінка відповідає за секунду замість 200 мс - бот встигне просканувати вп'ятеро менше сторінок за один візит. Для сайту з 50 сторінками це байдуже. Для інтернет-магазину з 10 000 товарів - це катастрофа індексації.

Що робити прямо зараз? Три речі, які займуть менше години:

• Виміряйте свій TTFB через WebPageTest з трьох різних локацій і запишіть результати
• Перевірте slow query log вашої бази - навіть 10 хвилин аналізу можуть виявити головного "злодія" мілісекунд
• Увімкніть серверний кеш (навіть базовий плагін типу WP Super Cache краще, ніж нічого)

Ваш сайт прямо зараз відповідає комусь. Можливо - потенційному клієнту. Можливо - Googlebot. Скільки мілісекунд він змушує їх чекати? І чи знаєте ви це число - або просто надієтесь, що все нормально?