Архитектура фронтенда
Code splitting: тест с множественным выбором
Суть Синтез по всему юниту code splitting в формате множественного выбора — латентностный размен, разбивка по маршрутам vs по компонентам, request waterfall, кэширование vendor-чанка и resource hints.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Ни один не просит определение — каждый отражает решение по разбивке, которое ты принимаешь под реальным бюджетом латентности, где неверный выбор деградирует LCP или заставляет заново скачивать React на каждом деплое.
Цель
Убедись, что связываешь латентностный размен, правило «маршрут vs компонент», request waterfall, кэширование vendor-чанка и resource hints — синтез, к которому вёл обзор.
Викторина
Completed
Команда оборачивает каждую панель дашборда в React.lazy. Анализатор показывает 40 чанков, ни один больше 12 KB, но полевой LCP на 4G деградирует с 2.3s до 4.1s. Что доминирующая причина?
Heads-up Разбивка не добавила кода — те же модули теперь в большем числе файлов. Регрессия — это латентность round trip'ов от последовательного waterfall плюс потеря сжатия, а не лишние байты.
Heads-up Стоимость парсинга масштабируется с суммарным объёмом байт, а не числом файлов. Доминирующая стоимость на 4G — последовательная латентность round trip, поэтому тот же билд нормален на десктопе.
Heads-up Анализатор прав по размеру. Меньше-на-диске не равно быстрее-по-сети, когда каждый чанк — это запрос, а запросы зависимы — это вся посылка юнита.
Викторина
Completed
Можно разбить ровно одну вещь на странице. Какой кандидат — самый высокорычажный и низкорисковый split?
Heads-up Разбивка компонента над сгибом покупает round trip и спиннер, экономя почти ничего, бьёт по LCP и рискует CLS. Мелкий контент над сгибом отгружай в чанке маршрута.
Heads-up Over-splitting дробит граф в последовательный waterfall и убивает сжатие. Правило — разбивать тяжёлое и не-на-первой-отрисовке, а не всё подряд.
Heads-up React нужен для первой отрисовки, поэтому его отсрочка лишь добавляет round trip на критический путь. React место в долго-кэшируемом vendor-чанке, а не за lazy-границей.
Викторина
Completed
Ревьюер заявляет: «HTTP/2 multiplexing делает бандлинг устаревшим, так что дроби как угодно гранулярно». В чём он неправ?
Heads-up Multiplexing помогает только запросам, о которых браузер знает одновременно. Waterfall последователен по построению, а мелкие файлы хуже сжимаются — обе стоимости переживают HTTP/2.
Heads-up HTTP/2 как раз мультиплексирует много параллельных запросов по одному соединению — эта часть верна. Изъян — в последовательном обнаружении и потере сжатия, а не в параллелизме.
Heads-up Не всегда — route-based splitting всё равно выигрывает, держа начальный маршрут лёгким. Суть в том, чтобы найти середину: n чанков, где n много меньше числа модулей, а не дробить и не отгружать один гигантский файл.
Викторина
Completed
Вернувшиеся пользователи заново скачивают React на каждом деплое, хотя зависимости не менялись. Самая вероятная причина?
Heads-up Это симптом плохого чанкинга, а не правило дизайна. Корректно изолированный content-hashed vendor-чанк остаётся в кэше между деплоями, пока его байты не меняются.
Heads-up Кэш ключуется по URL. С content-hashed именами неизменный vendor-чанк сохраняет тот же URL и остаётся в кэше; hash меняется, потому что в него протекло что-то волатильное.
Heads-up Размер тут не блокирует кэширование. Дефект — волатильность хэша: вынеси runtime в отдельный крошечный файл, чтобы байты vendor оставались стабильными между деплоями.
Викторина
Completed
Интерактивный viewer на 180 KB лежит под сгибом и открывается, только когда пользователь до него прокрутит. Лучшая стратегия загрузки для аудитории на 4G?
Heads-up Это кладёт 180 KB, до которых большинство не прокрутит, на критический путь LCP, раздувая парсинг и TTI для всех ради одного спиннера. Тяжёлый, под-сгибом, гейтнутый взаимодействием виджет — канонический кандидат на отсрочку.
Heads-up Разбивка шапки над сгибом добавляет round trip и спиннер к контенту первой отрисовки и строит последовательный waterfall. Разбивай тяжёлое отсроченное; не дроби страницу.
Heads-up iframe — это отдельный документ со своим JS-контекстом и стоимостью загрузки, а не инструмент стратегии чанков. Viewer — компонент: разбей его как компонент и упреди waterfall через prefetch.
Викторина
Completed
В чём практическая разница между rel='preload' (или modulepreload) и rel='prefetch' для чанков?
Heads-up Приоритет и намерение различаются. preload — высокий приоритет для чанка, нужного текущей странице; prefetch — idle-приоритет, спекуляция о будущей навигации. Prefetch для критического чанка оставит его обнаруженным слишком поздно.
Heads-up Оба применимы к script/module-чанкам (modulepreload для ES-модулей). Разделение — критично-для-текущей-страницы vs вероятно-будущее, а не по типу ресурса.
Heads-up Ни один не блокирует рендеринг — оба это hints. prefetch — низкоприоритетная спекуляция; preload — высокоприоритетная текущая нужда. Перевёрнуто относительно утверждения.
Итог
Сквозная линия юнита — одно дерево решений: разбивка это латентностный размен, а не бесплатное сокращение размера, поэтому вопрос всегда в том, сколько последовательных round trip’ов ты добавил на критический путь. Разбивай по маршрутам по умолчанию (ограниченный waterfall, дефолт фреймворка); разбивай компонент только если он тяжёлый и не на первой отрисовке; никогда не разбивай мелкий контент над сгибом. Именно waterfall, а не число байт, проигрывает на 4G, и HTTP/2 его не спасает. Защити кэширование content-hashed vendor-чанком с вынесенным runtime, и используй preload для критичных сейчас чанков, prefetch — для вероятно-следующих навигаций.