TTFB больше 600 мс на shared-хостинге: что делать

Время до первого байта складывается из сети и работы сервера. У российского посетителя до российского сервера сеть занимает десятки миллисекунд, значит всё остальное это генерация страницы. При значении в секунду с лишним зелёный LCP уже недостижим, сколько ни оптимизируй картинки.

TTFB это первая цифра, которую видишь в любом серьёзном инструменте измерения скорости. Time to First Byte: сколько времени прошло с момента отправки запроса до получения первого байта ответа от сервера. Если она 1.2 секунды, у вас уже не получится зелёный LCP, потому что фронтенд начинает работать только после того, как байт пришёл.

На shared-хостинге TTFB больше 600 миллисекунд это типичная история. Её часто принимают за судьбу и переезжают на VPS, заплатив за это лишний раз. Из десяти случаев девять решаются без переезда, и я разберу, почему.

Из чего складывается TTFB

TTFB это не одно число, это сумма пяти этапов. Чтобы починить большой TTFB, надо понимать, какой из этапов виноват.

DNS lookup. Браузер спрашивает у DNS-сервера, на какой IP идти. Обычно 5-30 миллисекунд, иногда 100-200 для редких зон.

TCP handshake. Установка соединения. Зависит от RTT между пользователем и сервером. У российского пользователя до российского сервера 10-40 мс. До европейского 50-90 мс.

TLS handshake. Согласование шифрования по HTTPS. Ещё 1-2 RTT, итого 30-180 мс. На HTTP/2 и HTTP/3 ускоряется через 0-RTT, но не везде включено.

Время сервера на формирование ответа. Это самая интересная часть для нас. От момента, когда сервер получил запрос, до момента, когда он вернул первый байт. Тут лежит работа PHP, MySQL, кеши, шаблоны.

Передача первого байта. Микросекунды, обычно не учитываются.

Если у вас TTFB 1.2 секунды и сайт хостится в России, скорее всего 900+ миллисекунд из них это серверная часть. Над ней и работаем.

Замер можно сделать через curl, и это даёт честный разбор:

curl -w "@-" -o /dev/null -s https://saitfix.ru/ <<'EOF'
DNS:        %{time_namelookup}n
TCP:        %{time_connect}n
TLS:        %{time_appconnect}n
Server:     %{time_starttransfer}n
Total:      %{time_total}n
EOF

Команда покажет каждый этап в секундах. Если time_starttransfer минус time_appconnect больше 0.5 секунды, серверная часть это ваша главная боль.

Почему serverless и VPS не решают, если проблема в коде

Вижу регулярно: сайт тормозит, человек переезжает с shared на VPS, платит втрое больше, TTFB остаётся таким же. Потому что виновник был не хостинг, а PHP-код, который генерирует страницу 0.9 секунды на любом железе.

Поэтому первый шаг это не переезд, а диагностика, что именно медленное. Дальше уже видно, лечится ли это на текущем хостинге.

Главные источники медленной серверной части

В порядке частоты в моих аудитах.

1. WordPress без серверного кеширования

Каждый запрос к WordPress без кеша это:

• Загрузка ядра WP (~2-5 МБ PHP-файлов).
• Загрузка всех активных плагинов (могут быть мегабайты).
• 40-80 запросов в базу.
• Обработка хуков и фильтров.
• Рендер темы.

Итого 300-1000 миллисекунд CPU на каждый запрос. На shared-хостинге, где CPU делится между несколькими сайтами, эта цифра ещё растягивается.

Лечение: серверный кеш. Самый простой и работающий вариант на shared:

WP Super Cache. Бесплатный плагин от Automattic. Включить, выбрать Expert mode, добавить правила в .htaccess. После этого первые запросы за минуту страница генерируется как обычно, но результат сохраняется в HTML-файл. Дальше Apache отдаёт его напрямую через mod_rewrite, минуя PHP вообще. TTFB падает до 50-150 миллисекунд.

Cache Enabler от KeyCDN. Похожий по сути, но мобильную и десктопную версии разделяет автоматически.

WP Rocket. Платный, но за дело: умеет кешировать, минифицировать, отложенно грузить, очищать в правильные моменты. На моих проектах он часто оправдывает 40 евро в год.

Важно: если у вас в админке кнопка Очистить кеш нажимается через интерфейс плагина, кеш реально очищается, и при следующем запросе страница перегенерируется. Если вы видите старую страницу несмотря на правки, проверяйте порядок плагинов кеширования и .htaccess правила.

2. Битрикс без композитного режима

Битрикс это сложный движок, и без композитной обработки он может генерировать страницу 800-1500 миллисекунд.

Композитный режим в Битриксе разделяет страницу на статичную часть (хедер, меню, футер, текст) и динамическую (корзина, имя пользователя, актуальные цены). Первая отдаётся из кеша моментально, вторая дорисовывается JS после.

