Хостинг быстрый, а сайт тормозит: куда исчезает секунда до первого байта

Знакомая история: вы заплатили за «премиум-хостинг с NVMe и турбо-режимом», а сайт всё равно думает секунду-полторы, прежде чем показать хоть что-то. Открываешь страницу — белый экран, крутится вкладка, и только потом рывком появляется контент. При этом хостер клянётся, что сервер быстрый, тесты диска отличные, а место занято на треть. Кто виноват? Если решите не разбираться в одиночку — я профессионально занимаюсь SEO-продвижением сайтов с 2005 года и разберу ваш случай лично.

В девяти случаях из десяти виноват TTFB — время до первого байта. Это самая недооценённая метрика скорости, про которую владельцы бизнеса вообще не слышали, а зря: именно она чаще всего объясняет, почему «быстрый хостинг» не спасает. За 20 лет я разгребал этот вопрос на сотнях проектов — от лендингов до магазинов на 50 000 товаров — и в этой статье разберу по косточкам, что такое TTFB, почему он не равен скорости загрузки, что на него влияет и как его починить, не переплачивая за железо.

Что такое TTFB простыми словами

TTFB (Time To First Byte, время до первого байта) — это пауза между моментом, когда браузер отправил запрос на сервер, и моментом, когда он получил самый первый байт ответа. Не всю страницу. Не картинки. Один-единственный байт — сигнал «я тебя услышал, держи начало ответа».

Представьте, что вы звоните в кол-центр. TTFB — это время от гудка до того, как трубку сняли и вы услышали «здравствуйте». Ещё ничего не решили, ни один вопрос не задали — просто вам ответили. Если оператор снимает трубку через 12 секунд, вы уже раздражены, хотя разговор даже не начался. С сайтом то же самое: пока сервер «снимает трубку», пользователь смотрит на пустой белый экран.

Из чего складывается это ожидание? Технически TTFB — сумма трёх кусков: время на установку соединения (DNS, TCP, TLS-рукопожатие), время на дорогу запроса до сервера и обратно, и — самое главное — время, которое сервер тратит, чтобы сформировать ответ. Вот этот третий кусок, работа бэкенда, обычно и раздувает метрику до неприличных значений.

Хороший ориентир по цифрам, которым я пользуюсь на проектах:

• до 200 мс — отлично, сервер отвечает мгновенно;
• 200–500 мс — нормально, пользователь не замечает задержки;
• 500–800 мс — уже чувствуется, пора разбираться;
• больше 800 мс — плохо, а больше 1,5 секунд — критично, вы теряете и людей, и позиции.

Почему TTFB — это не то же самое, что скорость загрузки

Здесь кроется главная путаница, из-за которой люди годами лечат не ту болезнь. Скорость загрузки страницы — это когда всё дорисовалось: текст, картинки, кнопки, шрифты. А TTFB — это только самое начало, ответ сервера. Это две разные стадии, и лечатся они разными методами.

Разберу на пальцах. Вся загрузка страницы делится на два больших этапа. Первый — серверный: браузер постучался, сервер подумал, собрал HTML и отдал первый байт. Второй — клиентский: браузер получил HTML и начал грузить и рисовать всё остальное — стили, скрипты, шрифты, изображения. TTFB отвечает только за первый этап.

Почему это важно понимать? Потому что 90% советов в интернете про «ускорение сайта» — сжать картинки, включить lazy-load, минифицировать CSS — лечат второй этап, клиентский. И если у вас проблема на первом, серверном, эти советы дадут ноль. Вы можете сжать все картинки до последнего килобайта, но если сервер отдаёт первый байт через 2 секунды, сайт всё равно останется медленным. Про клиентскую часть я подробно писал в отдельном материале о том, как повысить скорость загрузки сайта — там про фронтенд, а тут мы копаем именно в сервер.

Аналогия из жизни. Вы заказали еду в ресторане. TTFB — это время, пока официант принял заказ и кухня начала готовить. Скорость загрузки — это когда блюдо уже стоит перед вами, разложенное и украшенное. Если кухня тормозит с самого начала (высокий TTFB), не важно, как красиво потом подадут — вы уже голодный и злой сидите 40 минут.

Что влияет на TTFB: разбираем по элементам

TTFB — это не одна кнопка, а результат работы целой цепочки. Слабое звено в любом месте раздувает метрику. Пройдусь по всем звеньям, которые реально двигают цифру на моих проектах.

