Швидкість сервера і TTFB: як виявити і виправити

TTFB понад 800 мс — прямий шлях до червоних Core Web Vitals і втрати позицій. Причини: перевантажений shared-хостинг, некешований PHP, повільні MySQL-запити або відсутність CDN. Як виміряти, знайти причину і виправити — з конкретними числами.

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

TTFB (Time to First Byte) — час від моменту, коли браузер надіслав HTTP-запит, до отримання першого байту відповіді від сервера. Це найперша метрика в ланцюжку завантаження: поки сервер не відповів, браузер нічого не робить.

Ми зіштовхуємось з цією проблемою в кожному другому технічному аудиті — особливо у проєктів на shared-хостингу, де TTFB стабільно перевищує 1500 мс навіть у неакивний час. Власники сайтів часто не усвідомлюють масштабу: вони бачать звичну швидкість у себе в браузері з кешем, але реальний користувач без кешу чекає 2–3 секунди лише на відповідь сервера.

Чому Google це хвилює? Логіка проста: TTFB — перший компонент у формуванні LCP (Largest Contentful Paint). Якщо сервер відповідає за 1800 мс, LCP фізично не може бути меншим. Google відкрито зазначив у документації web.dev, що TTFB є первинним фактором для всіх метрик швидкості завантаження.

TTFB охоплює три фази:

• DNS-запит — перетворення домену в IP-адресу. Зазвичай 10–80 мс.
• TCP + TLS handshake — встановлення з'єднання та шифрування. 50–150 мс.
• Час очікування сервера (TTFB server time) — скільки сервер генерує відповідь. Від 50 мс до 3000+ мс залежно від хостингу і коду.

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

Нормативи TTFB: що вважається хорошим у 2026

Google визначає три зони TTFB на основі даних Chrome User Experience Report (CrUX). Ці пороги застосовуються до 75-го перцентилю реальних користувачів, не лабораторних тестів.

Варто розрізняти лабораторний і польовий TTFB. Лабораторний (PageSpeed Insights, WebPageTest) вимірює TTFB одного запиту в контрольованих умовах. Польовий — усереднені дані реальних відвідувачів з CrUX за останні 28 днів. Для ранжування Google використовує саме польові дані.

На практиці ми бачимо такі типові значення залежно від типу хостингу:

• Shared-хостинг із 50–100+ сайтами на сервері: 800–3000 мс
• VPS (2–4 vCPU, 4–8 GB RAM) з базовою конфігурацією: 200–600 мс
• VPS + Redis + оптимізований PHP: 80–250 мс
• VPS + CDN + повне кешування: 50–150 мс для закешованих сторінок

Як виміряти TTFB: PageSpeed Insights, WebPageTest, GSC

Три інструменти дають різні зрізи даних — лабораторні, порівняльні і польові. Для повної картини потрібні всі три.

1. PageSpeed Insights (найпростіший старт)

Перейдіть на pagespeed.web.dev, введіть URL. У звіті знайдіть розділ «Diagnostics» → «Server response times (TTFB)». Інструмент показує лабораторний TTFB і порівнює з полем CrUX. Якщо лабораторний TTFB у нормі, але польовий поганий — проблема в пікових навантаженнях або географічних затримках.

2. WebPageTest — детальний waterfall

1. Відкрийте webpagetest.org, вкажіть URL.
2. Оберіть локацію тесту, близьку до вашої аудиторії: Frankfurt або Amsterdam для України.
3. У результатах waterfall зелений блок «Waiting (TTFB)» — це чистий серверний час без DNS і TCP.
4. Запустіть 3 тести і орієнтуйтесь на медіану — перший може бути спотворений cold DNS.

WebPageTest також показує First Byte окремо від DNS і TCP, що дозволяє точно ізолювати серверну проблему.

3. Google Search Console — польові дані реальних користувачів

1. GSC → Core Web Vitals → Poor URLs.
2. Відсортуйте за метрикою LCP — сторінки з червоним LCP часто мають і поганий TTFB.
3. Натисніть на URL → «Open in PageSpeed Insights» — побачите польові дані TTFB для конкретної сторінки.