Включается в Настройки > Композитный сайт. На большинстве сайтов даёт TTFB 100-200 миллисекунд после первой генерации. Минус: настройка требует понимания, что в каких блоках помечать как динамическое, иначе пользователи увидят кешированные данные после своего входа.

3. База без индексов

Запрос к базе SELECT * FROM wp_postmeta WHERE meta_key = '_some_key' без индекса по meta_key на таблице из 500 тысяч строк выполняется секунду. Если такой запрос идёт на каждой странице, TTFB прибавляет эти секунды.

Поиск медленных запросов в WordPress через плагин Query Monitor (бесплатный): он показывает каждый SQL-запрос на странице, время и стек вызова. Запросы дольше 50 миллисекунд это уже подозрительно, дольше 200 точно проблема.

В Битриксе есть встроенный профилировщик в Настройки > Производительность. Показывает медленные запросы, помогает найти проблемы в самописных компонентах.

Лечение: индексы. Если запрос идёт по полю, создаём индекс через ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key(20), meta_value(50)). Плагины обычно не делают индексов на свои поля, поэтому проблема массовая.

4. Внешние HTTP-запросы из PHP

Заходит человек на главную, и в PHP-обработчике скрипт делает запрос на внешний сервис: проверка курса валют, обновление статистики, отправка пинга в аналитику, проверка новых заказов CRM. Этот внешний запрос идёт синхронно. Если он занял 800 миллисекунд (а так часто и бывает с медленными сторонними API), TTFB на эти 800 мс растягивается.

Где искать: в коде темы и плагинов смотрите вызовы wp_remote_get, file_get_contents с URL, curl_exec. Все они потенциально блокируют генерацию страницы.

Лечение: либо вынести вызов в фоновый процесс через WP-Cron, либо кешировать результат на час-сутки, либо переделать на асинхронный вызов из браузера после загрузки страницы.

5. Соседи по shared-хостингу

Этот пункт сложно проверить, но он реальный. На shared-хостинге сотни сайтов делят одно ядро или один пул процессов. Если ваш сосед запустил тяжёлый плагин или попал под DDoS, ваш TTFB вырастает, хотя у вас на сайте ничего не изменилось.

Признаки: TTFB у вас плавает в широких пределах в течение суток. С утра 200 мс, после обеда 1.5 секунды, вечером 600. Без видимой связи с трафиком.

Что делать: написать в поддержку хостинга с конкретными замерами по часам. Хороший хостер посмотрит загрузку ноды и при необходимости перенесёт вас на менее загруженный сервер. Плохой ответит шаблоном всё в порядке. После второго такого ответа пора менять хостинг.

Как ускорить TTFB на shared без перехода на VPS

Перечислю по порядку приоритетов, от простого к сложному.

1. Включите OPcache, если он отключён

OPcache это встроенная в PHP штука, которая кеширует скомпилированный байт-код. Без него каждый запрос к PHP-файлу заставляет интерпретатор парсить и компилировать заново. С OPcache разница 30-50 процентов на TTFB.

Проверка: создайте файл phpinfo.php с <?php phpinfo();, откройте в браузере, найдите секцию Zend OPcache. Если там Disabled, включайте через панель хостинга (обычно есть переключатель в настройках PHP). На большинстве российских хостингов он включён по умолчанию, но я регулярно встречаю старые тарифы, где забыли.

После включения посмотрите на opcache.memory_consumption: если стоит 64 МБ и у вас большой WordPress, можно попросить поднять до 128 или 256.

2. Перейдите на актуальную версию PHP

PHP 8.2 на тех же запросах работает на 15-30 процентов быстрее, чем PHP 7.4. PHP 8.3 ещё чуть быстрее. Если у вас сайт на 7.4, протестируйте совместимость и переключайтесь.

Тест простой: на staging-копии включаете 8.2, прогоняете все страницы, смотрите на ошибки. Если их нет, можно переключать прод. Большинство современных WordPress-плагинов и тем уже совместимы. Старые могут падать, и тогда план: обновить плагин, заменить плагин, или, в редких случаях, остаться на 7.4 и думать о замене темы.

3. Ставьте серверный кеш

Подробнее уже разобрал выше. Это самая большая разовая победа: TTFB падает с 800 до 100 миллисекунд за полчаса работы.

4. Чистите запросы к базе

Через Query Monitor находите запросы дольше 50 миллисекунд, разбираетесь, откуда они приходят. Часто источник один-два плагина, которые делают WP_Query без оптимизации. Замена плагина или ручная правка SQL решает.

В Битриксе чистите неиспользуемые компоненты на главной. Каждый информер, лента, виджет это запросы к базе, которые накапливаются.

