Как оптимизировать первую загрузку при увеличении размера бандла приложения?

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

Умеете ли вы начинать с измерений, а не с перечня техник, и понимаете ли, что на первую загрузку влияет не только размер JS. Следом обычно спрашивают, какие метрики вы смотрите и чем код-сплиттинг может навредить.

Как отвечать

Сначала измерить:

• метрики: LCP, INP и CLS из Core Web Vitals, плюс TTFB и объём JS на старте. В лаборатории Lighthouse и вкладка Performance с троттлингом CPU, в поле библиотека web-vitals или RUM;
• состав бандла: webpack-bundle-analyzer, rollup-plugin-visualizer для Vite, source-map-explorer. Ищете тяжёлые библиотеки и дубли разных версий одного пакета.

Потом уменьшать то, что грузится на старте:

• разбиение по маршрутам: динамический import(), React.lazy с Suspense, тяжёлые редакторы, графики и карты грузятся по требованию;
• tree shaking: ESM-сборки библиотек, sideEffects: false в package.json, импорт конкретных функций. Тяжёлое меняется на лёгкое: moment на date-fns или Day.js, lodash на отдельные функции или нативный код;
• полифилы: современный browserslist убирает транспиляцию и полифилы, которые нужны только старым браузерам;
• доставка: Brotli на сервере или CDN, файлы с хэшем в имени и Cache-Control: immutable, modulepreload для критичных чанков;
• рендер: SSR или статическая генерация показывают контент до загрузки JS, а стриминг отдаёт страницу частями. Для LCP-картинки fetchpriority="high" и никакого loading="lazy".

Закрепите результат бюджетом: size-limit или проверка в CI, которая падает, если стартовый чанк вырос.

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

Отвечают «минификация и gzip». Современные сборщики минифицируют по умолчанию, это не оптимизация, а базовая гигиена.

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

Измеряют на своём мощном ноутбуке с быстрым интернетом. Узкое место у пользователя часто не сеть, а разбор и выполнение JS на слабом телефоне.