4. Chrome DevTools — для швидкого ручного тесту

Відкрийте DevTools (F12) → Network → завантажте сторінку → клік на перший запит (HTML-документ) → вкладка «Timing» → рядок «Waiting (TTFB)». Це точний серверний час для вашої поточної мережі та локації.

З практики: порівнюйте TTFB з різних локацій — із Франкфурта і з Харкова. Якщо з Харкова 300 мс, а з Франкфурта 1800 мс — проблема в CDN або геолокації сервера. Якщо однаково погано з обох — хостинг або код.

Повний чеклист вимірювання швидкості є частиною нашого покрокового гайду з технічного SEO-аудиту. TTFB нерозривно пов'язаний з LCP та іншими Core Web Vitals — виправлення одного прискорює й інші.

Основні причини повільного TTFB: хостинг, PHP, база даних, CDN

Найпоширеніший виновник — Shared Hosting з 80+ сайтами на одному сервері. Але навіть на хорошому VPS TTFB може бути поганим через некешований PHP або важкі SQL-запити. Ось повна карта причин:

Shared Hosting. На shared-сервері ваш сайт ділить CPU і RAM з десятками або сотнями інших. У піковий час (10:00–18:00) сервер перевантажений — TTFB злітає до 3–5 секунд. Рішення тут лише одне: переїзд на VPS або хмарний сервер.

PHP без кешування. Кожен HTTP-запит до PHP-сайту без OPcache змушує PHP перекомпілювати файли з нуля. OPcache зберігає скомпільований байт-код в пам'яті. Без нього: 800–1500 мс. З ним: 150–400 мс. Перевірте: php -i | grep opcache.enable.

MySQL без оптимізації. Повільні запити — другий за частотою вбивця TTFB. Симптом: через SHOW PROCESSLIST бачите запити, що виконуються 0.5–5 секунд. Типові причини: відсутність індексів на колонках фільтрації, N+1 запити в ORM, занадто великі JOIN без лімітів.

Відсутність CDN для статичних ресурсів. CDN не знижує серверний TTFB напряму, але через edge-кешування та проксіювання запитів може скоротити загальний TTFB на 100–300 мс завдяки географічній близькості точки входу до користувача.

Важкі плагіни і pagebuilder-фреймворки. Сайти на WordPress з 20+ активними плагінами або на Elementor/Divi завантажують десятки PHP-класів на кожний запит. Навіть якщо кожен плагін додає лише 20–50 мс — разом вони дають 400–800 мс зайвого серверного часу. Перевірте через Query Monitor (WordPress-плагін): він показує кількість SQL-запитів і час виконання PHP для кожного запиту. Більше 80 запитів на сторінку — привід для оптимізації.

Відсутність HTTP/2. HTTP/1.1 дозволяє лише 6 паралельних з'єднань на домен, HTTP/2 — необмежено через multiplexing. Для TTFB прямий ефект невеликий, але HTTP/2 Server Push дозволяє відправляти критичні ресурси до їх запиту браузером — що скорочує сприйнятий час завантаження на 80–150 мс. Перевірте підтримку: curl -sI --http2 https://yoursite.ua | head -1.

Неоптимізована конфігурація Nginx/Apache. За замовчуванням Apache обробляє кожен запит у новому потоці — при 50+ одночасних запитах це виснажує CPU. Nginx event-driven з PHP-FPM споживає значно менше ресурсів при тому самому навантаженні. Додатково: увімкніть keepalive_timeout 65; у Nginx і fastcgi_cache для кешування PHP-відповідей на рівні веб-сервера.

Зовнішні блокуючі ресурси в head. Іноді TTFB виглядає нормальним, але перший рендер затримується через синхронно завантажені зовнішні скрипти — Google Tag Manager, чат-боти, A/B-тестери. Технічно це не TTFB, але в звіті PageSpeed це відображається як Time to Interactive (TTI). Завжди перевіряйте: чи є у вас <script src="third-party.js"> без async або defer в <head>.

