Быстрый на тестах, медленный у пользователей: где frontend теряет производительность

Хороший балл — начало проверки

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

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

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

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

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

Проверяйте production-сборку. Запишите сценарий в панели Performance браузера и отметьте промежуток между действием и видимым результатом. Повторите его несколько раз в одинаковых условиях: единичный удачный запуск легко принять за улучшение.

Замедление CPU помогает проявить проблему, но не заменяет проверку на доступном реальном телефоне. Начните с устройства, на котором задержка уже воспроизводится, и сохраните исходную запись для сравнения.

Разделить ожидание ответа и задержку реакции

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

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

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

Выбрать исправление по записи, а не по привычке

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

Другой вариант: фильтрация быстрая, но в DOM одновременно появляются тысячи карточек. Тогда стоит проверить пагинацию или виртуализацию. У виртуализации есть цена: нужно продумать фокус, возврат к позиции и поиск по странице. Для обычного каталога постраничная выдача может оказаться проще.

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

Проверить улучшение на том же действии

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

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

Результат работы лучше описывать через устранённую задержку и условия проверки. Честное «перестал зависать выбор фильтра на таком устройстве и объёме данных» полезнее обещания, что весь сайт теперь быстрый.

• Есть записанный сценарий и исходное измерение.
• Понятно, где возникает задержка: сеть, обработка или отрисовка.
• Изменение проверено на production-сборке в сопоставимых условиях.
• Первое использование, повторные действия и возврат назад работают корректно.
• После выпуска проверены данные реальных посещений, если их достаточно.