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

TTFB визначає, коли користувач взагалі побачить хоч щось на екрані. Повільний TTFB, і відвідувач іде ще на етапі, коли ваш сайт навіть не почав відображатися. А Google з 2025 року включає серверну чуйність у сигнали ранжування Core Web Vitals.

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

💡 Швидкий огляд:

• Розберіться, що таке TTFB і чому кожна секунда цієї затримки множиться на кожну дію відвідувача.
• Пройдіть ланцюжком із чотирьох факторів: DNS, сервер, плагіни WordPress і кешування HTML.
• Порівняйте чотири сценарії на реальних вимірах Pingdom, від 150 мс до катастрофічних 4,2 секунди.
• Увімкніть кешування HTML і побачите, як один плагін знижує TTFB у рази без заміни хостингу.

Що таке TTFB і чому він впливає на все

Формальне визначення з Wikipedia: TTFB — це час від надсилання HTTP-запиту до отримання першого байта відповіді браузером клієнта. До нього входять затримка сокетного з'єднання, час пересилання запиту і час обробки на сервері.

Якщо сказати простіше: TTFB — це пауза між «перейти за посиланням» і «на сайті щось почало відбуватися». В ігрових термінах, latency, пінг, затримка до першого відгуку. Користувач не бачить ні заголовка, ні меню, ні спінера, лише порожню вкладку. І що довша ця пауза, то вищий шанс, що вкладку закриють.

Важливий нюанс: TTFB впливає не лише на перше завантаження. Кожен внутрішній перехід, кожне натискання на посилання в меню, кожен клік по зображенню всередині допису, все це окремий HTTP-запит зі своїм TTFB. Поганий показник множиться на кожну дію читача.

Чотири фактори, з яких складається TTFB

TTFB — це не одна метрика, а сума затримок на кожному етапі ланцюжка «користувач → сайт». Усі чотири ланки працюють послідовно: якщо одна гальмує, гальмує і кінцевий результат. Розберемо кожну.

DNS: перший рубіж

Браузер не знає, де фізично знаходиться ваш сервер, поки DNS не перетворить домен на IP-адресу. Хороші DNS-сервери з розподіленою мережею вузлів роблять це за мілісекунди, погані, додають десятки й сотні мілісекунд до кожного завантаження.

Практичний мінімум: використання Cloudflare або аналогічного сервісу з глобальним кешуванням DNS. Після першого запиту адреса залишається в кеші, і для повторних звернень DNS-затримка зникає повністю.

Сервер і PHP: що відбувається на хостингу

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

Два параметри хостингу визначають швидкість: версія PHP і процесорний час, виділений вашому тарифу. Дешевий shared-хостинг із десятками сайтів на одному сервері та застарілим PHP, гарантований шлях до TTFB > 1 секунди. Спеціалізований WordPress-хостинг із PHP 8.2+ і вбудованим кешуванням на рівні сервера дає принципово інші цифри.

Плагіни і тема WordPress

WordPress збирає сторінку з десятків PHP-файлів, і кожен активний плагін додає свій код у цей процес. Десять якісних плагінів від відомих розробників можуть майже не впливати на TTFB. Один погано написаний плагін, який на кожному запиті робить три зайвих запити до бази даних, здатен обвалити швидкість усього сайту.

Ось приклад розумного набору плагінів, усе необхідне, нічого зайвого:

А це вже потенційно проблемна конфігурація. Кілька десятків активних плагінів, і серверу доводиться обробляти кожен із них під час формування сторінки:

На практиці більше 30 активних плагінів майже гарантовано означають високий TTFB, навіть на хорошому хостингу. Правило просте: кожен плагін має виконувати конкретне завдання, яке не можна вирішити інакше. Все, що висить «про всяк випадок», підлягає видаленню.

Кешування HTML: головний важіль

