TTFB: как разогнать ответ сервера до 200 мс и обогнать конкурентов

Представьте: пользователь кликает по ссылке вашего сайта в выдаче, а в течение целой секунды видит белый экран — браузер ещё даже не получил первый байт ответа. За это время часть посетителей уже нажимает «назад», а поисковый робот фиксирует медлительность и снижает интенсивность обхода. Виновник — TTFB, время до первого байта. Это метрика, с которой начинается вообще вся скорость загрузки: пока сервер думает, никакой Critical CSS, lazy load и оптимизация картинок не помогут, потому что отрисовка ещё не началась. В этой статье разберём по косточкам, из чего складывается TTFB, какие значения считаются хорошими, чем измерять и, главное, как разогнать ответ сервера до 200 мс и ниже.

Что такое TTFB и почему это фундамент скорости

TTFB (Time To First Byte) — это интервал времени между моментом, когда браузер отправил HTTP-запрос, и моментом, когда он получил первый байт ответа от сервера. Проще говоря, это «время раздумий» сервера плюс время на установку соединения и передачу первого фрагмента данных по сети. Метрика измеряется в миллисекундах и является нулевой точкой отсчёта для всего, что происходит дальше: загрузки HTML, парсинга CSS, выполнения JavaScript и финальной отрисовки контента.

Почему это фундамент? Потому что TTFB напрямую сдвигает все остальные метрики скорости. Если сервер отвечает за 800 мс вместо 200 мс, вы теряете лишние 600 мс ещё до того, как браузер начал хоть что-то рисовать. Эти 600 мс «зашиты» в каждую последующую метрику: First Contentful Paint наступит позже, Largest Contentful Paint тоже сдвинется, и никакими клиентскими оптимизациями вы это не компенсируете. Поэтому работу над скоростью почти всегда логично начинать именно с серверной части, а уже потом переходить к фронтенду. Подробнее о связке метрик мы писали в материале о том, как улучшить Core Web Vitals и скорость загрузки.

Формально TTFB не входит в тройку основных Core Web Vitals (LCP, INP, CLS), но он является их прямым предшественником. Google в документации прямо называет TTFB фундаментальным показателем, влияющим на загрузку. На практике связь жёсткая: трудно получить хороший LCP менее 2,5 секунды, если только TTFB уже съедает секунду. Поэтому опытные специалисты воспринимают эту метрику как «бюджет», который нужно держать максимально низким, чтобы остался запас на отрисовку основного контента — про это есть отдельный разбор про ускорение LCP и главного контента страницы.

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

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

• DNS-резолвинг. Браузер преобразует доменное имя в IP-адрес. Обычно занимает 20–120 мс, но при плохом DNS-провайдере или отсутствии кэширования может растягиваться до сотен миллисекунд.
• TCP-хендшейк. Установка соединения по протоколу TCP (трёхстороннее рукопожатие). Зависит от расстояния до сервера и обычно равна одному round-trip-времени (RTT).
• TLS-хендшейк. Согласование шифрования для HTTPS. На старых конфигурациях добавляет один-два RTT. Современный TLS 1.3 и сессионные тикеты заметно ускоряют этот этап.
• Обработка на бэкенде. Самая управляемая и часто самая жирная часть: PHP/Node/Python генерирует страницу, ходит в базу данных, дёргает кэш, выполняет логику плагинов. Тут легко потерять от 100 мс до нескольких секунд.
• Передача первого байта по сети. Финальная фаза — данные физически летят от сервера к клиенту. Зависит от географической удалённости и качества канала.

Ключевой вывод: DNS, TCP и TLS вместе обычно занимают разумные 50–200 мс, и их оптимизируют через CDN и правильные настройки. А вот «время обработки на бэкенде» — это та переменная, которая чаще всего и превращает хороший TTFB в плохой. Именно сюда стоит смотреть в первую очередь при диагностике.

Какие значения TTFB считаются хорошими

Единого жёсткого стандарта нет, но есть устоявшиеся ориентиры, на которые опираются и Google, и большинство SEO-специалистов. Привожу их в виде таблицы — это удобная шпаргалка для оценки текущего состояния.

Значение TTFB	Оценка	Что это значит на практике
менее 200 мс	Отлично	Сервер отвечает почти мгновенно, есть запас на отрисовку
200–500 мс	Норма	Приемлемо для большинства сайтов, но есть куда расти
500–600 мс	Пограничное	Уже заметно для пользователя, стоит заняться оптимизацией
более 600 мс	Проблема	Тормозит весь сайт, бьёт по LCP и поведенческим
более 1000 мс	Критично	Серьёзные потери трафика и проблемы с индексацией

Google в рекомендациях ориентирует на TTFB менее 800 мс как на верхнюю границу «хорошего», но это именно потолок, а не цель. Если вы хотите конкурентного преимущества, целиться нужно в диапазон до 200 мс для основной массы страниц. На практике сайты в ТОП-3 по высокочастотным запросам часто демонстрируют ответ сервера в районе 100–300 мс, и это не совпадение — быстрый сервер косвенно улучшает поведенческие факторы и снижает отказы.

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

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

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

