Какие методы используются для оценки оптимальности бандла с точки зрения производительности страниц

Что проверяют

Отличаете ли вы размер бандла от его влияния на пользователя. Мегабайт лениво загружаемого кода может никому не мешать, а 150 КБ в критическом пути ухудшат LCP и INP. Следом обычно спрашивают, как не дать бандлу снова разрастись после оптимизации.

Как отвечать

Разложите ответ на три уровня.

Состав бандла:

• анализаторы: webpack-bundle-analyzer, rollup-plugin-visualizer для Vite, source-map-explorer. Ищете крупные зависимости, одну библиотеку в двух версиях, целиком затянутые пакеты ради одной функции;
• три размера: исходный, минифицированный и сжатый gzip или Brotli. По сети идёт сжатый, а парсит и исполняет браузер распакованный, и на слабом телефоне это дороже загрузки;
• Coverage в Chrome DevTools: доля кода, который загрузили, но не выполнили при открытии страницы.

Лабораторные замеры:

• Lighthouse и вкладка Performance: Total Blocking Time, long tasks дольше 50 мс, время на выполнение скриптов. Lighthouse по умолчанию эмулирует медленный мобильный, так и задумано.

Реальные пользователи:

• Core Web Vitals: LCP до 2,5 с, INP до 200 мс, CLS до 0,1 по 75-му перцентилю. Данные берут из CrUX и PageSpeed Insights или собирают сами библиотекой web-vitals.

Закончите контролем: бюджеты через size-limit или Lighthouse CI в пайплайне, performance.hints в webpack. По итогам анализа применяют разбиение кода по маршрутам, динамический import(), tree shaking с корректным полем sideEffects в package.json, замену тяжёлых библиотек лёгкими.

Где спотыкаются

Смотрят только на килобайты. Время парсинга и исполнения JS на среднем Android-смартфоне часто важнее времени загрузки.

Путают лабораторные цифры с полевыми. Высокий балл Lighthouse на ноутбуке разработчика не означает хороший INP у пользователей.

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