Скорость сервера и 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 для закешированных страниц.