Архитектура фронтенда
Code splitting: свободное припоминание
Припоминание сильнее перечитывания. На каждый промпт проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет дерево решений по разбивке.
Восстанови спину юнита — почему разбивка это латентностный размен, правило «маршрут vs компонент», request waterfall, ловушку кэша vendor-чанка и разделение preload/prefetch — не подглядывая в обзор.
- 01Почему code splitting — это латентностный размен, а не бесплатное сокращение размера?
- 02Почему route-based splitting — безопасный дефолт, а разбивка по компонентам — скальпель?
- 03Объясни request waterfall и почему HTTP/2 multiplexing от него не спасает.
- 04Как изоляция vendor-чанка помогает кэшированию и как она случайно даёт обратный эффект на каждом деплое?
- 05Когда использовать rel=preload (modulepreload), а когда rel=prefetch для чанка?
- 06Почему lazy-загрузка компонента над сгибом — классическая продакшен-авария и какие Core Web Vitals она атакует?
Если ты смог восстановить каждый ответ по памяти, ты держишь спину юнита: разбивка меняет одну загрузку на много запросов, поэтому метрика — добавленные последовательные round trip’ы, а не сэкономленные байты. Route-based splitting — ограниченный, высокорычажный дефолт; разбивка по компонентам — скальпель только для тяжёлых, не-на-первой-отрисовке виджетов. Именно waterfall проигрывает на мобиле, и HTTP/2 его не спасает; content-hashed vendor-чанк с вынесенным runtime держит кэши тёплыми между деплоями; а preload защищает критичные сейчас чанки, prefetch прогревает вероятно-следующие — и никогда не lazy-грузи над сгибом.