Найпотужніший фактор з усіх. Плагін кешування, як-от плагін Cache Enabler, зберігає готові HTML-копії сторінок на диску сервера. Коли надходить запит, вебсервер віддає статичний файл, оминаючи весь стек PHP і WordPress.

Результат: серверу більше не потрібно завантажувати ядро, тему та плагіни для кожного відвідувача. Лише сам вебсервер (nginx або Apache) обслуговує контент напряму. Саме тому кешування дає найзначніше зниження TTFB, у рази, а не на відсотки. Докладніше про те, чому nginx ефективніший за Apache для цього завдання, розбирали в окремій статті.

TTFB на практиці: чотири сценарії

Перейдімо до реальних вимірювань. Нижче наведено результати тестів на різних комбінаціях сайту та сервера, отримані через Pingdom Tools. Кожен сценарій показує TTFB для некэшованої та кешованої версій.

Повільний сайт на повільному сервері

Найгірша з можливих комбінацій: сайт із десятками плагінів і без кешування на старому shared-хостингу з PHP 5.4.

Розкриємо деталі першого запиту, видно, що сервер думає цілу вічність:

TTFB становить 4,2 секунди. Чотири секунди користувач дивиться на порожній екран, перш ніж браузер отримає бодай якісь дані. Додайте до цього час рендерингу сторінки, і загальне очікування до готовності сайту легко сягає семи секунд. Cloudflare на вході тут уже не допомагає: проблема глибша, на рівні хостингу та коду сайту.

Швидкий сайт на середньому сервері

Змінюємо умови: сайт із мінімумом плагінів, сервер на Apache з рядовою версією PHP, без кешування.

Результат, 521 мс. Уже у 8 разів краще, ніж у першому сценарії. Пів секунди до першого байта, прийнятно для більшості сайтів. Тепер вмикаємо кешування:

TTFB падає до 152 мс. Навіть середній хостинг із правильно налаштованим кешуванням видає відмінний результат.

Повільний сайт на швидкому сервері

Зворотна ситуація: оптимізований сервер на Plesk з nginx і рядовою версією PHP, але сайт роздутий плагінами.

Без кешу швидкий сервер однаково витрачає 1,29 секунди на обробку важкого сайту. Хороший хостинг пом’якшує, але не вирішує проблему погано оптимізованого WordPress.

Вмикаємо кешування, TTFB знижується до 400 мс. Різниця більш ніж утричі.

Швидкий сайт на швидкому сервері

Оптимальний сценарій: легкий сайт на хорошому хостингу.

Без кешу сервер віддає перший байт менш ніж за 500 мс. Додаємо кешування:

Результат, менше 150 мс. Практично миттєвий відгук.

Зведення результатів

Усі чотири сценарії на одному графіку:

Висновок із цих замірів прямий: хостинг важливий, але те, що ви робите із самим сайтом, впливає на TTFB сильніше. Швидкий сервер із кешуванням витягує навіть проблемний сайт до прийнятних 400 мс, а повільний сервер без кешу топить навіть легкий WordPress.

Як покращити TTFB: покроковий план

Оптимізація йде від простого до складного, від того, що робиться за п’ять хвилин і дає максимальний ефект, до тонших налаштувань.

Крок 1: увімкніть кешування HTML. Встановіть безкоштовний Cache Enabler або аналогічний плагін кешування. Це одна операція, яка знижує TTFB у рази на будь-якому хостингу. Без перебільшення, найвище повернення на хвилину зусиль у всій оптимізації WordPress.

Крок 2: перевірте версію PHP. В адмінці хостингу або в cPanel знайдіть налаштування версії PHP. Якщо доступна актуальна версія (8.2 або новіша), перемкніть. Перехід із застарілої гілки на сучасну помітно пришвидшує обробку кожного запиту. Перед перемиканням переконайтеся, що тема та всі плагіни сумісні з вибраною версією.

