Краткий ответ
Чтобы определить источник задержки, разделите получение документа, загрузку API и работу браузера. Высокий TTFB включает не только выполнение серверного кода; сопоставьте сетевые этапы с внутренними измерениями, проверьте кеш и нагрузку. Быстрый ответ сервера не исключает задержку отображения и взаимодействия.
Разложите путь до результата
Посетитель ждёт не абстрактный «сервер», а конкретное содержание или действие. Для первого открытия важны документ и отображение, для поиска — запрос и обновление списка, для формы — сохранение и подтверждение. Выберите один медленный сценарий и запишите его границы. Иначе разные участники будут измерять разные интервалы под общим названием скорости.
Начните с сетевого профиля и последовательности запросов. Уточните, какой запрос блокирует результат и выполняется ли работа параллельно или по цепочке. Десять быстрых последовательных API-вызовов могут давать большую общую задержку. Суммарный вес страницы сам по себе не объясняет, почему человек ждёт конкретный экран.
Правильно прочитайте TTFB
web.dev описывает TTFB как время до первого байта с учётом этапов соединения и ответа. Этот показатель не равен только времени SQL-запроса или обработчика приложения. Сопоставьте его с серверными измерениями и условиями сети. Если внутреннее выполнение быстрое, причина может находиться до приложения или в доставке ответа.
| Наблюдение | Следующая проверка | Чего не следует заключать сразу |
|---|---|---|
| Долго приходит документ | Сеть, прокси, выполнение, кеш | Что обязательно медленная база |
| Документ быстрый, API медленный | Конкретная операция и зависимости | Что весь сайт требует нового сервера |
| Все ответы быстрые, экран ждёт | JavaScript, отрисовка, условие показа | Что сеть полностью объясняет проблему |
| Медленно только под нагрузкой | Очереди, ресурсы и конкуренция | Что достаточно уменьшить картинки |
Сохраните корреляцию между клиентским запросом и серверным событием в допустимом диагностическом формате. Не выводите секреты и содержимое пользовательских данных ради удобства измерения. Для публичного отчёта достаточно обезличенной последовательности и интервалов, поддерживающих вывод.
Проверьте кеш как отдельное условие
Первый и повторный запрос могут иметь разную стоимость. Отметьте, где работает кеш: браузер, промежуточный слой, приложение или данные. MDN описывает различие частного и общего HTTP-кеширования и управляющих заголовков. Для персонализированных ответов нельзя включать общий кеш без проверки границ доступа и содержимого.
Не сравнивайте холодный запуск одного варианта с прогретым другого. Если кеш устаревает, предусмотрите правило обновления. Ускорение, которое показывает старую цену или чужой кабинет, не является приемлемым улучшением. Сначала определите корректность данных, затем время их получения.
Найдите серверную операцию
Разбейте обработку на значимые этапы: проверка доступа, чтение данных, внешний вызов, формирование ответа. Ищите измеренную задержку, а не предполагаемую «тяжёлую базу». Для внешнего API нужны тайм-аут и предусмотренное поведение отказа. Если действие не требуется для немедленного результата, рассмотрите фоновую обработку с надёжным контрактом.
Проверьте профиль нагрузки: число одновременных действий, объём данных и частоту. Тест маленькой пустой базы не описывает рабочий каталог. Но и искусственное число запросов без связи с задачей может приводить к ненужной архитектурной сложности. Выберите сценарий и предел, которые бизнес действительно должен поддерживать.
Проверьте работу браузера
Полученный ответ может ждать обработки, большого вычисления или завершения анимации. Для первого экрана используйте разложение LCP, для взаимодействия смотрите событие и работу главного потока. INP относится к отзывчивости, а не просто скорости сети. Нельзя исправить всё одним увеличением серверных ресурсов.
Отдельно проверьте слабое устройство и мобильный экран. Большой объём JavaScript может почти не мешать на рабочем компьютере разработчика, но заметно задерживать пользователя. Сравнивайте одинаковые версии, страницы и условия, сохраняя несколько прогонов. Объяснение различий лаборатории и реального опыта есть в отдельной статье.
Учебный пример медленного списка
Список заказов появляется через несколько последовательных запросов: пользователь, организация, настройки и сами заказы. Каждый ответ относительно быстрый, но цепочка задерживает результат. Команда проверяет, какие зависимости действительно необходимы, и меняет порядок получения данных без нарушения доступа. После этого измеряет тот же сценарий и проверяет пустые и ошибочные состояния.
Если основная задержка остаётся в запросе заказов, следующий шаг — его внутренний профиль. Не следует одновременно менять сервер, базу и весь интерфейс без возможности понять вклад. Результатом диагностики становится конкретная причина, проверенное изменение и границы измерения, а не общий совет «оптимизировать всё».
Как сравнивать сервер с холодным и прогретым кэшем
Запишите два отдельных сценария и не смешивайте их результаты. Прогретый ответ может быть быстрым, а первая генерация страницы — дорогой из-за базы или внешнего API. Проверьте также срок актуальности данных и действие после изменения материала.
Для персональных страниц сначала определите безопасность кэширования: ускорение не должно показывать одному клиенту данные другого. Документация HTTP-кэширования помогает различать правила хранения и повторной проверки. При измерении фиксируйте сеть, редиректы и серверную обработку. Высокий TTFB не всегда вызван вычислениями приложения, поэтому решение о более мощном сервере принимают после локализации задержки, а не по одному скриншоту общего времени загрузки.
Термины из материала
Источники и документация
У каждого документа указана дата последней проверки. Состав функций и интерфейсы сервисов могут меняться. Ссылки открываются в новой вкладке.
- web.dev: Time to First Byte Проверено
- MDN: кэширование HTTP Проверено
Применить к вашему проекту
Локализуем задержки между сетью, сервером и интерфейсом и подготовим план ускорения по измерениям.
Обсудить задачу