Хостинг и тариф. На дешёвом виртуальном хостинге ваш сайт живёт на одном сервере с сотнями чужих. Сосед запустил тяжёлый импорт — у вас просел ответ. Это называется «шумные соседи», и на shared-хостинге вы им никак не управляете. Мощность процессора и оперативка тоже поделены. Отсюда парадокс: диск NVMe быстрый, а сайт тормозит, потому что упирается не в диск, а в очередь к общему процессору.

Бэкенд — код и движок сайта. Это чаще всего главный виновник. Каждый раз, когда открывается страница, PHP-движок (WordPress, Битрикс, MODX) заново собирает её из кусков: лезет в базу, считает меню, подтягивает виджеты, прогоняет всё через плагины. Чем больше плагинов и чем кривее код — тем дольше сборка. Я видел сайты, где 20 плагинов добавляли к TTFB по 40–70 мс каждый.

Кэш. Кэш — это когда сервер один раз собрал страницу и запомнил готовый результат. Следующему посетителю он отдаёт заготовку мгновенно, не пересобирая. Без кэша каждый запрос — это полная пересборка с нуля. Разница колоссальная: с 1200 мс до 150 мс на одном и том же железе, я это делал десятки раз.

База данных. Движок сайта постоянно спрашивает базу: «дай товары этой категории», «дай последние статьи», «дай настройки». Если запросов сотни, если в них нет индексов, если таблицы разрослись и захламлены — база отвечает медленно, и весь TTFB встаёт колом. На больших магазинах база — узкое горло номер один.

CDN и география сервера. Данные не телепортируются — они идут по проводам со скоростью, ограниченной физикой. Если ваш сервер стоит в Германии, а клиент в Новосибирске, каждый запрос делает лишний круг в тысячи километров. CDN (сеть распределённых серверов) частично лечит это, раздавая контент с ближайшей к пользователю точки. Для регионального бизнеса география сервера критична — об этом ниже.

Как измерить TTFB: инструменты и что смотреть

Прежде чем лечить, надо померить — иначе будете гадать. Хорошая новость: TTFB измеряется бесплатно и за минуту. Вот чем пользуюсь я и что рекомендую вам.

• DevTools в браузере. Нажмите F12, вкладка Network, обновите страницу, кликните на самый первый запрос (документ). В строке Timing будет пункт «Waiting for server response» — это и есть ваш TTFB. Самый честный способ, показывает реальную картину для вашего местоположения.
• PageSpeed Insights от Google. Показывает метрику TTFB в разделе диагностики и данные реальных пользователей (поле). Удобно, что видно среднее по живому трафику, а не по одному замеру.
• WebPageTest. Позволяет выбрать город, из которого делать замер. Незаменимо, чтобы проверить, как отвечает сервер для клиентов из вашего региона, а не из дата-центра Google.
• Простой замер через консоль. Команда curl с выводом времени до первого байта даёт голую цифру без клиентских наворотов — чистое время сервера.

Важный момент: меряйте несколько раз и в разное время суток. Первый заход часто «холодный» (кэш пустой), повторные — «горячие». Если TTFB скачет от 200 мс до 2 секунд — это верный признак проблемы с кэшем или перегруженного shared-хостинга. Стабильно высокий TTFB — это уже бэкенд или база. Всё это, кстати, часть нормального технического аудита сайта, с которого я начинаю почти любой проект — сначала диагностика, потом лечение.

Типичные причины медленного TTFB на WordPress

WordPress — самый популярный движок, и самый частый пациент. Он гибкий, но именно эта гибкость его и топит: люди навешивают плагины и темы, не понимая, во что это выливается на сервере. Вот что я вижу чаще всего.

Плагинный зоопарк. 25–40 плагинов — обычная картина у среднего бизнеса. Половина не используется, но каждый грузится при каждом запросе. Особенно опасны «универсальные» конструкторы страниц и тяжёлые SEO-комбайны — они лезут в базу десятки раз на одну загрузку.

Отсутствие кэширования. Голый WordPress без кэш-плагина пересобирает страницу заново каждому посетителю. Установка нормального кэша (страничного) — самый быстрый способ сбить TTFB в разы, это первое, что я делаю.

Тяжёлая тема. Красивая тема с «100 демо в комплекте» тащит за собой гору кода, который выполняется на каждый запрос. Лёгкая тема плюс правильная вёрстка — и TTFB падает без всяких плагинов.

Мусор в базе. WordPress копит ревизии постов, спам-комментарии, временные записи (transients), логи. За пару лет база распухает так, что каждый запрос ползёт. Чистка базы — недооценённая процедура, а эффект заметный.

Внешние запросы на лету. Некоторые плагины при загрузке страницы стучатся на сторонние сервисы — проверить лицензию, подтянуть курс валют, загрузить шрифт. Если внешний сервис тупит, ваш TTFB тупит вместе с ним. Это коварная штука, её сложно поймать без профилирования.

