![\"Учебная](\"/assets/editorial/2022/performance-budget-trend-2022.svg\")
В учебном отчёте после изменения маршрута общий результат остаётся зелёным: сумма выросла с 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 и лимиты статьи.