Архитектура фронтенда
Code splitting: почини waterfall
Читать про over-splitting — не то же самое, что вытащить страницу из waterfall. Возьми реальное приложение, загони его в failure mode на троттленном 4G, затем переархитектурь граф чанков по дереву решений юнита — измеряя на каждом шаге, а не доверяя анализатору.
Преврати ментальную модель юнита в воспроизводимый инженерный цикл: профилируй граф чанков в полевых условиях, найди waterfall и over-split’ы, разбей по маршрутам, отсрочь только тяжёлые не-на-первой-отрисовке компоненты, добавь правильные resource hints, стабилизируй vendor-чанк и подтверди выигрыш Core Web Vitals числами до/после.
Возьми многомаршрутное SPA (своё или собери небольшое), которое либо переразбито в request waterfall, либо недоразбито в один гигантский бандл, и переархитектурь его граф чанков так, чтобы LCP на троттленном 4G упал ниже 2.5s, а CLS ниже 0.1 — доказывая каждое изменение измерениями, а не анализатором бандла.
- Таблица до/после, замеренная в идентичных условиях троттленного 4G: LCP, CLS, INP, байты JS начального маршрута и число последовательных запросов чанков на критическом пути.
- Network waterfall после изменения показывает критичные чанки, загруженные параллельно документу (через preload), а не обнаруженные последовательно, с видимо уменьшенной глубиной waterfall.
- LCP ниже 2.5s и CLS ниже 0.1 на троттленном 4G, и ни один компонент над сгибом не мигает fallback'ом Suspense.
- Diff двух билдов, доказывающий, что content-hashed URL vendor-чанка не изменился после тривиальной правки кода приложения, плюс абзац с указанием, какой рычаг починил каждую проблему и почему.
- Добавь слой route-prefetch-on-hover на всю навигацию и измерь улучшение click-to-interactive на предзагруженных маршрутах против холодных.
- Протестируй сжатие чанкинга: разбей один общий ресурс двумя способами (несколько крупных vs много крошечных чанков) и сравни суммарно переданные (compressed) байты, чтобы количественно оценить штраф сжатия от over-splitting.
- Добавь CI-гейт Lighthouse-CI, который прогоняется на троттленном 4G и роняет билд, если LCP, CLS или JS начального маршрута регрессирует за бюджет.
- Повтори эксперимент под HTTP/1.1 против HTTP/2 и задокументируй, как меняется стоимость waterfall, подтверждая, что multiplexing помогает параллельным запросам, но не последовательной цепочке обнаружения.
Это цикл, который ты будешь гонять на каждом реальном решении по разбивке: сначала измеряй в полевых условиях (троттленный 4G, а не анализатор), классифицируй каждый чанк как маршрут / тяжёлое-отсроченное / over-split, разбей по маршрутам по умолчанию, отсрочь только тяжёлые не-на-первой-отрисовке виджеты, добавь preload для критичного и prefetch для вероятно-следующего и стабилизируй vendor-чанк, чтобы деплои не сбрасывали кэш. Доказать выигрыш LCP и CLS числами до/после на игрушечном приложении делает прод-версию мышечной памятью — граф чанков это бюджет, который ты проектируешь, а не число, которое минимизируешь.