![\"Учебное](\"/assets/editorial/2022/performance-budget-trend-2022.svg\")
После небольшого изменения команда запускает проверку и получает PASS. Общая сумма работы выросла с 85 до 93 условных единиц, но осталась ниже общего лимита 98. Через несколько дней пользователи замечают, что первый экран стал реагировать позже. В отчёте нет явного нарушения: зелёный итог скрыл рост в одном компоненте.
\nЦена такой ошибки — не только лишние миллисекунды. Команда выбирает неверное действие. Она меняет кеш, сеть или весь маршрут, хотя регрессия появилась в одном участке. Потом сравнения начинают проводиться в разных условиях, а бюджет теряет смысл.
\nТезис: бюджет маршрута должен проверять именованные части до общей суммы. Общий итог нужен как дополнительный ограничитель. Он не отменяет нарушение отдельного компонента.
\nБюджет — это не одно число в конфигурации. Он связывает маршрут, пользовательский сценарий, версию сборки, условия запуска и измеряемые части работы. Эти поля образуют measurement contract. Если контракт не записан, два числа «до» и «после» могут описывать разные события.
\nВ учебной модели ниже четыре поля: documentTicks, styleTicks, scriptTicks и renderTicks. Суффикс Ticks намеренный. Это условные значения локального примера. Они не являются LCP, TTFB, INP, DOMContentLoaded или результатом браузерного профиля.
Настоящий браузер предоставляет другие записи. Например, Navigation Timing описывает навигацию документа, а Resource Timing — загрузку ресурсов. Сначала нужно получить такую запись из поддерживаемого API, затем явно сопоставить её поля с внутренней схемой. Нельзя переименовать произвольное число в LCP и получить от этого реальную метрику.
\nСравнение проходит четыре слоя.
\nДопуск — часть правила, а не скрытая скидка. При limit = 28 и tolerance = 2 порог равен 30. В отчёте нужно сохранить оба значения. Иначе нельзя отличить осознанный допуск от случайно изменённого лимита.
const contract = {\n route: '/checkout',\n scenario: 'open-and-submit',\n conditions: {\n browser: 'chromium',\n viewport: '390x844',\n cache: 'cold',\n network: 'fixed-4g'\n }\n};\n\nconst baseline = {\n documentTicks: 18,\n styleTicks: 15,\n scriptTicks: 26,\n renderTicks: 26\n};\n\nconst candidate = {\n documentTicks: 20,\n styleTicks: 16,\n scriptTicks: 34,\n renderTicks: 23\n};\n\nconst rules = {\n documentTicks: { limit: 20, tolerance: 2 },\n styleTicks: { limit: 18, tolerance: 2 },\n scriptTicks: { limit: 28, tolerance: 2 },\n renderTicks: { limit: 30, tolerance: 2 }\n};В этом примере baseline равен 85, candidate — 93. Общий allowed равен 98, поэтому aggregate проходит. Но scriptTicks вырос с 26 до 34. Его allowed равен 30. Компонент нарушен, значит итоговая проверка должна вернуть FAIL. Разница между 34 и 28 равна 6. Разница между 34 и allowed равна 4. Обе величины полезны, если отчёт называет их однозначно.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Общий PASS, но один участок вырос | Aggregate скрывает component failure | Сравнить каждый field с его allowed | Остановить итог как FAIL и открыть только failed component |
| До и после нельзя честно сравнить | Различаются cache, route, browser или scenario | Сравнить все поля contract | Вернуть status measurement-contract-invalid и переснять candidate |
| Отчёт меняется от запуска к запуску | Условия не зафиксированы или шум выше tolerance | Повторить сценарий и записать условия | Изменить способ измерения или обосновать tolerance |
| Красный компонент приводит к глобальной оптимизации | Диагностика не ограничена именем поля | Проверить input и границу failed component | Сделать одну локальную проверку, не менять весь стек |
| Учебный отчёт называют browser metric | Внутреннее поле не сопоставлено с API | Найти источник и mapping для значения | Переименовать поле или добавить реальный сбор |
Представим, что baseline снят с cold cache, а candidate — с warm cache. Candidate может оказаться быстрее. Это не доказательство улучшения: изменился вход. То же происходит, если baseline относится к /checkout, а candidate — к /cart, или если один запуск включает авторизацию, а другой нет.
Правильный результат в таком случае — не FAIL и не PASS. Сравнение нужно остановить с причиной measurement-contract-invalid. Component map остаётся пустым, aggregate не получает performance-смысл, а следующий шаг — восстановить один контракт и повторить измерение.
Не стоит автоматически нормализовать несовпадение. Если система молча заменит warm на cold или возьмёт последний baseline, она создаст удобный, но ложный verdict. Лучше потерять один результат, чем принять несопоставимые числа за регрессию или улучшение.
Модель полезна только после явной границы между сбором и решением. Сбор получает официальную запись API. Адаптер выбирает поля, нормализует единицы и сохраняет условия. Сравниватель работает уже с проверенной внутренней схемой.
\nconst navigation = performance.getEntriesByType('navigation')[0];\n\nconst observation = {\n source: 'PerformanceNavigationTiming',\n fields: {\n responseEnd: navigation.responseEnd,\n domInteractive: navigation.domInteractive,\n loadEventEnd: navigation.loadEventEnd\n },\n conditions: {\n route: location.pathname,\n navigationType: navigation.type\n }\n};\n\n// Учебный пример: здесь нет решения о PASS/FAIL.\n// Сначала нужен отдельный mapping в схему проекта.Этот код показывает границу, а не готовый production-сборщик. Он не учитывает отправку данных, sampling, privacy, доступность API и различия браузеров. Он также не превращает три timestamp в четыре условных компонента автоматически. Mapping должен описывать формулу, единицы, поддержку браузеров и условия применимости.
\nЕсли проекту нужен ресурсный бюджет, следует получить Resource Timing и отдельно решить, какие ресурсы входят в контракт. Документная навигация и загрузка каждого ресурса отвечают на разные вопросы. Смешивать их в один total без правила агрегации нельзя.
\nУчебные ticks не дают сведений о реальном количестве пользователей, SLA, полевых перцентилях или влиянии устройства. Даже настоящий browser trace не объясняет сам по себе причину регрессии. Он показывает наблюдение. Причину нужно искать в ресурсах, коде, серверном ответе, cache и сценарии.
\nОдин запуск не описывает шум. Число tolerance нельзя выбрать по привычке. Его обосновывают повторениями, средой, источником данных и ценой ложного срабатывания. Слишком большой допуск прячет регрессию. Слишком маленький превращает проверку в шумный сигнал.
\nБюджет также не заменяет продуктовую проверку. Быстрый маршрут может быть функционально неполным, а снижение одной метрики может ухудшить другой сценарий. Поэтому контракт должен ограничивать именно тот путь, который команда защищает, а рядом должны существовать проверки корректности.
\nИзменение готово, если маршрут и сценарий названы; условия сохранены; baseline и candidate имеют одну схему; каждое поле имеет limit и tolerance; отчёт показывает component checks отдельно от aggregate; mismatch условий останавливает сравнение; failed component ведёт к одной ограниченной проверке; повторный candidate снят в том же contract.
\nЗелёный total сам по себе этому критерию не соответствует. Проверка считается полезной только тогда, когда по её результату можно понять, что именно нарушено, что нужно проверить дальше и почему сравнение вообще допустимо.
\nPerformanceNavigationTiming и навигационных записей браузера.В учебном отчёте после изменения маршрута общий результат остаётся зелёным: сумма выросла с 85 до 93 условных единиц и не превысила общий предел 98. Но в том же отчёте scriptTicks поднялся с 26 до 34 при допустимом значении 30. Если смотреть только на total, изменение проходит. Цена ошибки — команда принимает зелёный итог за доказательство здоровья всего пути и пропускает участок, который уже вышел за свой предел.
Такой пример не описывает реальный запуск и не обещает пользователю измеренную скорость. Он показывает дефект правила: разные части маршрута нельзя складывать до того, как проверена каждая часть. Бюджет должен сначала установить сопоставимость входов, затем показать named component checks и только после этого посчитать aggregate. Иначе случайное уменьшение одного расхода может замаскировать рост другого.
\nГлавный вывод: общий PASS отвечает только на вопрос об общей сумме. Он не отменяет FAIL отдельного компонента. Чтобы результат можно было повторить, рядом с числами нужны маршрут, сценарий, версия рабочей нагрузки, условия, baseline, candidate, limit и tolerance.
\nБюджет маршрута — это контракт между измерением и решением. Он связывает конкретный путь, пользовательский сценарий и набор измеряемых полей с правилом остановки. Формулировка «страница должна быть быстрой» таким контрактом не является: в ней нет ни входа, ни единицы, ни границы отказа.
\nВ учебной модели маршрут — /training/checkout/review, сценарий — anonymous-cart-with-one-item, а версия рабочей нагрузки — checkout-fixture-v1. Четыре поля имеют суффикс Ticks, потому что это условная единица примера. Она не равна миллисекундам и не переименовывает произвольное число в LCP, TTFB или другую браузерную метрику.
Условия должны описывать то, что способно изменить результат: состояние кеша, viewport, профиль браузера, набор данных, сеть и тип навигации. Полный список зависит от проекта. Правило важнее списка: если baseline и candidate получены при разных обязательных условиях, сравнение надо остановить до вычисления performance verdict.
\nBaseline — это не последний отчёт, который случайно оказался зелёным. Это снимок с той же схемой полей и тем же контрактом, что у candidate. Перед сравнением сверяются route, scenario, workloadVersion, unit и conditions. Если одно поле не совпало, система возвращает состояние measurement-contract-invalid, а не пытается угадать, какую разницу можно простить.
Например, baseline снят с cold cache, а candidate — с warm cache. Более маленькое число candidate не доказывает улучшение: изменился вход. Та же проблема возникает при смене маршрута, состава корзины, viewport или типа навигации. Молчаливое «выравнивание» условий опаснее явной ошибки, потому что красивый отчёт перестаёт показывать границу применимости.
\nПроверка контракта должна быть наблюдаемой. В отчёте полезно сохранить не только статус, но и первое расхождение: conditions.cache: cold → warm. Тогда следующий шаг понятен — переснять candidate в прежних условиях или создать новый baseline с объяснённой причиной.
После validation каждый компонент проверяется отдельно. Для него нужны как минимум фактическое значение, baseline, limit, tolerance и вычисленный allowed. Правило задаётся формулой allowed = limit + tolerance; компонент проходит, если actual <= allowed.
В нашем примере для scriptTicks limit равен 28, tolerance равен 2, поэтому allowed равен 30. Candidate со значением 34 превышает порог на 4. Он также отличается от baseline на 8, но это другая величина: delta описывает изменение относительно снимка, а allowed — границу принятия. Отчёт не должен смешивать эти значения под одним названием «превышение».
Именованный компонент нужен не для того, чтобы заранее объявить виновную библиотеку. Он ограничивает место следующей проверки. Если красным стал scriptTicks, результат подтверждает нарушение правила этого поля. Он ещё не подтверждает причину: ею может оказаться bundle, обработка данных, dynamic import, состояние кеша или ошибка самого измерения.
Общая сумма полезна как отдельный guard. Она показывает, сколько места осталось у маршрута в целом, но теряет распределение расходов. В учебной записи baseline равен 18 + 15 + 26 + 26 = 85. Candidate равен 20 + 16 + 34 + 23 = 93. При aggregate limit 96 и tolerance 2 общий allowed равен 98.
\nCandidate проходит aggregate, потому что 93 не больше 98. Но scriptTicks не проходит, потому что 34 больше 30. Поэтому overall должен быть FAIL. Порядок вычисления защищает от подмены: aggregate отвечает за total, а component отвечает за именованную часть. Зелёная сумма не имеет права превращать красную строку в зелёную.
| Слой | Что получает | Что возвращает | Граница вывода |
|---|---|---|---|
| Contract | route, scenario, version и conditions | comparable или measurement-contract-invalid | Несовпадение не является регрессией |
| Component | baseline, candidate и правило имени | actual, allowed, delta и pass/fail | FAIL указывает поле, но не корень причины |
| Aggregate | сумму полей и общий limit | контекстный total pass/fail | Не отменяет failed component |
| Diagnosis | первое failed name | одну узкую следующую проверку | Не даёт глобального вывода о маршруте |
Ниже — полностью локальная модель. Она не вызывает браузер, сеть, таймер или CI. Все числа заданы явно, поэтому читатель может вручную проверить арифметику. В production такой объект потребует отдельного источника каждого поля и протокола, по которому baseline и candidate были получены.
\nconst contract = {\n route: '/training/checkout/review',\n scenario: 'anonymous-cart-with-one-item',\n workloadVersion: 'checkout-fixture-v1',\n unit: 'teaching-ticks',\n conditions: { browser: 'chromium', viewport: '390x844', cache: 'cold' },\n};\n\nconst rules = {\n documentTicks: { limit: 20, tolerance: 2 },\n styleTicks: { limit: 18, tolerance: 2 },\n scriptTicks: { limit: 28, tolerance: 2 },\n renderTicks: { limit: 30, tolerance: 2 },\n aggregate: { limit: 96, tolerance: 2 },\n};\n\nconst baseline = { documentTicks: 18, styleTicks: 15, scriptTicks: 26, renderTicks: 26 };\nconst candidate = { documentTicks: 20, styleTicks: 16, scriptTicks: 34, renderTicks: 23 };\n\nconst components = Object.keys(rules).filter((name) => name !== 'aggregate');\nconst checks = components.map((name) => {\n const rule = rules[name];\n const allowed = rule.limit + rule.tolerance;\n return {\n name,\n baseline: baseline[name],\n actual: candidate[name],\n limit: rule.limit,\n tolerance: rule.tolerance,\n allowed,\n delta: candidate[name] - baseline[name],\n pass: candidate[name] <= allowed,\n };\n});\n\nconst total = Object.values(candidate).reduce((sum, value) => sum + value, 0);\nconst aggregateAllowed = rules.aggregate.limit + rules.aggregate.tolerance;\nconst overall = checks.every((item) => item.pass) && total <= aggregateAllowed\n ? 'PASS'\n : 'FAIL';\n\nconsole.log({ overall, checks, total, aggregateAllowed });Вывод этого объекта должен содержать overall: 'FAIL'. В списке checks только scriptTicks имеет pass: false; его actual равен 34, allowed — 30, delta — 8. Total равен 93 и проходит aggregate. Если код возвращает PASS из-за одной только суммы, в нём нарушено главное правило модели.
Здесь есть ещё одна проверка качества примера: все четыре поля входят в total ровно один раз. Нельзя сначала считать total из всех свойств объекта, а затем добавить туда уже агрегированный результат. В реальной схеме список компонентов лучше хранить отдельно от aggregate, чтобы случайное новое поле не меняло формулу без ревью.
\nПоложительный путь показывает арифметику, но надёжность видна на отказе. Изменим только conditions.cache у candidate с cold на warm. Числа могут остаться прежними, однако результат уже нельзя трактовать как сравнение одного workload. Система должна вернуть measurement-contract-invalid, пустой список component checks и aggregate со статусом not-comparable.
Нельзя исправлять такой отказ увеличением tolerance. Допуск относится к шуму внутри одного объявленного условия, а не к смене самого условия. Если команда сознательно переходит с cold cache на warm cache, это новый сценарий измерения: ему нужен новый контракт и понятный baseline.
\nТо же правило действует для отсутствующего поля, лишнего поля или отрицательного значения. До вычисления delta проверяются схема и диапазон. Иначе пропущенное значение превратится в undefined, а арифметика или сериализация скроет ошибку под числом, похожим на результат.
Когда модель понадобится связать с браузером, сначала выбирается источник, а не придумывается mapping под удобную формулу. Navigation Timing предоставляет запись о навигации текущего документа. User Timing позволяет помечать и измерять участки работы приложения. Performance Timeline задаёт способы получить записи и наблюдать новые entries. Эти интерфейсы дают исходные наблюдения, но не определяют четыре учебных компонента и их лимиты.
\nconst [navigation] = performance.getEntriesByType('navigation');\n\nif (navigation) {\n const observation = {\n source: 'PerformanceNavigationTiming',\n route: location.pathname,\n navigationType: navigation.type,\n fields: {\n responseEnd: navigation.responseEnd,\n domInteractive: navigation.domInteractive,\n loadEventEnd: navigation.loadEventEnd,\n },\n };\n\n console.table(observation);\n}\n\nperformance.mark('checkout-review-start');\n// Здесь выполняется заранее описанная работа приложения.\nperformance.mark('checkout-review-end');\nperformance.measure(\n 'checkout-review-work',\n 'checkout-review-start',\n 'checkout-review-end',\n);Этот фрагмент показывает два разных источника. Navigation entry описывает временные точки навигации; mark и measure описывают названный участок работы приложения. Ни один из них автоматически не становится scriptTicks. Для mapping нужно записать поле источника, единицу, момент получения, условия доступности, преобразование и владельца. Если связь не определена, оставьте поле вне production verdict.
Есть и практическое ограничение: поддержка и поведение API зависят от браузера и сценария, а начало наблюдения может влиять на то, какие записи доступны. Поэтому пример не утверждает, что одной строки getEntriesByType достаточно для полевого профиля. Сначала проверяется наличие источника и повторяемость процедуры, затем решается, какие его поля подходят выбранной границе.
Component failure — это сигнал для следующего факта, а не готовая причинная цепочка. Если красным стал scriptTicks, выберите одну границу: размер bundle после изменения, список новых импортов или число обработанных элементов. Результат этой проверки должен различать хотя бы две гипотезы. Если ни одна граница не наблюдается, так и запишите: имеющихся данных недостаточно для выбора причины.
Широкая оптимизация всего маршрута в этот момент создаёт новый риск. Она меняет несколько переменных и лишает команды возможности связать новый результат с исходным failure. Сначала исправляется одна известная причина или уточняется измерение, затем candidate переснимается при прежнем контракте и сравнивается с тем же baseline.
\nИзменение limit тоже не является быстрым лечением. Оно допустимо, если владелец маршрута согласовал новую стоимость, обоснование и новый предел. Повышение aggregate, когда failed component остаётся без объяснения, убирает защитный сигнал, но не уменьшает работу маршрута.
\nПроверка готова к использованию, если читатель может восстановить входы и получить тот же статус. В отчёте видны route, scenario, версия и conditions; mismatched contract останавливает сравнение; каждый component содержит actual и allowed; aggregate помечен как вторичный; failed name ведёт к одной следующей проверке.
\nДля учебного объекта ожидается конкретный результат: baseline total равен 85, candidate total равен 93, aggregate allowed равен 98, scriptTicks имеет actual 34 и allowed 30, overall равен FAIL. При смене cache ожидается measurement-contract-invalid, а не вывод об ускорении или регрессии.
Условные ticks не сообщают latency реальных пользователей, перцентили, SLA, влияние устройства или стоимость передачи данных. Даже настоящий trace показывает наблюдение, но не доказывает сам по себе, какая библиотека вызвала изменение. Причину устанавливают отдельным экспериментом с сохранёнными входами.
\nОдин запуск также не описывает шум. Tolerance нужно выбирать по повторениям, среде, источнику и цене ложного срабатывания. Слишком большой допуск прячет постепенный рост, слишком маленький превращает бюджет в нестабильный сигнал. Эти решения принадлежат проекту и не следуют из арифметики учебного примера.
\nБюджет не заменяет функциональную проверку. Маршрут может уложиться в performance limits и при этом потерять действие, ошибку или доступность. Поэтому component checks должны жить рядом с проверками корректности сценария, а не подменять их.
\nPerformanceNavigationTiming и временные данные навигации документа; он не определяет учебные ticks и лимиты статьи.