Для чего нужно разделение кода

Разделение кода, или code splitting, означает, что приложение собирают не в один большой JavaScript-файл, а в несколько чанков. Браузер получает основной код для старта, а остальные части загружает тогда, когда они действительно нужны.

На интервью не останавливайтесь на фразе "для производительности". Скажите конкретнее: вы уменьшаете initial JavaScript, ускоряете загрузку первого экрана, снижаете время на скачивание, парсинг и выполнение кода. Это особенно заметно в больших SPA, где пользователь при первом визите не пользуется всеми разделами сразу.

Важно сразу добавить ограничение. Code splitting не удаляет код и не делает его бесплатным. Он переносит загрузку части кода на более поздний момент, поэтому нужно думать о fallback, предзагрузке и метриках.

Хорошие кандидаты на отдельный чанк обычно имеют два признака. Они тяжелые и не нужны всем пользователям сразу. Например, админка, страница отчетов с графиками, WYSIWYG-редактор, карта, календарь, платежный виджет или большой onboarding-flow.

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

Короткий пример можно показать через маршрут или тяжелую страницу. Важно не просто написать import(), а показать состояние загрузки.

import { lazy, Suspense } from "react";
import { Route, Routes } from "react-router-dom";
import { HomePage } from "./pages/HomePage";

const ReportsPage = lazy(() => import("./pages/ReportsPage"));

export function AppRoutes() {
  return (
    <Routes>
      <Route path="/" element={<HomePage />} />
      <Route
        path="/reports"
        element={
          <Suspense
            fallback={
              <div role="status" aria-live="polite">
                Загружаем раздел...
              </div>
            }
          >
            <ReportsPage />
          </Suspense>
        }
      />
    </Routes>
  );
}

Такой код говорит сборщику, что ReportsPage можно вынести в отдельный чанк. Пользователь не скачивает код отчетов при открытии главной страницы, если раздел отчетов ему пока не нужен. Fallback с role="status" помогает не оставлять пользователя без сигнала во время загрузки.

Но пример будет неполным без риска. При первом переходе на отчеты браузеру нужно скачать новый файл. Поэтому для вероятных переходов используют preload или prefetch, а для ошибок загрузки добавляют error boundary или понятный сценарий повторной попытки. Без этого при сетевой ошибке или деплое со старыми ссылками пользователь может получить белый экран.

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

На интервью можно сказать так:

Я бы не дробил приложение вслепую. Сначала посмотрел бы, какие части попадают в initial bundle, какие из них не нужны для первого экрана, и вынес бы крупные редкие сценарии. Потом проверил бы не только размер бандла, но и задержку при первом переходе к ленивому маршруту.

Такой ответ звучит сильнее, чем просто "нужно разделять код, чтобы было быстрее". Вы показываете критерий выбора и способ проверки результата.

Не оценивайте code splitting только по количеству файлов после сборки. Файлов может стать больше, и это нормально, если пользователь раньше получает нужный интерфейс и не скачивает лишний JavaScript.

Что можно проверить:

• размер initial JavaScript;
• сетевой водопад в Chrome DevTools;
• coverage, чтобы увидеть неиспользуемый код на первом экране;
• LCP, TBT или INP в лабораторных и реальных измерениях;
• задержку при первом переходе к ленивому маршруту;
• поведение на cold cache и слабой сети.

Практический вывод: хорошее разделение кода видно не только в bundle analyzer. Оно должно улучшать конкретный пользовательский путь, а не просто красиво выглядеть в отчете сборки.

В современных проектах разделение кода обычно поддерживается сборщиком и фреймворком. Webpack, Rollup и Vite понимают динамический import() и могут создавать отдельные чанки. React, Vue, Next.js и другие инструменты дают свои удобные способы ленивой загрузки маршрутов и компонентов.

Для интервью достаточно назвать принцип, а не перечислять все настройки. Если вас спрашивают глубже, можно сказать, что ручные точки разделения делают через dynamic import, а общие зависимости бандлер может выносить в отдельные vendor-чанки. В SSR-проектах еще проверяют, что ленивый компонент не обращается к window или document во время серверного рендера и не создает hydration mismatch.

Но это всегда нужно проверять на конкретной сборке, потому что автоматическое разбиение не гарантирует лучший UX.