Типичные причины медленного TTFB на Битрикс

Битрикс — отдельная песня. Мощная система для магазинов, но по умолчанию она прожорлива, и без настройки TTFB там легко улетает за секунду. Что душит Битрикс на практике:

• Выключенный или неправильный композит. «Композитный кэш» — родная технология Битрикса, которая отдаёт статичную версию страницы мгновенно. Если он выключен или настроен криво, сервер собирает страницу целиком каждый раз.
• Неоптимальные комплексные компоненты. Каталог, корзина, фильтры делают тяжёлые выборки из базы. Без кэширования компонентов и индексов эти выборки становятся гирей на TTFB.
• Раздутая база на большом каталоге. На магазинах с десятками тысяч товаров таблицы огромные. Если умный фильтр не переиндексирован, а инфоблоки не оптимизированы — каждый запрос месит гигабайты.
• Агент и хиты на крон. Битрикс запускает фоновые задачи «на хитах» — то есть за счёт посетителя. Если агенты не переведены на крон, ваш случайный пользователь оплачивает своим ожиданием чужую рассылку.
• Требовательность к железу. Битрикс честно требует мощный сервер. На дешёвом shared-хостинге он будет тормозить, что ни делай — тут экономия выходит боком.

Как ускорить TTFB: рабочий план

Теперь самое ценное — что конкретно делать. Я расставил шаги по соотношению «эффект к усилиям»: сверху то, что даёт максимум за минимум труда.

1. Включите страничный кэш. Это номер один по эффективности. Готовая страница отдаётся из памяти без пересборки. На WordPress — кэш-плагин, на Битриксе — композит, на связке nginx — full page cache. Один этот шаг часто срезает TTFB в 5–10 раз. Единственная оговорка: если на сайте есть динамика (корзина, личный кабинет, формы), кэш надо настраивать аккуратно, чтобы не сломать функционал — я на одном проекте так чуть не убил рабочую форму заявок, пришлось точечно исключать её из кэша.

2. Почистите плагины и код. Отключите всё, чем реально не пользуетесь. Правило простое: каждый плагин должен окупать своё присутствие. 15 нужных плагинов лучше 40, из которых работают 15.

3. Оптимизируйте базу. Удалите ревизии, спам, старые логи. Добавьте индексы на часто запрашиваемые поля. На больших сайтах это даёт кратный прирост. Это уже задача для специалиста, но эффект того стоит.

4. Подключите объектный кэш и OPcache. OPcache хранит скомпилированный PHP-код, чтобы не компилировать его заново на каждый запрос. Объектный кэш (Redis, Memcached) держит результаты запросов к базе в оперативке. Оба включаются на уровне сервера и заметно снижают TTFB.

5. Обновите PHP и настройте сервер. Свежий PHP 8.x в разы быстрее старых версий. Плюс правильная связка nginx + PHP-FPM вместо тяжёлого Apache в лоб. Просто переход со старого PHP на новый иногда срезает треть времени ответа.

6. Смените тариф или хостинг, если упёрлись. Если вы почистили всё, а TTFB всё равно высокий и скачет — значит, вы уперлись в железо соседей. Переезд с shared на VPS или выделенный сервер снимает потолок. Но делайте это последним шагом, а не первым: сначала выжмите софт.

7. Поставьте CDN. Для сайтов с посетителями из разных регионов и стран CDN раздаёт контент с ближайшей точки и разгружает основной сервер. Это лечит и географию, и пиковые нагрузки.

География сервера: почему это важно для регионов

Отдельно про географию, потому что это недооценивают. Данные идут по проводам, и физику не обманешь: чем дальше сервер от клиента, тем больше миллисекунд накидывается только на дорогу. Сервер во Франкфурте и клиент во Владивостоке — это гарантированные лишние 100–200 мс на пустом месте, ещё до того, как сервер начал думать.

Для местного бизнеса вывод прямой: сервер должен стоять в России, ближе к вашей аудитории. Это не только про скорость — Яндекс учитывает географию хостинга как один из сигналов при региональном ранжировании. Если вы продвигаетесь по конкретному городу, российский хостинг — часть гигиены. Я всегда закладываю это в стратегию, когда занимаюсь региональным продвижением: быстрый и географически близкий сервер работает на вас в связке с остальным.

Как TTFB влияет на позиции и поведение людей