Крок 3: проведіть аудит плагінів. Вимкніть усе, що не використовується просто зараз. Залиште лише ті плагіни, які вирішують конкретне завдання. Решту видаліть, а не просто деактивуйте. Плагіни «на виріст» і «можливо, знадобиться» додають код у кожен запит незалежно від того, користуєтеся ви ними чи ні.

Крок 4: оберіть швидку тему. Тема визначає, скільки PHP-коду виконується під час кожного завантаження. Важкі теми з візуальними конструкторами сторінок генерують значно більше серверної роботи, ніж мінімалістичні рішення. Якщо тест TTFB на чистому встановленні WordPress (без плагінів і зі стандартною темою) показує хороший результат, а після ввімкнення вашої теми показник різко погіршується, проблема саме в темі.

Крок 5: оцініть хостинг. Якщо після перших чотирьох кроків TTFB усе ще перевищує 500-800 мс, обмеження на стороні хостингу. Спеціалізований WordPress-хостинг з nginx, PHP 8.2+ і серверним кешуванням дає принципово інший рівень відгуку. Вибираючи, звертайте увагу на наявність вбудованого об’єктного кешування (Redis або Memcached) — це наступний рівень після кешування HTML.

Відео: TTFB від теорії до результату

Подивіться наочний розбір TTFB з живими вимірами до та після оптимізації:

⁉️🤔 Часті запитання

Який TTFB вважається хорошим для WordPress?

Орієнтуйтеся на цільові значення Google Core Web Vitals: до 800 мс, прийнятно, до 500 мс, добре, до 200 мс, чудово. На практиці для сайту на WordPress із кешуванням досяжний діапазон, 100-400 мс. Без кешування навіть швидкий сайт рідко опускається нижче 400-500 мс.

Чи обов’язково змінювати хостинг для покращення TTFB?

Не завжди. Кешування HTML знижує TTFB у рази навіть на середньому хостингу. Перш ніж переїжджати, увімкніть кешування, оновіть PHP до актуальної версії та почистіть плагіни. Якщо після цього TTFB усе ще вищий за 800 мс, хостинг справді час міняти.

Чому TTFB скаче від виміру до виміру?

На TTFB впливає завантаження процесора сервера в момент виміру, мережеві затримки та географія тестового сервера. Робіть серію з 5-7 вимірів і беріть медіану, а не перше-ліпше значення. Тестуйте з кількох локацій: сервер у Європі може показувати чудовий TTFB із Франкфурта, але поганий із Токіо.

Чи впливає TTFB на позиції в Google?

Так, починаючи з 2025 року серверна чуйність входить до Core Web Vitals як сигнал ранжування. Прямий вплив помірний, але непрямий, значний: високий TTFB збільшує показник відмов, а високий відсоток відмов уже безпосередньо валить позиції.

Чи можна виміряти TTFB безкоштовно?

Так. Використовуйте Pingdom Tools, GTmetrix, PageSpeed Insights або WebPageTest. Важливий нюанс: вимірюйте саме TTFB (час до першого байта), а не загальний час завантаження сторінки. У Pingdom для цього потрібно розгорнути деталі першого запиту до сайту.

Що робити з TTFB просто зараз

Головний висновок із вимірів вище: кешування HTML — це найпотужніший і найпростіший важіль. Один плагін знижує TTFB у рази на будь-якому хостингу, і це займає рівно п’ять хвилин.

Порядок дій такий:

• Якщо TTFB > 1 секунди, почніть із кешування та оновлення PHP. Ці два кроки дають основну частину можливого покращення.
• Якщо TTFB між 400 і 800 мс, аудит плагінів і теми зазвичай прибирає решту затримки.
• Якщо TTFB стабільно нижче 200 мс, ви в оптимальній зоні, підтримуйте поточний рівень.

Почніть із безкоштовного плагіна кешування: встановіть, активуйте та зробіть вимір через Pingdom Tools. Різниця буде видна одразу. А який у вас TTFB зараз, поділіться цифрами в коментарях.