PageSpeed Insights и Lighthouse

В отчёте PageSpeed Insights есть отдельный аудит «Сократите время ответа сервера (TTFB)». Lighthouse показывает Server Response Time. Это быстрый способ получить ориентир, но помните: PSI замеряет с серверов Google, география может отличаться от вашей аудитории. Зато тут же видны и связанные проблемы — render-blocking ресурсы, тяжёлые скрипты.

WebPageTest и GTmetrix

WebPageTest — самый детальный инструмент: он показывает waterfall-диаграмму, где TTFB разбит на фазы DNS, Connect, SSL и Wait. Это лучший способ понять, на каком этапе теряется время. Можно выбрать локацию замера, что критично для оценки географической удалённости. GTmetrix даёт похожую картину с понятной визуализацией и историей замеров.

DevTools, Search Console и Яндекс Вебмастер

Во вкладке Network браузерных DevTools при наведении на запрос документа в строке Timing видно поле Waiting for server response — это и есть TTFB конкретного запроса. В Google Search Console прямого показателя TTFB нет, но раздел «Статистика сканирования» косвенно отражает время ответа для робота. А вот в Яндекс Вебмастере есть прямое поле «Время ответа сервера» в разделе статистики обхода — это ценный источник данных именно с точки зрения поисковика, как мы подробно разбирали в полном руководстве по Яндекс Вебмастеру.

Главные причины медленного TTFB

Прежде чем лечить, поставим диагноз. На практике почти все случаи высокого TTFB сводятся к одной или нескольким из перечисленных причин — расположил их примерно по частоте встречаемости.

• Слабый или перегруженный хостинг. Дешёвый shared-хостинг, где на одной машине живут сотни сайтов, делящих CPU и память. Под нагрузкой соседей ваш сервер начинает «тупить».
• Тяжёлые запросы к базе данных. Неоптимизированные SQL-запросы без индексов, выборки на тысячи строк, разросшаяся таблица wp_options с автозагрузкой — типичная история для WordPress.
• Отсутствие кэширования. Каждый запрос генерирует страницу с нуля: PHP исполняется заново, БД опрашивается заново. Без кэша даже мощный сервер захлёбывается.
• Медленный или устаревший PHP. Старые версии PHP (5.x, 7.0) работают в разы медленнее PHP 8.x. Плюс отсутствие OPcache означает компиляцию скриптов при каждом запросе.
• Географическая удалённость сервера. Если сервер физически в другой стране, каждый RTT добавляет десятки миллисекунд только на сетевую задержку.
• Тяжёлые плагины и темы. Раздутые сборщики страниц, десятки плагинов, внешние API-вызовы прямо в процессе рендеринга — всё это удлиняет обработку на бэкенде.

Чтобы понять, какая именно причина в вашем случае главная, посмотрите waterfall в WebPageTest. Большое значение в фазе Wait при маленьких DNS/Connect/SSL означает проблему на бэкенде (кэш, БД, PHP). А вот раздутые DNS/Connect/SSL указывают на сетевые и инфраструктурные проблемы, которые лечатся CDN и сменой хостинга. Системно вся эта диагностика — часть технического SEO-аудита сайта.

Пошаговое ускорение TTFB до 200 мс

Теперь самое практичное — конкретный план действий. Идём от самого результативного к тонкой настройке. Каждый шаг даёт измеримый эффект, и в сумме они почти всегда выводят TTFB в зелёную зону.

Шаг 1. Адекватный хостинг или VPS

Если вы сидите на дешёвом shared-хостинге и TTFB прыгает от 400 до 1500 мс, никакая оптимизация кода не спасёт стабильно — вас тормозят соседи по серверу. Переход на нормальный VPS или managed-хостинг с выделенными ресурсами часто срезает TTFB в два-три раза сам по себе. Выбирайте провайдера с серверами, географически близкими к вашей аудитории, с SSD/NVMe-дисками и современным стеком. Подробно тему выбора инфраструктуры мы раскрыли в материале про оптимизацию сервера и хостинга для SEO.

Шаг 2. Серверное кэширование: OPcache, Redis, Memcached

OPcache хранит скомпилированный байт-код PHP в памяти, избавляя сервер от перекомпиляции скриптов при каждом запросе — обязательная вещь, включается одной директивой в php.ini. Redis или Memcached используются как объектный кэш: результаты тяжёлых запросов к БД складываются в оперативную память и отдаются мгновенно. Для WordPress это даёт особенно заметный эффект, потому что движок делает десятки запросов к базе на каждой странице.

Шаг 3. Полностраничное кэширование