Як зменшити TTFB: 6 перевірених методів

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

1. Перехід з Shared Hosting на VPS

Найефективніший крок. Навіть базовий VPS (Hetzner CX21: 2 vCPU, 4 GB RAM, ~€5–7/міс) знижує TTFB з 1500–3000 мс до 200–600 мс. Після переїзду налаштуйте: Nginx як веб-сервер, PHP-FPM із пулом воркерів, MariaDB замість MySQL для кращої продуктивності.

2. Увімкнення OPcache і PHP 8.x

PHP 8.2 швидший за PHP 7.4 приблизно на 30–50% на типових CMS-задачах. Перехід PHP 7.4 → 8.2 + OPcache: -200–500 мс TTFB без жодних змін коду. Налаштування OPcache в php.ini:

• opcache.enable=1
• opcache.memory_consumption=256
• opcache.max_accelerated_files=20000
• opcache.validate_timestamps=0 (на production)

3. Redis або Memcached для об'єктного кешування

Redis кешує результати MySQL-запитів і об'єкти PHP в оперативній пам'яті. Для OpenCart підключається через модуль кешування; для WordPress — плагін W3 Total Cache або Redis Object Cache. Ефект: TTFB з 1200 мс → 180–300 мс на сторінках, що активно звертаються до БД.

4. Оптимізація MySQL-запитів

• Увімкніть slow query log: slow_query_log=1, long_query_time=0.5.
• Аналізуйте повільні запити через EXPLAIN SELECT ....
• Додайте індекси на колонки, що використовуються у WHERE, JOIN, ORDER BY.
• Розгляньте query cache або перехід на MariaDB з покращеним оптимізатором запитів.

5. CDN із кешуванням HTML

Cloudflare (безкоштовний план) або BunnyCDN кешують статичні ресурси. Для зниження TTFB ключове — кешування самого HTML-документа на edge-нодах CDN. Налаштуйте Cache-Control: public, max-age=3600, s-maxage=86400 для статичних сторінок. Для динамічного контенту — Cloudflare Page Rules для обходу кешу при наявності cookie авторизації.

6. HTTP/2 або HTTP/3

HTTP/2 multiplexing скорочує кількість TCP-з'єднань і паралелізує завантаження ресурсів. Перевірте підтримку: curl -I --http2 https://yoursite.ua — у відповіді має бути HTTP/2 200. Якщо Nginx повертає HTTP/1.1 — додайте listen 443 ssl http2; у конфіг.

Налаштування PHP-FPM для стабільного TTFB під навантаженням

Навіть на VPS PHP-FPM із замовчуваними параметрами може «захлинатися» при 30+ одночасних запитах. Ключові параметри пулу (/etc/php/8.1/fpm/pool.d/www.conf):

• pm = dynamic — динамічний пул, адаптується до навантаження.
• pm.max_children = 30 — максимум паралельних воркерів. Розраховуйте: (доступна RAM − 512 MB системи) ÷ середній розмір PHP-процесу (~50 MB). Для 4 GB RAM: (4096 − 512) ÷ 50 = 71. Починайте з 30, збільшуйте поступово.
• pm.start_servers = 5, pm.min_spare_servers = 3, pm.max_spare_servers = 10 — мінімальний запас «теплих» воркерів.
• pm.max_requests = 500 — перезапускати воркер після 500 запитів, щоб уникнути витоку пам'яті у старих модулях.

Після налаштування перевірте статус пулу: systemctl status php8.1-fpm і php-fpm8.1 -t для валідації конфігурації.

Моніторинг TTFB після оптимізації

Одноразове виправлення — це не кінець роботи. TTFB може погіршитися після оновлення CMS, додавання нового плагіна або зростання трафіку. Налаштуйте постійний моніторинг:

