Производительность
Bundle budgets: тест с множественным выбором
Суть Синтез с множественным выбором по юниту bundle budgets — четырёхфазная модель стоимости, рычаги Core Web Vitals, splitting vs compression, налог third-party и enforcement в CI.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов сквозь весь юнит. Каждый отражает решение, которое ты принимаешь на реальном perf-ревью — не определение для пересказа, а вопрос о том, какой рычаг реально двигает число под нагрузкой.
Цель
Подтверди, что умеешь связывать четырёхфазную модель стоимости, пороги Core Web Vitals, иерархию splitting/tree-shaking/compression, налог third-party и enforcement в CI — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Команда A переходит с gzip на brotli и режет transfer с 180 KB до 150 KB. Команда B применяет code-splitting к тому же роуту с 600 KB до 200 KB несжатого. Обе отчитываются о выигрыше в LCP. Кто реально снизил стоимость CPU и почему?
Heads-up Compression — выигрыш только на транспортном уровне. Движок парсит распакованные байты, поэтому стоимость CPU задаётся несжатым размером и brotli её не меняет.
Heads-up Brotli — это encoding; V8 получает сырые распакованные байты и парсит их одинаково независимо от способа доставки. Никакого ускорения парсинга.
Heads-up При быстром TTFB LCP свыше 2.5 с обычно означает, что JS parse/execute блокирует отрисовку. CPU — ровно то узкое место, на которое нацелен юнит.
Викторина
Completed
Страница грузится за 800 мс на M-ноутбуке разработчика, но висит пустой ~8 с на mid-range Android. TTFB 70 мс на обоих. Что доминирующая причина?
Heads-up TTFB 70 мс на обоих, то есть сеть быстро доставила первый байт. Разрыв — это CPU-bound parse/compile/execute, не download.
Heads-up TTFB идентичен — 70 мс. Сервер не переменная; переменная — CPU клиента.
Heads-up Compression влияет на байты download. Пустой экран 8 с при быстром TTFB — это CPU, парсящий/исполняющий большой несжатый bundle.
Викторина
Completed
У команды P75 LCP — Poor, а P75 CLS — Good. Они режут bundle роута с 700 KB до 200 KB. LCP и INP улучшаются; CLS почти не двигается. Почему это ожидаемый исход?
Heads-up CLS измеряет визуальную стабильность (доля viewport × дистанция сдвига), а не стоимость CPU. Срез байт не резервирует место под layout.
Heads-up Неизменный CLS — это корректно: фикс CLS — это images с размерами, зарезервированное место и font-display: swap — ничего из этого срез bundle не трогает.
Heads-up CLS — это вопрос дисциплины layout на клиенте; один SSR не чинит media без размеров или поздние шрифты.
Викторина
Completed
Разработчик пишет `import { debounce } from 'lodash'`, и анализатор показывает 70 KB, а не 2 KB. На своём пакете он уже выставил `sideEffects: false`. В чём реальная причина и фикс?
Heads-up `sideEffects: false` на твоём пакете лишь помечает твой код shakeable; он не делает чужой CJS-модуль статически анализируемым.
Heads-up Минификация переименовывает и срезает пробелы; она не удаляет неиспользуемые экспорты CJS. Tree-shaking требует статически анализируемого ESM.
Heads-up Compression ужимает transfer этих байт, но они всё равно поставляются, парсятся и исполняются. Фикс — не включать их.
Викторина
Completed
Команда спринт режет первопартийный bundle с 800 KB до 350 KB; через месяц data-команда добавляет через GTM Segment, Hotjar и Intercom (~450 KB), и выигрыш стёрт. Какой контроль поймал бы это до релиза?
Heads-up size-limit меряет чанки в выводе твоей сборки. Скрипты, внедрённые GTM, грузятся с внешних доменов в рантайме и не попадают в твой bundle, так что gate их не видит.
Heads-up Ты не контролируешь исходники вендоров и не можешь их shake; вендоры поставляют полный набор фич. Tree-shaking — это первопартийный механизм только для ESM.
Heads-up Compression режет transfer, а не parse/execute на main thread, который навязывают скрипты вендоров. Нужен контроль governance, а не compression.
Викторина
Completed
Lighthouse CI на каждом PR показывает P75 LCP 2.1 с; production RUM показывает 4.8 с P75 на мобильных для того же роута. Как это читает сеньор?
Heads-up Разрыв синтетика-vs-поле в 2×+ нормален и отражает реальное разнообразие устройств/сетей, а не ошибку конфигурации.
Heads-up Lighthouse дёшево ловит регрессии от кода до merge; RUM ловит то, что синтетика упускает после деплоя. Они покрывают разные классы отказов.
Heads-up То, что RUM вскрыл худшее реальное число — повод резать байты, а не принимать регрессию за baseline.
Итог
Сквозная линия юнита — одно дерево решений: байты равны четырём фазам CPU (download — это сеть, parse/compile/execute — CPU юзера), поэтому реальные рычаги сокращают поставляемые байты — сначала splitting, затем tree-shaking, с compression как финишёром только для транспорта. Core Web Vitals количественно меряют стоимость (LCP/INP двигаются с JS, CLS — нет). Third-party скрипты — тихий убийца бюджета, которого первопартийные gate не видят, потому им нужен свой budget плюс CSP. И ничто не держится без enforcement: size-limit в CI, RUM в production, храповик budget-raise против дрейфа.