TTFB — время от запроса до первого байта ответа. Метрика не входит в Core Web Vitals, но влияет на все три: пока сервер не ответил, браузер не может ни загрузить ресурсы, ни отрисовать страницу. Если TTFB полторы секунды, уложиться в норматив по LCP уже невозможно, сколько картинки ни сжимай. Разбираемся, из чего складывается это время.
Коротко
- TTFB входит в LCP: пока сервер думает, браузер не может начать отрисовку.
- Ориентир для большинства сайтов — до 0,8 секунды.
- Самая результативная мера для сайтов на CMS — кэширование готовых страниц.
- Цепочки редиректов добавляют к TTFB время каждого промежуточного ответа.
Из чего складывается TTFB
| Этап | Что происходит | На что влияет |
|---|---|---|
| Редиректы | Промежуточные перенаправления | Каждое добавляет полный цикл запроса |
| Поиск адреса сервера | Определение IP по имени домена | Настройки DNS, время жизни записей |
| Установка соединения | Рукопожатие, в том числе защищённое | Расстояние до сервера, версия протокола |
| Обработка запроса | Сервер формирует страницу | Кэш, база данных, код |
У большинства сайтов основное время уходит на последний этап. Но прежде чем оптимизировать код, стоит убедиться, что первые три не съедают половину: лишний редирект способен добавить сотни миллисекунд на ровном месте.
Ориентир. До 0,8 секунды — приемлемо для большинства сайтов, до 0,2 — хорошо. Значения выше полутора секунд означают, что остальная оптимизация скорости будет малоэффективной: вы упрётесь в сервер.
Кэширование: главная мера
Для сайта на CMS каждая страница обычно собирается заново: запросы к базе, шаблоны, модули. Кэширование сохраняет готовый результат и отдаёт его без пересборки.
Кэш страниц целиком
Самый большой выигрыш. Готовый HTML отдаётся сразу, без обращения к базе.
Кэш запросов к базе
Помогает там, где полный кэш невозможен: в личном кабинете, корзине.
Кэш на уровне веб-сервера
Отдаёт сохранённые страницы, не доходя до приложения вовсе.
Продумайте сброс кэша
Чтобы изменения появлялись сразу: при правке товара его страница и разделы должны обновиться.
Частая ошибка. Кэш включают, но не проверяют, работает ли он. Загляните в заголовки ответа: обычно там видно, попал запрос в кэш или нет. Бывает, что кэш отключается сессией, куками или параметрами в адресе — и фактически не работает ни разу.
База данных и код
Если полный кэш невозможен, разбираются с тем, что происходит при сборке страницы.
- Найдите самые долгие запросы. Один неоптимальный запрос к большой таблице легко съедает секунду.
- Проверьте индексы. Отсутствие индекса на поле, по которому идёт отбор, — классическая причина.
- Уберите запросы в цикле. Сто карточек, каждая со своим запросом, — сто обращений к базе вместо одного.
- Отключите лишние модули. На сайтах с историей их обычно накапливается много, и каждый что-то делает при каждой загрузке.
- Обновите версию языка. Разница между старой и современной версией бывает кратной при том же коде.
- Вынесите тяжёлое в фон. Отправка писем, генерация отчётов, обращения к внешним сервисам не должны происходить во время отрисовки страницы.
Инфраструктура
| Мера | Когда помогает |
|---|---|
| Сменить тариф хостинга | Сервер медленный даже на лёгких страницах |
| Перенести сервер ближе к аудитории | Аудитория в одном регионе, сервер далеко |
| Подключить CDN | Аудитория распределена по стране или миру |
| Включить современный протокол | Много ресурсов на странице |
| Настроить время жизни DNS-записей | Заметное время уходит на поиск адреса |
Про смену хостинга. Это популярный первый шаг и часто преждевременный. Сначала проверьте, что дело не в коде и не в отсутствии кэша: медленный сайт на быстром сервере останется медленным, просто дороже.
Редиректы: незаметный расход
Каждое перенаправление — это полный цикл: запрос, ответ, новый запрос. Цепочка из трёх звеньев утраивает время до начала реальной загрузки.
Типичные цепочки
- http → https → с www → без www
- Адрес без слеша → со слешем → каноничный
- Старый адрес → промежуточный → новый
- Мобильная версия → основная
Как должно быть
- Один редирект сразу на конечный адрес
- Внутренние ссылки ведут на конечные адреса
- Цепочки выпрямлены до одного шага
- В карте сайта только конечные адреса
Проверяется быстро: любой сервис проверки заголовков покажет всю цепочку. Особенно внимательно стоит посмотреть, что происходит при заходе на голый домен без протокола — там цепочки водятся чаще всего.
Как измерить
- PageSpeed Insights. Показывает TTFB и в полевых, и в лабораторных данных.
- Инструменты разработчика. Вкладка «Сеть», первый запрос, строка ожидания ответа.
- Сервисы проверки заголовков. Заодно покажут цепочку редиректов.
- Проверка с пустым кэшем. Обязательно: закэшированная страница отдаётся быстро и скрывает проблему.
- Проверка разных типов страниц. Главная, карточка, категория, результаты фильтра — время может отличаться в разы.
Измеряйте страницу, а не только главную. Главная обычно закэширована лучше всех. Реальные проблемы живут на страницах фильтров и поиска по сайту, где кэш не работает, а запросов к базе больше всего.
Частые вопросы
Какой TTFB считается нормальным?
До 0,8 секунды приемлемо для большинства сайтов, до 0,2 — хорошо. Выше полутора секунд остальная работа над скоростью почти бесполезна: вы упрётесь в сервер.
Входит ли TTFB в Core Web Vitals?
Нет, это вспомогательная метрика. Но она входит в LCP как первая его часть: пока сервер не ответил, браузер не может начать отрисовку.
Поможет ли смена хостинга уменьшить TTFB?
Иногда да, но это стоит проверять после кэша и оптимизации кода. Медленный сайт на быстром сервере останется медленным. Показатель того, что дело в хостинге, — медленный ответ даже на пустой странице с включённым кэшем.
Почему TTFB хороший на главной и плохой на страницах фильтров?
Главная обычно закэширована, а страницы фильтров генерируются заново при каждом запросе и делают больше обращений к базе. Именно их и нужно проверять в первую очередь.
Читайте также
Сделаем сайт, который приносит заявки
Спроектируем структуру под запросы, соберём и запустим — с учётом SEO с первого дня.
Обсудить разработку
