Что такое TTFB и как сократить время ответа сервера
Практика3 минРедакция Innovialabs
Коротко
TTFB — время от запроса до первого байта ответа; он задерживает всё остальное, включая LCP, и замедляет сканирование. Его сокращают кэшированием, CDN, статической генерацией, оптимизацией запросов к базе и хостингом рядом с пользователями.
Что такое TTFB
TTFB (Time to First Byte) — время от начала запроса до получения первого байта ответа. В него входят:
- редиректы, если они есть;
- DNS-запрос, установка TCP-соединения и TLS-рукопожатие;
- обработка запроса на сервере: код, запросы к базе, рендеринг HTML;
- путь первого байта обратно к браузеру.
Пока HTML не пришёл, браузер не может начать загружать CSS, шрифты и картинки. Поэтому TTFB — фундамент всей скорости страницы. Ориентир от web.dev: стремиться к TTFB не больше 0,8 секунды для большинства визитов.
Как TTFB влияет на LCP и сканирование
- LCP (отрисовка самого крупного элемента) не может наступить раньше, чем придёт HTML. Если сервер отвечает медленно, хороший LCP получить очень сложно, как бы вы ни оптимизировали картинки.
- Сканирование. Поисковый робот ограничивает нагрузку на сайт. Когда сервер отвечает медленно, робот успевает обойти меньше страниц. Для больших сайтов это значит, что новые страницы дольше попадают в индекс.
Как измерить TTFB из разных регионов
TTFB сильно зависит от расстояния до сервера, поэтому одной проверки из офиса мало.
| Инструмент | Что показывает |
|---|---|
| Chrome DevTools → Network → Timing | Строка «Waiting for server response» для конкретного запроса |
| PageSpeed Insights | Полевые данные реальных пользователей Chrome, если трафика достаточно |
| WebPageTest | Тест из выбранного города и браузера, разбивка по этапам |
| Search Console → Статистика сканирования | Среднее время ответа сервера для Googlebot |
| curl | Быстрая проверка из любой точки, где есть терминал |
curl -o /dev/null -s -w "dns %{time_namelookup} tls %{time_appconnect} ttfb %{time_starttransfer}\n" https://example.com/
Проверяйте из тех регионов, где ваши пользователи: Ташкент, Алматы, Москва — и отдельно из Европы или США, если там сервер или часть аудитории. Сравнивайте холодный запрос (кэш пуст) и тёплый.
Как сократить время ответа
1. Кэширование
- Кэш целых страниц на сервере или в обратном прокси (Nginx, Varnish) — самый сильный рычаг для страниц, одинаковых для всех.
- Кэш объектов (Redis, Memcached) для тяжёлых вычислений и частых запросов.
- Заголовки
Cache-Controlсs-maxageиstale-while-revalidate, чтобы CDN отдавал кэш и обновлял его в фоне.
2. CDN
CDN отдаёт ответ с ближайшего к пользователю узла. Важно кэшировать не только статику, но и HTML там, где это возможно. Проверьте, есть ли у выбранного CDN точки присутствия рядом с вашей аудиторией.
3. Оптимизация базы данных
- Включите лог медленных запросов и смотрите план выполнения (
EXPLAIN). - Добавьте индексы под частые условия
WHEREиJOIN. - Уберите проблему N+1, когда для списка делается отдельный запрос на каждый элемент.
- Используйте пул соединений, чтобы не открывать соединение на каждый запрос.
4. Статическая генерация
Страницы, которые редко меняются (блог, услуги, карточки товаров), выгоднее генерировать заранее — SSG или инкрементальная регенерация. Тогда сервер отдаёт готовый HTML вместо рендеринга на каждый запрос.
5. Хостинг рядом с пользователями
Физическое расстояние добавляет задержку к каждому этапу соединения. Если аудитория в Узбекистане и СНГ, сервер в Ташкенте или в соседнем регионе обычно отвечает быстрее, чем в Северной Америке. Учтите и требования к локализации персональных данных, если сайт их хранит.
6. Мелкие, но заметные вещи
- Уберите лишние редиректы (http → https → www → слеш).
- Включите HTTP/2 или HTTP/3 и современный TLS.
- Не делайте блокирующих запросов к внешним API во время рендеринга.
Типичные ошибки
- Измерять только с локальной машины рядом с сервером.
- Оптимизировать картинки, когда главная задержка — на сервере.
- Ставить CDN, но не кэшировать HTML.
- Сбрасывать весь кэш при любом изменении в админке.