Тут два фронта, и оба бьют по деньгам. Первый — поведенческий. Пока сервер «снимает трубку», человек смотрит на белый экран. Исследования и мой опыт сходятся: каждая лишняя секунда ожидания заметно повышает долю тех, кто закрывает вкладку не дождавшись. Особенно на мобильных, где терпение короче. Человек ушёл — это потерянная заявка, за которую вы, возможно, заплатили рекламой.

Второй фронт — поисковый. Поисковые системы видят, что люди уходят с медленного сайта, и делают выводы. Быстрый отклик сервера входит в оценку качества страницы напрямую (в Google это часть Core Web Vitals) и косвенно — через поведенческие факторы ранжирования. Медленный TTFB тянет вниз по обоим каналам: и метрика плохая, и люди разбегаются, что портит поведенческие. Получается двойной удар по позициям.

Есть и третий, менее очевидный момент — индексация. Поисковый робот тратит ограниченный бюджет на обход сайта. Если каждая страница отвечает медленно, робот успевает обойти меньше страниц за тот же заход. На больших сайтах это реально тормозит попадание новых страниц в поиск — я разбирал механику в материале про индексацию сайта в поисковых системах. Медленный сервер бьёт даже туда, куда обычно не смотрят.

И ещё про деньги напрямую: если вы льёте трафик из Яндекс Директа, медленный TTFB сжигает бюджет. Вы платите за клик, человек приходит, видит белый экран, уходит — деньги за клик потрачены, заявки нет. Скорость сервера здесь конвертируется в стоимость лида буквально.

Реальный пример с моего проекта

Чтобы не звучать абстрактно — свежий кейс. Пришёл интернет-магазин на Битриксе, около 8000 товаров. Жалоба классическая: «Переехали на дорогой хостинг с обещанием скорости, а сайт как тормозил, так и тормозит, реклама сливается впустую».

Замерил TTFB — 1,7 секунды на главной, до 2,4 на карточках товара. Хостинг реально был неплохой. Стал копать бэкенд: композитный кэш выключен, умный фильтр не переиндексирован, база забита старыми логами и незакрытыми сессиями, PHP старой версии, часть агентов крутится «на хитах».

Что сделал по порядку: включил и настроил композит, перевёл агенты на крон, переиндексировал фильтр, почистил и оптимизировал базу, обновил PHP, добавил объектный кэш. Ни рубля на новое железо. Итог: TTFB упал до 210–280 мс на главной и до 400 мс на карточках. Отказы с рекламного трафика снизились ощутимо, а через два месяца подтянулись и позиции по среднечастотке. Мораль простая: дело было не в хостинге, а в том, что на нём никто не настроил софт. Такие вещи всплывают на комплексном аудите сайта — когда смотришь и технику, и поведение, и коммерцию разом.

Коротко: главное о TTFB

• TTFB — время до первого байта, пауза между запросом браузера и первым ответом сервера. Это про «сервер снял трубку», а не про то, что страница дорисовалась.
• Это не скорость загрузки. TTFB — серверный этап, скорость загрузки — клиентский. Сжатие картинок не лечит медленный сервер.
• Норма — до 200 мс отлично, до 500 мс нормально, больше 800 мс — уже проблема, больше 1,5 с — критично.
• Главные виновники — отсутствие кэша, зоопарк плагинов, тяжёлый бэкенд, захламлённая база, слабый или общий хостинг, далёкий сервер.
• Первое лекарство — страничный кэш. Часто срезает TTFB в 5–10 раз без затрат на железо.
• Мерить — DevTools (Waiting for server response), PageSpeed Insights, WebPageTest, curl. Несколько раз и в разное время.
• География — для регионального бизнеса сервер должен стоять в России, ближе к клиентам. Это и скорость, и сигнал для Яндекса.
• Цена вопроса — медленный TTFB роняет позиции, повышает отказы, сжигает рекламный бюджет и тормозит индексацию. Двойной, а то и тройной удар.

Что делать вам прямо сейчас

Не гадайте — измерьте. Откройте F12, посмотрите «Waiting for server response» на главной и на нескольких внутренних страницах. Если цифра стабильно за 800 мс — у вас есть проблема, и почти наверняка она решается настройкой софта, а не переплатой за железо. Если скачет — копайте в кэш и хостинг.

Хорошая новость в том, что TTFB — одна из самых благодарных метрик: усилия окупаются быстро и видно сразу. Часто хватает включить кэш и почистить лишнее, чтобы сайт «ожил». Если хотите разобраться, где именно у вас утекает время, и получить конкретный план без общих слов — приходите на SEO-консультацию, посмотрю ваш сервер и скажу прямо, что тормозит и что с этим делать. А если решать некому — возьму доработку сайта на себя и доведу TTFB до нормы.