5. Уменьшите размер страницы и количество плагинов

Активные плагины в WordPress тянут за собой код, даже если он не используется на этой странице. Сайт с 40 плагинами стартует ощутимо медленнее, чем с 15.

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

6. Включите HTTP/2 или HTTP/3 на хостинге

На большинстве российских хостингов это есть, проверяется через curl -sI -k --http2 https://saitfix.ru/ или онлайн-сервисом tools.keycdn.com/http2-test. Если HTTP/2 не активен, попросите включить в поддержке. Это сокращает TLS-фазу на 30-100 миллисекунд за счёт параллельных стримов.

7. Включите Brotli или хотя бы Gzip

Сжатие ответа уменьшает время передачи и в некоторых случаях время time_starttransfer, потому что сервер быстрее отдаёт компактный буфер. Bratli лучше Gzip примерно на 20 процентов на текстовом контенте.

Проверка: curl -sI -H "Accept-Encoding: br, gzip" https://saitfix.ru/ смотрите заголовок Content-Encoding. Если там br, всё хорошо. Если gzip, можно попросить хостера включить Brotli. Если нет ничего, у вас выключено сжатие, и это критичная проблема.

8. Если ничего не помогло, профилируйте код

Подключите Tideways, NewRelic, или хотя бы Xdebug profiler на staging. Снимите профиль одного запроса, посмотрите, какая функция жуёт CPU. Иногда проблема в самописном куске кода в functions.php или в кастомном плагине, и точечная правка снимает 70 процентов TTFB.

Когда переход на VPS реально оправдан

После всех описанных шагов остаются сценарии, где shared не вытянет:

• Сайт с миллионом посетителей в месяц.
• Интернет-магазин с тысячами товаров и активной фильтрацией, на котором кеш дает мало (каждый пользователь смотрит свою комбинацию фильтров).
• Сайт с большой долей залогиненных пользователей, для которых кеш не работает.
• Сайт, где нужно крутить тяжёлый PHP-процесс или выполнять задачи дольше 30 секунд (типичный лимит shared).
• Сайт, у которого пиковая нагрузка кратковременная, и shared под ней просто отдаёт 503.

Переход на VPS это не магия. Это другая инфраструктура, и она требует, чтобы кто-то её обслуживал: устанавливал и настраивал nginx + PHP-FPM, обновлял систему, разбирался с резервным копированием. Если делать самому без опыта, легко сделать хуже, чем было.

Я обычно ставлю клиентам стек nginx + PHP-FPM + MariaDB на FirstVDS или Selectel, с панелью FastPanel или ISPmanager 6 для удобного управления. На типичном сайте после миграции TTFB опускается до 80-150 миллисекунд, и появляется запас по нагрузке.

Чек-лист на ближайший вечер

Если сейчас у вас TTFB больше 600 мс на главной, попробуйте по порядку.

• Замерьте через curl -w "..." или pagespeed.web.dev сегодняшние цифры.
• Установите Query Monitor для WordPress или включите профилировщик Битрикса.
• Включите OPcache через настройки PHP.
• Поставьте серверный кеш: WP Super Cache, Cache Enabler или композитный режим Битрикса.
• Обновите PHP до 8.2 или 8.3 на staging, протестируйте, переключите прод.
• Отключите неиспользуемые плагины.
• Замерьте снова и сравните.

В большинстве случаев TTFB после этих шагов падает в 3-5 раз и без переезда на VPS.

Когда нужно делегировать

Если самому копаться в Query Monitor и .htaccess нет желания, я обычно делаю аудит производительности сайта за 4-8 часов и сдаю короткий список конкретных правок. Дальше или вы сами по плану, или я веду работы. Это входит в часовую ставку или в любой из тарифов на /#pricing.

Если хотите быстрый замер и план, опишите ситуацию через /#contact. Связанные материалы про скорость, кеширование и хостинг собраны в /blog/category/speed/ и /blog/category/support/.

Частые вопросы

Из чего складывается TTFB

Из сетевой задержки и времени генерации ответа. Сеть внутри России съедает десятки миллисекунд. Всё остальное это работа PHP и базы.

Как ускорить TTFB без перехода на VPS

Включить кэш байт-кода PHP, поставить кэш страниц для анонимных посетителей, разгрузить базу и убрать синхронные обращения к внешним сервисам. Обычно этого хватает, чтобы уйти из красной зоны.

Поможет ли переезд на VPS

Только если упираетесь в ресурсы хостинга. Если страница медленно собирается из-за тяжёлого кода и запущенной базы, на VPS она будет собираться так же медленно, только дороже.

Какое значение считать нормальным

Для сайта на обычном хостинге 300-600 мс это норма. Свыше секунды уже повод разбираться, потому что дальше никакая работа с фронтендом метрики не вытянет.