Code splitting через React.lazy: грузим экран, а не приложение

Механика: компонент, приостановленный до прибытия своего кода

Прежде чем тянуться к React.lazy, стоит понять, что браузер делает при динамическом импорте: вспышка fallback в дев-режиме — это видимая поверхность сетевого round trip, и именно это знание определяет, куда ставить каждую границу.

React.lazy(() => import("./Editor")) возвращает компонент, который вы рендерите как любой другой. При первой попытке рендера срабатывает загрузчик: import() велит бандлеру вырезать модуль (и всё, что импортирует только он) в отдельный чанк, который в этот момент скачивается по сети. Пока промис в полёте, ленивый компонент приостанавливается — ближайшая граница Suspense показывает свой fallback, — а когда модуль резолвится, React рендерит его экспорт по умолчанию. Модуль скачивается и выполняется один раз; последующие рендеры синхронны.

import { lazy, Suspense } from "react";

const Editor = lazy(() => import("./Editor"));            // нужен default export

// Обход для именованных экспортов: перекраиваем модуль в загрузчике
const Chart = lazy(() =>
  import("./charts").then((m) => ({ default: m.RevenueChart }))
);

function ReplyPanel({ open }) {
  return (
    <Suspense fallback={<EditorSkeleton />}>
      {open && <Editor />}
    </Suspense>
  );
}

Два правила объявления спасают от самострелов. Объявляйте ленивые компоненты на верхнем уровне модуля — lazy(), созданный внутри рендера, порождает новый тип компонента на каждый рендер, и React размонтирует и заново монтирует поддерево (потеря стейта, повторная загрузка) при каждом апдейте родителя. И lazy резолвит только default export; для именованных экспортов переотображайте модуль в загрузчике, как выше. Более глубокий смысл: каждая граница lazy — промис, резолвящийся за сетевое время, поэтому её размещение — архитектурное решение, а не синтаксическое.

Где резать: сначала роуты, потом компоненты

Самый ценный разрез — роут: пользователи одного экрана не получают ни байта кода остальных, граница чанка совпадает с естественным состоянием загрузки (навигацией), и роутеры современных фреймворков делают это по умолчанию. Первый фикс из истории — отделение чекаута от админских графиков и markdown-библиотек — был чистым роут-сплиттингом и снял бандл с 612 до 240 КБ gzip. Якорь для бюджета: 300 КБ сжатого JS — это примерно 1 МБ кода на парсинг и исполнение, то есть секунды CPU на среднем телефоне уже после окончания скачивания; сплиттинг экономит время парсинга, а не только байты.

Покомпонентный сплиттинг окупается на вещах тяжёлых и условных: модалки, rich-text-редакторы, панели графиков, всё ниже сгиба или за кликом. Тест конкретен: откройте анализатор бандла и посмотрите фактический размер чанка. Ленивая загрузка дейтпикера на 6 КБ не покупает почти ничего, а стоит запроса плюс вспышки fallback; ленивая загрузка редактора на 280 КБ, который открывают 4% сессий, — ради этого всё и затевалось. Режим отказа — водопад: ленивый компонент, чей чанк после загрузки рендерит другой ленивый компонент, создаёт последовательные round trip, потому что второй запрос невозможно обнаружить, пока первый чанк не приехал и не отрендерился. При RTT 200 мс три вложенные границы — это 600+ мс чистой задержки до какой-либо работы рендера. Держите границы соседями (один Suspense, чанки качаются параллельно), а не предками.

Прогрев по намерению: потратьте задержку до клика

Задержке ленивого чанка не обязательно начинаться в момент рендера. Динамический import() — просто вызов функции, прогревающий кеш модулей: вызовите его заранее, и к моменту, когда React приостановится, промис может быть уже зарезолвлен:

const loadEditor = () => import("./Editor");      // общий загрузчик = общий кеш
const Editor = lazy(loadEditor);

<button
  onMouseEnter={loadEditor}                        // намерение: фора ~200-300 мс
  onFocus={loadEditor}
  onClick={() => setOpen(true)}
>
  Ответить
</button>

Зазор между hover и кликом — несколько сотен миллисекунд, на приличном соединении это зачастую вся загрузка чанка: вспышка fallback превращается в несобытие. Идея обобщается: прогревать чанки роутов, когда ссылка входит во viewport (IntersectionObserver), после первой отрисовки — для самого вероятного следующего роута, или через requestIdleCallback для низкоприоритетного прогрева. Браузерный эквивалент — <link rel="modulepreload"> для статически известных чанков. Компромисс: прогрев тратит трафик на предсказания — пере-прогрев на лимитированном мобильном соединении заново собирает монолит по одному спекулятивному чанку, поэтому привязывайте его к настоящим сигналам намерения (hover, focus, viewport), а не грейте всё подряд.

SSR и цикл измерения

Две эксплуатационные заметки закрывают тему. Серверный рендеринг: на сервере нет «потом» — классический React.lazy исторически не работал в SSR, отчего экосистема вырастила loadable-components; современный стриминговый SSR React 18+ плюс роутовый сплиттинг на уровне фреймворка решают это за вас, но ограничение гидратации остаётся: клиент должен скачать тот же чанк, прежде чем сможет гидратировать поддерево, так что медленный чанк — это серверный HTML, который видим, но мёртв; проектируйте fallback так, чтобы пользователи не кликали в неживой UI. Измерение: сплиттинг — игра в байты, и проверять его надо в байтах. Анализатор бандла (rollup-plugin-visualizer, webpack-bundle-analyzer) показывает, действительно ли разрез вынес библиотеку из входного чанка — один случайный статический import редактора где угодно во входном графе тихо склеивает чанк обратно, и ловится эта регрессия именно в анализаторе. Отслеживайте размер входного чанка в CI: эта метрика деградирует по одному невинному импорту за раз.