Время ответа сервера сайта: как проверить и уменьшить TTFB

Часть 6 из 6 · Серия «Скорость сайта без магии»

Пять частей мы шли по цепочке загрузки от конца к началу: сначала научились измерять, потом искали причину по симптому, разобрали метрики, занялись изображениями и стилями со скриптами.

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

Разберём этот участок и на нём закончим серию.

Что такое TTFB и что в него входит

Time to First Byte — время от начала перехода на страницу до момента, когда приходит первый байт ответа.

Важно, что это не только «сервер думал». По документации web.dev, в TTFB входят:

переадресации (редиректы)
запуск service worker, если он есть
поиск адреса по DNS
установка соединения и согласование TLS
сам запрос
… до первого байта ответа

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

Отдельно проясним частую путаницу. Сообщения вида «время ожидания ответа сервера истекло» или «превышено время ответа от сервера» — это ошибки соединения: сервер не ответил вовсе. TTFB — про другое: ответ пришёл, вопрос лишь в том, насколько быстро. Дальше речь только о втором.

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

Ориентиры из той же документации:

И сразу важная оговорка: TTFB не входит в Core Web Vitals. Это вспомогательная метрика — она помогает объяснить, почему у страницы плохой LCP, но сама по себе целью не является. Если TTFB держится около секунды, а главный элемент появляется быстро, гнаться за десятыми долями не нужно.

Как проверить время ответа сервера сайта

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

1. Отчёт о скорости. В результатах проверки страницы есть отдельный показатель ответа сервера. Это самый простой способ увидеть цифру.
2. Панель разработчика в браузере. Вкладка «Сеть», первый запрос в списке — там видно, сколько заняли ожидание ответа и загрузка.
3. Разные страницы. Проверьте главную, карточку товара и страницу категории. Если медленно везде одинаково — дело в сервере или тарифе. Если медленно только на каталоге — в работе приложения или базы.
4. Первый и повторный визит. Резкая разница между ними — почти всегда признак кэширования: первый запрос собирает страницу, второй отдаёт готовую.

Одного запуска мало по той же причине, что и в первой части: ответ сервера плавает. Сделайте несколько замеров и смотрите на середину серии, а не на самый удачный результат.

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

Редиректы

Каждая переадресация — это отдельный полный оборот: запрос ушёл, вернулся ответ «идите по другому адресу», браузер пошёл заново.

Классическая цепочка выглядит так:

http://site.ru
  → https://site.ru
    → https://www.site.ru
      → https://www.site.ru/catalog/

Три оборота вместо одного. Лечится настройкой: сразу вести на конечный адрес, а не выстраивать лестницу. Отдельно проверьте ссылки внутри самого сайта и в рекламных кампаниях — часто именно они ведут на устаревший адрес, с которого начинается цепочка.

Приложение собирает страницу заново на каждый запрос

Самая частая причина у сайтов на CMS. Каждый визит запускает один и тот же цикл: подняться, прочитать настройки, сходить в базу, собрать шаблон, отдать HTML. Для страницы, которая не менялась неделю, это чистая трата.

Решение — кэширование, о нём отдельно ниже.

База данных

Тяжёлые запросы на страницах каталога, отсутствие индексов, выборка всего подряд там, где нужны двадцать позиций. На маленьком сервере база ещё и конкурирует за память с самим приложением — эта механика подробно разобрана в статье «MySQL на маленьком VPS: почему база съедает всю память».

Внешние сервисы в момент запроса

Курс валют, остатки со склада, отзывы, рекомендации. Если приложение ходит за ними синхронно и ждёт ответа, ваш TTFB равен вашему серверу плюс чужому. А чужой сервер вы не контролируете.

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

Ограничения тарифа и соседи

На виртуальном хостинге ресурсы делятся между сайтами. Всплеск у соседа превращается в ваши задержки, а собственные лимиты по процессору упираются в потолок ровно в час пик. Что именно ограничивает тариф, разобрано в статье «Гигабайты ничего не решают», а признаки того, что дело действительно в хостинге, — в материале «Сайт тормозит на хостинге».

Расстояние

Сервер в другом полушарии добавляет задержку самим фактом расстояния — сигналу нужно время. Для аудитории из одной страны проще держать сервер рядом с ней. Сеть доставки контента помогает статике (картинки, стили, скрипты), но HTML, собираемый приложением, обычно всё равно едет с исходного сервера.

Кэширование сайтов: главный рычаг

Если из этой статьи запоминать одну вещь — пусть это будет кэширование. Оно даёт самый большой выигрыш за самые скромные усилия.

Смысл простой: не делать заново работу, результат которой уже известен.

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

Кэш внутри приложения. Результаты тяжёлых запросов к базе, настройки, скомпилированные шаблоны, ответы внешних сервисов. Работает даже там, где страницу целиком закэшировать нельзя.

Заголовки для браузера. Указания, сколько хранить у себя стили, скрипты, шрифты и изображения. Повторный визит вообще не доходит до сервера.

Что кэшировать нельзя — и это важнее, чем кажется:

корзина
личный кабинет
оформление заказа
страницы после входа
всё, что различается для разных посетителей

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