• UptimeRobot або Better Uptime — безкоштовний моніторинг доступності з перевіркою кожні 5 хвилин. Налаштуйте alert при response time > 1000 мс.
• Grafana + Prometheus + node_exporter — для VPS: дашборд із CPU, RAM, disk I/O і nginx request time. Дозволяє бачити кореляцію між піками навантаження і TTFB.
• Google Search Console Core Web Vitals — перевіряйте щотижня. Якщо «Poor» URL-адреси знову ростуть після стабілізації — щось змінилося на сервері або в коді.
• WebPageTest scheduled tests — безкоштовна функція: запускати тест щодня з однієї локації та порівнювати TTFB у динаміці.

З нашого досвіду: клієнти, які налаштували моніторинг одразу після оптимізації, виявляли деградацію TTFB у середньому через 6–8 тижнів — зазвичай після чергового оновлення WordPress або OpenCart, яке скидало налаштування OPcache. Без моніторингу така деградація могла б тривати місяцями непоміченою.

Кейс: як ми знизили TTFB з 1800 мс до 280 мс

Клієнт — інтернет-магазин одягу (Україна), близько 3000 сторінок товарів і категорій на OpenCart 3.x. До нас звернулися після того, як GSC показала різке погіршення Core Web Vitals: 78% сторінок потрапили в «Poor» за LCP.

Початковий стан (вересень 2025 року):

• Хостинг: shared, ~90 сайтів на сервері, Харків
• TTFB (WebPageTest, Frankfurt): 1780–1920 мс (медіана 1830 мс)
• LCP: 5.2 секунди (польові дані CrUX)
• PageSpeed Score (mobile): 31 / 100
• PHP: 7.4, OPcache вимкнений
• MySQL slow queries: 47 запитів на хвилину, середній час 0.8 сек

Що ми зробили — покроково:

Крок 1 (тиждень 1): Переїзд на VPS. Після переїзду клієнта на VPS Hetzner CX21 (2 vCPU, 4 GB RAM, €5.83/міс, локація Frankfurt) TTFB одразу впав до 520 мс. Тільки за рахунок зміни хостингу — без жодних змін коду. PageSpeed mobile: 47.

Крок 2 (тиждень 1–2): PHP 8.1 + OPcache. Оновили PHP 7.4 → 8.1, налаштували OPcache з memory_consumption=256. TTFB: 380 мс. PageSpeed mobile: 58.

Крок 3 (тиждень 2–3): Redis для OpenCart. Встановили Redis 7.x, підключили через модуль phpfastcache/phpfastcache. Кешуємо: результати категорій, список товарів, пошукові запити. TTFB: 310 мс. MySQL slow queries: знизилися з 47 до 8 на хвилину.

Крок 4 (тиждень 3–4): Оптимізація MySQL. Увімкнули slow query log, знайшли 5 критичних запитів. Найгірший — SELECT на таблиці oc_product_description без індексу по language_id. Додали складений індекс: ALTER TABLE oc_product_description ADD INDEX idx_lang_prod (language_id, product_id);. Час запиту: з 1.2 сек до 0.008 сек. TTFB: 280 мс.

Крок 5 (тиждень 4): CDN Cloudflare. Підключили Cloudflare Free, налаштували кешування статики (CSS, JS, зображення). Page Rules для кешування HTML-сторінок категорій і товарів на 1 годину. Остаточний TTFB для закешованих запитів: 110–180 мс.

Результати через 3 місяці (грудень 2025 — лютий 2026):

Зростання трафіку на 34% за 3 місяці — без жодних змін контенту, нових сторінок або посилань. Тільки технічна оптимізація сервера. Це не завжди так драматично, але для сайтів із вихідним TTFB понад 1500 мс подібний ефект — норма, а не виняток.

Що дало найбільший ефект: переїзд на VPS — одразу −1300 мс TTFB. Решта оптимізацій дала ще −240 мс, але більш стабільний результат під навантаженням. Без VPS жодна інша оптимізація не має сенсу — shared-хостинг є стелею для продуктивності.

Побічні ефекти оптимізації, яких не очікували: поліпшення TTFB позначилось не лише на LCP. Показник Interaction to Next Paint (INP) також покращився — з 380 мс до 140 мс, оскільки сервер тепер швидше відповідає на AJAX-запити (додавання в кошик, зміна фільтрів). Це призвело до зниження bounce rate на сторінках категорій з 62% до 47% за даними GA4. Клієнт зазначив, що кількість завершених замовлень на мобільних пристроях зросла на 18% за той самий тримісячний період — хоча це й не можна приписати виключно TTFB, загальне покращення технічної якості сайту явно відіграло роль.