Самый мощный приём для контентных сайтов: готовый HTML страницы сохраняется целиком и отдаётся следующим посетителям без участия PHP и БД вообще. Это превращает TTFB в десятки миллисекунд. На уровне сервера это делает кэш nginx (fastcgi_cache) или Varnish, на уровне WordPress — плагины вроде WP Super Cache и LiteSpeed Cache. Тонкости настройки кэша для движка мы разбирали в гайде про оптимизацию сайта на WordPress для SEO.

Шаг 4. Оптимизация БД и медленных запросов

Найдите медленные запросы через slow query log MySQL или плагин Query Monitor. Типичные исправления: добавить индексы на часто фильтруемые колонки, почистить разросшиеся таблицы (ревизии, спам-комментарии, transient-записи), отключить автозагрузку ненужных опций в wp_options, оптимизировать таблицы командой OPTIMIZE TABLE. Иногда удаление одного жадного плагина срезает по 200–300 мс с каждого запроса.

Шаг 5. Обновление PHP

Переход с PHP 7.x на PHP 8.1 или 8.2 нередко даёт прирост производительности на 20–40% буквально без изменения кода. Новые версии быстрее интерпретируют скрипты, экономнее работают с памятью и поддерживают JIT-компиляцию. Перед обновлением проверьте совместимость темы и плагинов на тестовой копии.

Шаг 6. CDN и сжатие

CDN распределяет статику и кэш по узлам, физически близким к пользователю, сокращая сетевую задержку и фазы Connect/SSL. Для аудитории из разных регионов это серьёзно стабилизирует TTFB. Детали — в разборе про CDN для SEO и ускорения сайта. Параллельно убедитесь, что включено сжатие текстовых ответов — это уменьшает объём передаваемых данных и ускоряет доставку первого байта, о чём подробно в статье про сжатие Brotli и Gzip.

Влияние TTFB на краулинговый бюджет и индексацию

Скорость ответа сервера важна не только для пользователей. Поисковые роботы Google и Яндекса ограничивают нагрузку на ваш сервер, и если он отвечает медленно, робот сбавляет темп обхода, чтобы не «уронить» сайт. Это напрямую сокращает количество страниц, которые он успевает просканировать за единицу времени — то есть бьёт по краулинговому бюджету. Для крупных сайтов с тысячами страниц это означает, что новые и обновлённые материалы дольше попадают в индекс.

Логика простая: при TTFB в 200 мс робот успевает обойти в несколько раз больше URL, чем при 1000 мс, за тот же интервал. Поэтому быстрый сервер — это ещё и инструмент ускорения индексации, особенно важный для интернет-магазинов и новостных проектов. Подробнее эта взаимосвязь разобрана в материалах про оптимизацию краулингового бюджета и обхода и про то, как ускорить индексацию сайта в Яндексе и Google.

Чек-лист по ускорению TTFB

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

1. Замерьте текущий TTFB в WebPageTest по нескольким типам страниц и разным локациям.
2. Разберите waterfall: определите, где теряется время — на бэкенде (Wait) или в сети (DNS/Connect/SSL).
3. Проверьте версию PHP, обновите до 8.1+ и включите OPcache.
4. Настройте полностраничное кэширование и объектный кэш (Redis/Memcached).
5. Найдите и почините медленные запросы к БД, почистите и оптимизируйте таблицы.
6. Оцените хостинг: при нестабильном TTFB на shared переходите на VPS или managed.
7. Подключите CDN для географически распределённой аудитории.
8. Убедитесь, что включено сжатие текстовых ответов (Brotli/Gzip).
9. Отключите или замените тяжёлые плагины, делающие внешние вызовы при рендеринге.
10. Перемерьте TTFB и проверьте поле «время ответа сервера» в Яндекс Вебмастере через несколько дней.

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

Услуги LSI Продвижение

Наша команда предлагает полный спектр услуг по SEO-продвижению и технической доработке сайтов. Мы работаем только белыми методами, ориентируемся на реальный бизнес-результат — трафик, заявки и продажи, а не только позиции в отчёте, — и выстраиваем продвижение системно, под конкретные задачи и нишу вашего проекта. Начать можно с бесплатной диагностики, чтобы понять текущее состояние сайта и точки роста, а затем перейти к комплексной работе. Выберите подходящую услугу из списка ниже:

• Бесплатный SEO аудит сайта — автоматическая проверка на 50+ параметров за 2 минуты
• Комплексный SEO аудит — глубокий ручной анализ с рекомендациями от эксперта
• Продвижение сайтов — вывод в ТОП Яндекса и Google по целевым запросам
• SEO консультация — разбор вашего сайта с конкретными рекомендациями
• LSI тексты — экспертный контент, оптимизированный для поисковых систем
• Доработка сайта — техническая оптимизация и исправление ошибок
• Создание сайта под ключ — разработка с нуля с SEO-оптимизацией
• Стоимость продвижения — прозрачные тарифы и условия
• Портфолио и кейсы — реальные результаты наших клиентов