Технические варианты — от простых заголовков до Redis и кэша на уровне веб-сервера — разобраны в статье «Кэширование на пальцах». Владельцу сайта на популярной CMS обычно достаточно включить страничный кэш штатными средствами и не ставить рядом второй такой же плагин.

Gzip и Brotli: сжатие текста в пути

HTML, CSS, JavaScript, SVG и JSON — обычный текст, а текст сжимается отлично. Сервер отдаёт их в сжатом виде, браузер распаковывает у себя.

Механика согласования простая: браузер сообщает, какие способы сжатия понимает, сервер выбирает из них. Brotli сжимает текст плотнее gzip и поддерживается современными браузерами; gzip остаётся универсальным запасным вариантом. Ничего настраивать в браузере не нужно — договорённость происходит сама.

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

Чего не нужно делать: сжимать то, что уже сжато. JPEG, WebP, видео и архивы от повторного прохода не уменьшатся, а процессорное время потратят.

Когда дело действительно в хостинге

Мы начинали серию с предупреждения: не менять хостинг по одному низкому баллу. Пора сказать, когда переезд оправдан.

Признаки, что вы упёрлись в площадку:

• время ответа велико на всех страницах, включая простые;
• кэширование включено и работает, а разницы почти нет;
• задержки заметно растут в часы наибольшей посещаемости;
• в панели видно упор в лимиты процессора или памяти;
• поддержка подтверждает, что тариф исчерпан.

Если это про вас, дальше выбор между более старшим тарифом и переходом на отдельный сервер — этот разговор подробно разобран в статье «Когда виртуальный хостинг стал тесен». Тонкая настройка веб-сервера и обработчика PHP — тема материала «Тормозит сайт — виноват не хостинг: тюним nginx и PHP-FPM».

А если ни один признак не совпал — переезд, скорее всего, ничего не изменит. Тяжёлые картинки и лишние скрипты переезжают вместе с сайтом.

Порядок действий

1. измерить время ответа на нескольких страницах
2. убрать лишние редиректы
3. включить кэш готовых страниц
4. исключить из кэша персональные страницы
5. включить сжатие текстовых файлов
6. вынести обращения к внешним сервисам из момента запроса
7. заняться тяжёлыми запросами к базе
8. и только теперь обсуждать тариф

Правило прежнее: одно изменение — один замер. Кэширование особенно коварно тем, что после его включения любая правка может «не работать», пока не сброшен кэш.

Чек-лист

[ ] время ответа известно и измерено несколько раз
[ ] проверены главная, каталог и карточка отдельно
[ ] цепочка редиректов не длиннее одного шага
[ ] кэш готовых страниц включён
[ ] корзина и личный кабинет из кэша исключены
[ ] сжатие текстовых файлов работает
[ ] внешние API не вызываются синхронно при запросе
[ ] проверено поведение в час пик, а не только ночью

Проверка в Turbo

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

Ссылку на отчёт удобно приложить к обращению в поддержку хостинга: разговор «у меня медленно» и разговор «вот замер, ответ сервера столько-то, вот страницы» проходят по-разному.

Короткие ответы на частые вопросы

Как проверить время ответа сервера сайта?

Запустите проверку страницы в PageSpeed Insights или Turbo и найдите показатель ответа сервера — либо откройте панель разработчика в браузере, вкладку «Сеть», и посмотрите время первого запроса. Проверяйте несколько разных страниц и делайте несколько замеров: одиночный результат плавает.

Что такое TTFB сайта и какое значение нормально?

TTFB — время от начала перехода на страницу до прихода первого байта ответа; в него входят редиректы, поиск DNS, установка соединения и работа самого сервера. Хорошим считается значение до 0,8 секунды, плохим — больше 1,8 секунды. При этом TTFB не входит в Core Web Vitals: это вспомогательная метрика, а не самостоятельная цель.

Как уменьшить время ответа сервера?

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

Что даёт кэширование страниц сайта?

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

Нужно ли включать gzip сжатие сайта?

Да, для текстовых файлов — HTML, CSS, JavaScript, SVG и JSON — это дешёвая и безопасная настройка на стороне сервера. Современные браузеры понимают и более плотный Brotli, а gzip остаётся универсальным запасным вариантом. Уже сжатые файлы — фотографии, видео, архивы — сжимать повторно не нужно.

Чем закончилась серия

Шесть частей складываются в один порядок действий:

1. Проверить скорость и зафиксировать исходную точку.
2. Найти участок, где теряется время, по симптому.
3. Назвать проблему метрикой: LCP, CLS или INP.
4. Разобраться с изображениями — чаще всего именно они держат первый экран.
5. Убрать лишние стили и скрипты, мешающие рисовать и нажимать.
6. Ускорить ответ сервера — эта статья.

И три правила, которые повторялись в каждой части, потому что экономят больше всего времени:

• Сначала измерить, потом чинить. Гипотеза без замера — это лотерея.
• Одно изменение — один замер. Иначе вы не узнаете, что сработало.
• Цель — действие посетителя, а не число в отчёте. Сто баллов не продают товар; быстро появляющаяся цена и кнопка, которая сразу отвечает, — продают.

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

Проверить свой сайт, увидеть причины по влиянию и сохранить отчёт для сравнения можно бесплатно на turbo.siteko.net.