{
  "index": 213,
  "slug": "editorial-2022-02-practice-performance-budget",
  "title": "Бюджет производительности: как не спрятать регрессию за общим PASS",
  "excerpt": "Как описать один пользовательский путь, разделить его бюджет на именованные части и остановить изменение, которое превышает допуск, даже если общий результат ещё выглядит зелёным.",
  "contentHtml": "<p>На странице оформления следующий шаг появляется позже, чем ожидал пользователь. В отчёте при этом стоит зелёный PASS: общий размер страницы и суммарное время не вышли за предел. Команда добавляет небольшой виджет, ещё один стиль и дополнительный обработчик. Каждый коммит проходит проверку. Через несколько релизов один участок пути забирает весь запас, а итоговая цифра продолжает скрывать это смещение.</p>\n<p>Цена ошибки — не абстрактная «медленная страница». Пользователь дольше ждёт перехода, чаще повторяет действие или закрывает вкладку. Инженер тратит время на поиск причины среди уже принятых изменений. Если бюджет проверяет только сумму, он не отвечает на главный вопрос: какой компонент потратил запас и что именно нужно остановить?</p>\n<p>Тезис статьи простой: бюджет производительности должен описывать конкретный пользовательский путь, условия измерения и несколько именованных ограничений. Общая сумма полезна как дополнительный предохранитель. Она не должна отменять провал отдельной части.</p>\n<h2>Что именно ограничивает бюджет</h2>\n<p>Бюджет — это набор заранее названных пределов. Он может ограничивать размер JavaScript, число запросов, время навигации или другую метрику, которая связана с выбранным сценарием. Число имеет смысл только вместе с путём и условиями. Лимит для каталога нельзя без проверки перенести на оформление заказа: у страниц разные данные, изображения и порядок действий.</p>\n<p>Сначала назовите вход. В учебном примере это маршрут <code>/training/checkout/review</code> и сценарий <code>anonymous-cart-with-one-item</code>. Это не production-маршрут и не результат настоящего запуска. Длинное имя нужно намеренно: другой товар, авторизация, локаль или feature flag могут создать другой набор ресурсов.</p>\n<p>Затем зафиксируйте условия. Запишите версию сборки, тип сети, состояние кеша, устройство или профиль CPU, способ запуска и источник чисел. Если часть условий неизвестна, не подставляйте правдоподобное значение. Пометка «не измерялось» лучше, чем вывод о браузере по одному числу из учебного объекта.</p>\n<table><caption>Контракт бюджета для одного пути</caption><thead><tr><th>Часть контракта</th><th>Пример значения</th><th>Что проверяет</th><th>Чего не доказывает</th></tr></thead><tbody><tr><td>Route и scenario</td><td><code>/training/checkout/review</code>, одна корзина</td><td>Сравнивает один и тот же вход</td><td>Качество всех страниц</td></tr><tr><td>Условия</td><td>Сборка, сеть и cache записаны</td><td>Показывает сопоставимость замеров</td><td>Поведение другой среды</td></tr><tr><td>Компоненты</td><td><code>document</code>, <code>style</code>, <code>script</code>, <code>render</code></td><td>Находит участок, который забрал запас</td><td>Автоматически не объясняет причину</td></tr><tr><td>Допуск</td><td>Limit и tolerance у каждого имени</td><td>Даёт правило остановки</td><td>Универсальную норму для любого продукта</td></tr><tr><td>Total</td><td>Вторичный предел суммы</td><td>Замечает общий рост</td><td>Разрешение на провал компонента</td></tr></tbody></table>\n<h2>Почему одна сумма даёт ложный PASS</h2>\n<p>Представьте четыре части с пределами 26, 17, 30 и 22 условных единицы. Их допустимая сумма равна 95. Baseline содержит 24, 15, 26 и 20. Candidate меняет только script: 34 вместо 26. Сумма candidate равна 93. По total он проходит. По правилу для script он превышает предел 30 и должен получить FAIL.</p>\n<p>Такой пример показывает перенос затрат. Остальные части не стали дешевле из-за того, что скрипт стал тяжелее. Если проверять только сумму, рост в одном месте можно компенсировать случайным уменьшением в другом. Для пользователя это не всегда равноценная замена: лишний JavaScript может задержать обработчик, а уменьшение изображения не вернёт время, потерянное на главном потоке.</p>\n<figure><img src=\"/assets/editorial/2022/performance-budget-allocation-2022.svg\" alt=\"Схема бюджета пользовательского пути: document, style, script и render имеют отдельные пределы, а общий total проверяется после компонентов\"><figcaption>Схема разделяет именованные части и общий предел. Учебная иллюстрация объясняет порядок проверки; она не показывает реальный trace, браузерный запуск или production-метрику.</figcaption></figure>\n<h2>Учебная модель сравнения</h2>\n<p>Ниже код намеренно работает с числами, а не с браузером. Единица <code>ticks</code> придумана для примера. Она показывает инвариант проверки: провал компонента нельзя замаскировать зелёной суммой.</p>\n<pre><code>const budget = {\n  route: '/training/checkout/review',\n  scenario: 'anonymous-cart-with-one-item',\n  components: {\n    documentTicks: { limit: 26, tolerance: 1 },\n    styleTicks: { limit: 17, tolerance: 1 },\n    scriptTicks: { limit: 30, tolerance: 2 },\n    renderTicks: { limit: 22, tolerance: 1 },\n  },\n  totalTicks: { limit: 95, tolerance: 3 },\n};\n\nconst baseline = {\n  documentTicks: 24,\n  styleTicks: 15,\n  scriptTicks: 26,\n  renderTicks: 20,\n};\n\nconst candidate = {\n  ...baseline,\n  scriptTicks: 34,\n};\n\nfunction checkBudget(snapshot, contract) {\n  const components = Object.entries(contract.components).map(\n    ([name, rule]) =&gt; ({\n      name,\n      value: snapshot[name],\n      allowed: rule.limit + rule.tolerance,\n      pass: snapshot[name] &lt;= rule.limit + rule.tolerance,\n    }),\n  );\n\n  const total = Object.values(snapshot).reduce((sum, value) =&gt; sum + value, 0);\n  const totalAllowed = contract.totalTicks.limit + contract.totalTicks.tolerance;\n\n  return {\n    components,\n    total,\n    totalPass: total &lt;= totalAllowed,\n    pass: components.every((item) =&gt; item.pass) &amp;&amp; total &lt;= totalAllowed,\n  };\n}\n\nconsole.log(checkBudget(candidate, budget));</code></pre>\n<p>В этой модели <code>scriptTicks</code> равен 34, а его allowed равен 32. Total равен 93, а его allowed равен 98. Полный результат обязан быть FAIL. Код не измеряет FCP, LCP, INP, сетевую задержку или работу CPU. Он не вызывает Lighthouse и не заменяет browser trace. В рабочем проекте поля нужно связать с конкретным источником измерения, иначе они остаются внутренней условной шкалой.</p>\n<h2>Симптомы и действия</h2>\n<table><caption>Диагностика регрессии бюджета</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Total проходит, component падает</td><td>Рост скрыт внутри суммы</td><td>Сравнить каждую именованную часть с её allowed</td><td>Остановить изменение и найти владельца части</td></tr><tr><td>Два запуска дают разные выводы</td><td>Не совпали сеть, cache, CPU или данные</td><td>Сопоставить conditions и route в обоих snapshots</td><td>Разделить сценарии или повторить измерение в фиксированных условиях</td></tr><tr><td>Число выросло, но причина неизвестна</td><td>Бюджет хранит результат без состава ресурсов</td><td>Проверить размер chunk, список запросов и источник метрики</td><td>Добавить детализацию, а не повышать лимит вслепую</td></tr><tr><td>Провал появляется только у одной локали</td><td>Сценарии смешаны в одном job</td><td>Запустить одинаковый route для каждой локали отдельно</td><td>Сделать локаль частью scenario или выделить отдельный budget</td></tr><tr><td>Старый snapshot проходит после смены сборщика</td><td>Baseline получен в другой версии среды</td><td>Сравнить версию сборки и формат измерения</td><td>Создать новый baseline и сохранить причину замены</td></tr><tr><td>Команда повышает лимит после каждого FAIL</td><td>Лимит используют как способ убрать сигнал</td><td>Проверить изменение ресурса и обоснование нового допуска</td><td>Сначала устранить рост или зафиксировать осознанное исключение</td></tr></tbody></table>\n<h2>Как выбрать измерение</h2>\n<p>Размер ресурсов и число запросов удобно проверять в сборке. Они дают ранний сигнал до открытия страницы в браузере. Такой сигнал отвечает на вопрос о составе артефакта, но не говорит, как быстро пользователь увидит или сможет использовать экран.</p>\n<p>Временные метрики нужно получать из инструмента, который действительно их измеряет. API Navigation Timing даёт события навигации. <code>PerformanceResourceTiming</code> помогает увидеть интервалы загрузки отдельных ресурсов. Для интеракций нужны отдельные данные о событиях и отрисовке. Не называйте сумму размеров «временем до интерактивности» и не называйте синтетический snapshot полевой метрикой.</p>\n<p>Сопоставимость важнее количества цифр. Один замер на быстром ноутбуке не устанавливает предел для всех телефонов. Среднее значение может скрыть хвост распределения. Если бюджет защищает конкретный путь, проверяйте тот же путь, тот же набор данных и тот же класс условий. Если это невозможно, добавьте в результат причину несопоставимости и остановите автоматическое сравнение.</p>\n<h2>Порядок внедрения</h2>\n<ol><li>Выберите один путь, который связан с действием пользователя, и запишите route, scenario и ожидаемый результат.</li><li>Определите источник каждого числа: размер артефакта, browser timing, synthetic run или field data. Не смешивайте эти классы.</li><li>Зафиксируйте условия запуска: версия сборки, сеть, cache, устройство, данные и feature flags.</li><li>Разделите бюджет на части, которыми можно управлять отдельно: document, style, script, render или другой состав, подходящий пути.</li><li>Снимите baseline и сохраните его рядом с условиями. Не называйте его «истиной» без диапазона и повторных запусков.</li><li>Добавьте candidate-проверку для каждой части и только после неё — проверку total.</li><li>Прогоните положительный и отрицательный сценарии: обычный candidate должен пройти, а превышение одного компонента при зелёном total должно упасть.</li><li>Для каждого FAIL назначьте действие: уменьшить ресурс, убрать запрос, отложить код, изменить сценарий или осознанно пересмотреть контракт.</li></ol>\n<h2>Ограничения</h2>\n<p>Бюджет не исправляет медленную страницу сам. Он только превращает выбранное ожидание в сигнал. Плохой маршрут, неверный baseline или неописанные условия дадут точный ответ на неверный вопрос.</p>\n<p>Лимиты зависят от продукта. Экран с фотографиями, форма оплаты и текстовая статья имеют разный состав ресурсов. Одного числа для всех страниц обычно недостаточно. Разделяйте budgets по типу пути, но не создавайте отдельный лимит для каждого случайного варианта: так сигнал распадётся и станет необслуживаемым.</p>\n<p>Лабораторные данные и данные реальных пользователей дополняют друг друга. Лабораторный запуск помогает сравнивать изменения в одинаковой среде. Полевые данные показывают разброс устройств, сетей и поведения. Учебный код из статьи не содержит ни тех, ни других данных. Он проверяет только логику контракта.</p>\n<p>Иногда рост оправдан функцией. Тогда измените бюджет вместе с описанием причины, владельцем и способом повторной проверки. Не повышайте лимит только для того, чтобы вернуть зелёный статус.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Контракт готов, если другой инженер может открыть запись budget и ответить на четыре вопроса: какой путь проверяется, в каких условиях, какая часть превысила допуск и какое действие следует выполнить. Автоматическая проверка должна завершаться FAIL, когда один компонент превышает свой allowed, даже если total остаётся внутри общего предела.</p>\n<p>Минимальный приёмочный набор выглядит так: baseline и candidate имеют одинаковые route, scenario и conditions; каждое значение неотрицательно и принадлежит известному полю; результат печатает component verdict и total verdict; положительный пример проходит; отрицательный пример из учебного кода падает на <code>scriptTicks</code>. Это проверяет механизм, но не заявляет production-эффект.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://web.dev/articles/performance-budgets-101\" target=\"_blank\" rel=\"noopener noreferrer\">web.dev: Performance budgets 101</a> — определение бюджета как набора ограничений и связь лимитов с решениями о ресурсах.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: PerformanceResourceTiming</a> — официальное описание временной шкалы загрузки отдельных ресурсов.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Navigation_timing\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Navigation timing</a> — официальное описание событий навигации и границ API.</li></ul>\n<p>Эти источники описывают инструменты и понятие бюджета. Они не подтверждают числа из учебного примера и не дают готовый лимит для конкретного продукта.</p>"
}