Ще один несподіваний результат: Googlebot почав краулити сайт значно активніше. За даними GSC (Crawl Stats), середня кількість сторінок, що краулиться на день, зросла з 180 до 430 — сервер тепер відповідає достатньо швидко, щоб Googlebot не обмежував частоту візитів через повільність відповідей. Для інтернет-магазину з активним оновленням асортименту це означає швидше потрапляння нових товарів в індекс.

Підводні камені, з якими зіштовхнулись:

• PHP 8.1 зламав два застарілих модулі OpenCart — довелося оновити або замінити. Завжди тестуйте на staging перед деплоєм.
• Redis потребував налаштування eviction policy: maxmemory-policy allkeys-lru, щоб не витрачати всю RAM при великому каталозі.
• Cloudflare кешував сторінки з формами замовлення — вирішили через Page Rule «Bypass Cache» для URL з /cart і /checkout.
• Після переїзду на VPS виявилось, що SSL-сертифікат (Let's Encrypt) не оновився автоматично — налаштували cron-задачу certbot renew з перевіркою двічі на день.
• MariaDB за замовчуванням має innodb_buffer_pool_size=128M — для сервера з 4 GB RAM збільшили до 1.5 GB, що дало додаткове прискорення запитів на 15–20%.

Загалом перехід від shared-хостингу до правильно налаштованого VPS зі стеком Nginx + PHP-FPM + MariaDB + Redis — це не разова акція, а зміна підходу до інфраструктури. Він вимагає початкових зусиль, але повертається стабільним TTFB, вищими позиціями і меншою кількістю несподіваних проблем зі швидкістю в майбутньому.

Практичний чеклист: що зробити прямо зараз

Зберіть цей список як точку старту для будь-якого сайту з TTFB понад 800 мс. Кожен пункт займає не більше 15 хвилин на перевірку.

Після проходження чеклісту у вас буде чіткий пріоритезований план: що виправляти першим і якого результату очікувати. З нашого досвіду, пункти 1–3 виконуються за одну робочу сесію і дають найбільш повну картину ситуації ще до початку будь-яких змін.

Одна з найчастіших помилок — почати з «простих» виправлень (CDN, HTTP/2), залишивши основну проблему (shared-хостинг) недоторканою. CDN знижує TTFB на 100–200 мс, але не може компенсувати 1500 мс серверного часу на перевантаженому shared-сервері.

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

Часті запитання

Який TTFB вважається нормальним у 2026?

Google визначає хорошим TTFB до 800 мс (75-й перцентиль). Реально конкурентоспроможний рівень — до 400 мс. Значення 800–1800 мс потребують покращення, понад 1800 мс — критично погані Core Web Vitals і помітні втрати позицій.

Чи впливає TTFB безпосередньо на позиції в Google?

Прямого сигналу ранжування не існує, але TTFB входить у ланцюжок до LCP — одного з трьох сигналів Core Web Vitals. Поганий TTFB автоматично погіршує LCP, INP і загальний Page Experience Score, що вже є підтвердженим фактором ранжування.

Що перевірити першим при повільному TTFB?

Перший крок — виміряти TTFB з різних локацій через WebPageTest або PageSpeed Insights. Якщо TTFB стабільно поганий звідусіль — проблема серверна (хостинг, PHP, MySQL). Якщо тільки з певних регіонів — відсутній або неправильно налаштований CDN.

Чи допомагає кешування зменшити TTFB?

Так, і значно. Redis або Memcached для об'єктного кешування може знизити TTFB з 1500–2000 мс до 150–300 мс на PHP-сайтах. Full-page cache (наприклад, Varnish або модуль кешування в OpenCart) дає ще кращий результат, оскільки взагалі виключає генерацію PHP для закешованих сторінок.