Технический аудит

Время ответа сервера сайта

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

Опубликовано: · Обновлено:

Время ответа сервера
TTFB и узкие места Auteh · Proprietary — all rights reserved

Время ответа сервера — задержка от запроса браузера до начала получения ответа. В отчётах часто фигурирует как TTFB (time to first byte). Для менеджера сайта формула проще: как быстро инфраструктура и бэкенд начали отдавать документ. Это не «вся скорость сайта», а её старт.

Почему это важно до оптимизации картинок

Цепочка загрузки:

  1. сервер начинает ответ;
  2. браузер получает HTML;
  3. подгружаются стили, скрипты, изображения;
  4. пользователь видит интерфейс.

Если шаг 1 долгий, шаги 2–4 стартуют позже. Идеально сжатые фото не компенсируют секунду молчания кухни. Поэтому TTFB смотрят рядом с Core Web Vitals — особенно с LCP.

Откуда берётся задержка

Типичные источники:

  • слабый или перегруженный хостинг, лимиты тарифа, «шумные» соседи;
  • страница собирается из БД без кэша на каждый запрос;
  • синхронные обращения к внешним API до отдачи HTML;
  • нет полноценного кэша для анонимных посетителей;
  • географическая удалённость сервера от аудитории.

Медленный Wi‑Fi у клиента — не TTFB сервера. Поэтому опирайтесь на инструменты и сравнение страниц, а не только на ощущение с рабочего ноутбука.

Как локализовать проблему

  1. Снимите отчёт скорости по главной и по тяжёлой внутренней странице.
  2. Найдите показатели «время ответа сервера», TTFB, waiting / server.
  3. Сравните простую страницу (контакты, политика) и сложную (каталог, персональный подбор).
  4. Если даже простая молчит — приоритет инфраструктура, кэш, хостинг.
  5. Если простая быстрая, а каталог нет — генерация шаблона, запросы к БД, серверная логика.

Дополнительный контроль: замер из другого региона/сети. Это не замена лаборатории, но ловит вопиющие случаи.

Старт цепочки загрузки

> Внешняя проверка публичной части: Проверить скорость сайта бесплатно

Зоны ответственности

Хостинг / админ: тариф под пики, кэш страниц для гостей, актуальный runtime, мониторинг деградаций.

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

Контент / шаблон: огромные серверно собираемые листинги иногда хуже «дорогого хостинга» без правок. Упростить шаблон каталога может быть дешевле миграции.

Не смешивайте в одном тикете «сделайте быстро». Лучше: «главная до первого ответа заметно медленнее страницы контактов — проверьте кэш и генерацию».

Частые заблуждения

«Самый дорогой хостинг решит». Если URL бьёт базу тысячами запросов, дорогой тариф лишь дороже греется.

«У нас в офисе мгновенно». Тёплый кэш, хороший канал, близость к серверу. Клиент видит другую картину.

«TTFB зелёный — сайт быстрый». Дальше могут ехать мегабайты JS. Время ответа необходимо, но недостаточно.

Разговор с хостером

  1. Точный URL и окно времени, когда тормозит.
  2. Вопрос про CPU, соседей, кэш для гостей.
  3. Сравнение TTFB простой и сложной страницы.
  4. Сопротивление апгрейду «вслепую», если нет кэша на простых URL.

Связка с остальной скоростью

Хороший TTFB на каталоге не отменяет задачу сжать изображения и убрать тройной чат. Плохой TTFB на политике конфиденциальности почти никогда не лечится «оптимизацией JPEG». Держите две очереди: инфраструктура/бэкенд и фронт. Иначе неделя уходит на картинки, а узкое место — холодный бэкенд без кэша.

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

После правок фиксируйте URL, время, инструмент, TTFB до/после и сопутствующие изменения (кэш, тариф, индекс БД). Так вы отделяете прогресс от шума сети.

Не смешивайте инцидент «сайт лежит» с задачей «TTFB 800 мс». Сначала доступность, потом ускорение. В договоре с подрядчиком формулируйте SLA на ключевые URL, а не абстрактное «сайт быстрый».

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

Повторный замер делайте в сопоставимых условиях: тот же URL, похожее время суток, тот же инструмент. Иначе «улучшение» окажется шумом канала.

Итог

Время ответа сервера — старт загрузки. Отделите медленный бэкенд/хостинг от тяжёлого фронта, сравните простые и сложные URL и ставьте задачу тому, кто владеет узким местом. После правок измерьте те же страницы снова — ощущение «вроде шустрее» без цифр обманчиво.

Снаружи: Проверить скорость сайта бесплатно.

Частые вопросы

Это то же самое, что «скорость сайта»?

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

Какое значение считать плохим?

Ориентиры относительны. Если простая страница секунды думает до начала ответа без причины — разбирать. Смотрите динамику до/после и сравнение URL.

Кэш всегда спасает?

Часто ускоряет анонимные и повторные просмотры. ЛК и корзину кэшируют иначе; «включить кэш» без настройки мало.

Поможет ли другой дата-центр?

Если аудитория далеко — иногда да. Если тормозит генерация страницы в коде/БД — переезд без правок слабо поможет.

Что может проверить Auteh

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

Источники