Как измеряется нагрузка на проект
Что проверяют
Различаете ли вы две разные «нагрузки»: сколько запросов выдерживает то, что отдаёт фронтенд, и насколько тяжело приложение для устройства пользователя. Следом обычно спрашивают, чем лабораторные замеры отличаются от данных реальных пользователей и какие цифры вы считаете нормой.
Как отвечать
Сначала уточните, о чём речь, и разложите ответ на два слоя.
Нагрузка на серверную часть (SSR, BFF на Node.js, CDN):
- RPS и одновременные пользователи: сколько запросов в секунду приходит и сколько сервер держит до деградации;
- задержка по перцентилям: p95 и p99 времени ответа, а не среднее, которое прячет медленный хвост;
- доля ошибок и ресурсы: ответы 5xx, CPU, память процесса, попадания в кэш CDN.
Меряют нагрузочными тестами (k6, JMeter, Gatling) и мониторингом в проде (Grafana, APM-агенты).
Нагрузка на клиент:
- Core Web Vitals: LCP (до 2,5 с), INP (до 200 мс, в 2024 году заменил FID), CLS (до 0,1), всё по 75-му перцентилю реальных визитов;
- главный поток: длинные задачи дольше 50 мс и суммарная блокировка TBT в Lighthouse;
- вес ресурсов: размер JS после сжатия, число запросов, бюджет на бандл через
size-limitили анализатор сборки.
Важно разделять лабораторные данные (Lighthouse, WebPageTest, вкладка Performance в DevTools) и полевые: CrUX, библиотека web-vitals, RUM-мониторинг вроде Sentry. Лаборатория воспроизводима и нужна для отладки, поле показывает, что видят люди на слабых телефонах и медленной сети.
Где спотыкаются
Называют TTI и FID как актуальные метрики. FID уже не входит в Core Web Vitals, а TTI убран из отчёта Lighthouse, и ответ сразу выглядит устаревшим.
Опираются на одно число из Lighthouse на мощном ноутбуке. Без троттлинга и без полевых данных это оценка вашей машины, а не пользователей.
Сводят нагрузку к поведенческой аналитике: клики, отказы и конверсия важны для продукта, но про производительность и ёмкость системы они ничего не говорят.