Использовал ли утилиты для анализа бандла

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

Работали ли вы с размером бандла руками или только слышали про код-сплиттинг. Интервьюер ждёт историю: какой инструмент, что нашли, что сделали и как измерили результат. Следом обычно спрашивают, как не дать бандлу снова разрастись.

Как отвечать

Назовите инструменты под свой сборщик:

• webpack-bundle-analyzer: карта модулей для webpack, показывает размеры stat, parsed и gzip;
• rollup-plugin-visualizer: то же для Vite и Rollup;
• source-map-explorer: разбор готового бандла по source maps, от сборщика не зависит;
• Statoscope: анализ stats webpack, сравнение двух сборок, поиск дублей;
• Bundlephobia: сколько весит пакет ещё до установки;
• size-limit: бюджет размера в CI, сборка падает, если бандл вырос сверх лимита;
• вкладка Coverage в Chrome DevTools: сколько загруженного кода реально выполнилось.

Дальше расскажите, что обычно находится: две версии одной библиотеки в дереве зависимостей, moment со всеми локалями, lodash целиком вместо точечных импортов или lodash-es, CommonJS-пакет, который не проходит tree shaking, полный набор иконок ради пяти штук, тяжёлый редактор или графики в основном чанке. И как это лечится: динамический import() и React.lazy, замена библиотеки на лёгкую (date-fns, dayjs), sideEffects: false в package.json, вынос редких экранов в отдельные чанки.

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

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

Сравнивают stat size, то есть размер исходников до минификации. Пользователь качает gzip или brotli, и цифры там совсем другие.

Называют «минус 30%» без объяснения, как мерили и на какой странице. Интервьюер сразу спросит про метод.

Оптимизируют килобайты там, где тормозит не загрузка, а долгие задачи на главном потоке. Уменьшение бандла само по себе INP не улучшает.