STATUS IS UPВИКИ ПО ОПТИМИЗАЦИИ САЙТОВ
03Ускорить
Основы оптимизации / Ускорить

Как задать бюджет производительности сайта, который команды будут соблюдать

Установите применимые и исполняемые ограничения по весу страниц, времени загрузки и отзывчивости для тех пользовательских путей, которые важны клиентам.

Как задать бюджет производительности сайта, который команды будут соблюдать — ВИЗУАЛЬНОЕ РУКОВОДСТВО
ЧИТАТЬ
8 мин
ИСТОЧНИКИ
6
ПОВТОРНО ПРОВЕРИТЬ
2027-03-27
проверено
Рецензент по веб‑производительности и релизной инженерии
КРАТКИЙ ОТВЕТ

Начните с решения.

Задайте бюджет производительности сайта, выбрав несколько пользовательских путей, которые имеют значение, измерив их текущее поведение и согласовав пределы, которые можно реально пройти при выпуске. Сопрягите одну–две пользовательские метрики с управляемыми лимитами: например, целевой показатель загрузки и взаимодействия для мобильных устройств на 75-м процентиле, а также ограничения по начальному JavaScript, изображениям и внешним запросам. Для каждого лимита задайте уровень предупреждения и уровень ошибки, блокирующий релиз.

Не начинайте с универсального числа по весу страницы. Страница товара, результаты поиска и профиль залогиненного пользователя решают разные задачи. Используйте данные реальных пользователей (field data), когда они есть, затем выполните согласованный лабораторный тест для важного пути перед выпуском. Когда фича потребляет мощность, уменьшите или отложите другой вес, упростите путь или согласуйте временное исключение с датой исправления.

ВИЗУАЛЬНОЕ РУКОВОДСТВО

Видеть работу как систему.

Используйте эту карту, чтобы связать решения из статьи, прежде чем применять отдельные тактики.

SIUУскорить
01Начните с путей, а не со средних по сайту
02Выбирайте результаты и управляемые входы
03Задавайте числа от вашего базового уровня
04Сделайте бюджет правилом выпуска
01

Начните с путей, а не со средних по сайту

Составьте список из трёх–пяти путей, где задержка имеет явную клиентскую или операционную цену: переход на кампейновую страницу, поиск товара, отправка формы лида, вход в систему или завершение запроса в службу поддержки. Для каждого опишите начало, полезный результат, основной класс устройства и страницу или взаимодействие, которые должны работать хорошо.

Дайте каждому пути отдельную строку бюджета. Дашборд может содержать больше кода, чем публичная статья, но его действие по фильтрам требует цели по отзывчивости. Медиа-обогащенная страница товара может допускать большие изображения, но необходим лимит для основного видимого изображения. Это предотвращает исчезновение слабого критического пути в усреднении по источнику.

Определите момент ценности

Назовите, что посетитель видит или может сделать: прочитать предложение, увидеть результат или получить подтверждение отправки формы.

Разделяйте пути для новых и возвращающихся

Кеширование существенно меняет стоимость ресурсов, поэтому указывайте, покрывает ли бюджет первый визит, повторный визит или оба варианта.

02

Выбирайте результаты и управляемые входы

Используйте и метрики результата, и ограничения по входам. Google описывает Largest Contentful Paint (LCP) как метрику загрузки; Interaction to Next Paint (INP) — как отзывчивость взаимодействия; и Cumulative Layout Shift (CLS) — как визуальную стабильность. Рекомендуемые пороги хорошего состояния: LCP ≤ 2.5 секунды, INP ≤ 200 миллисекунд и CLS ≤ 0.1 на 75-м процентиле, рассматриваемые отдельно для мобильных и десктопных устройств.

Добавьте лимиты, которые выявляют причину на раннем этапе: начальный JavaScript, изображения, необходимые до основного контента, общий объём передачи для маршрута, запросы к третьим сторонам и известный «дорогой» виджет. Отслеживайте сжатые размеры передачи последовательно. Диагностика вроде Time to First Byte может помочь при расследовании медленной загрузки, но сама по себе не является показателем клиентского исхода.

Бюджет загрузки

Используйте LCP, когда путь зависит от появления основного контента.

Бюджет отзывчивости

Используйте полевые (field) данные INP для поиска, фильтрации, меню и оформления заказа; до появления полевых данных применяйте лабораторный прокси.

Бюджет веса

Ограничьте начальный маршрут и крупнейших вкладчиков, чтобы владельцы знали, что нужно менять после нарушения.

03

Задавайте числа от вашего базового уровня

Снимите базовый уровень для каждого пути. В PageSpeed Insights различайте поле Chrome User Experience Report (CrUX), которое агрегирует реальные Chrome‑опыты пользователей, и лабораторные данные Lighthouse, которые являются контролируемым тестом. Поле показывает опыт, достижимый пользователям; лабораторные тесты делают изменение повторяемым перед выпуском.

Сегментируйте как минимум по мобильным и десктопным устройствам и, по возможности, по критическим шаблонам или URL. PageSpeed Insights может по умолчанию использовать данные по источнику (origin), если URL‑данные отсутствуют; некоторые страницы не имеют данных CrUX. В таком случае пометьте запись как лабораторный базовый уровень и добавьте измерение реальных пользователей для важных путей. Сохраняйте тестовый URL, профиль устройства и сети, состояние кеша, дату и версию инструмента с каждым базовым снимком.

Выберите цель, которая планомерно улучшает базовый уровень, затем протестируйте её в репрезентативных условиях. Бюджет, который блокирует обычные релизы, будет обходиться; бюджет выше текущего опыта никого не защищает.

Правильно читайте перцентиль

75-й перцентиль — это значение, на или ниже которого находятся 75% наблюдаемых опытов; это не среднее.

04

Сделайте бюджет правилом выпуска

Храните бюджет в версионируемом, проверяемом месте рядом с кодом или чеклистом выпуска. Каждая строка должна содержать путь, метрику, профиль теста или популяцию, порог предупреждения, порог ошибки, владельца, метод измерения и путь для исключений. MDN рекомендует уровни предупреждения и ошибки: предупреждение поддерживает проактивное планирование, а ошибка — верхнюю границу с заметным негативным эффектом.

Автоматизируйте надёжные проверки. Сборщик пакетов может отклонять слишком тяжёлый артефакт или начальную точку входа; webpack поддерживает максимальные ограничения на артефакты и точки входа и подсказки об уровнях ошибок в продакшене. Выполняйте повторяемые лабораторные тесты для затронутого пути в pull request‑ах или релизных кандидатах. Сохраняйте полевые метрики для пострелизной верификации и приоритизации, а не как ненадёжный gate в сборке.

Когда лимит не проходит, уменьшите ресурс, отложите несущественный код, измените опыт, разделите выпуск или согласуйте исключение. Не повышайте порог тихо, чтобы пройти сборку.

Правило исключения

Зафиксируйте владельца продукта и технического владельца, влияние на клиентов, дату истечения и задачу по устранению перед выпуском.

Блокирующее правило

Блокируйте воспроизводимый порог ошибки для защищённого пути; уведомляйте и расследуйте пороги предупреждений.

05

Проверяйте и исправляйте после запуска

Вес страницы не предсказывает весь опыт полностью. Порядок запросов, работа, блокирующая рендер, возможности устройства, условия сети, кеширование и третьи стороны тоже влияют. Держите ограничения по входам, чтобы ловить рост, и метрики результата, чтобы проверять, пригоден ли путь. Интерфейс W3C Resource Timing предоставляет тайминги ресурсов и размеры передачи, сжатые и распакованные, для глубокой диагностики. Детали таймингов к кросс‑орижин ресурсам могут ограничиваться разрешениями тайминга, поэтому неполная «водопадная» диаграмма не доказывает отсутствие затрат со стороны третьих лиц.

Проверяйте полевые результаты после значительных изменений шаблона, платформы, маркетинговых тегов или трафика. Если LCP ухудшился, проверьте ответ сервера, ресурс, являющийся LCP, и работу, блокирующую рендер. Если INP ухудшился, проанализируйте реальные взаимодействия; Lighthouse не может измерить INP, потому что в нём нет пользовательского ввода, хотя Total Blocking Time служит лабораторным прокси. Используйте проактивный рабочий процесс SIU для триажа нарушения, стабилизации критического пути и верификации исправления в том же контексте измерения.

Сначала проверяйте исключения

Просроченные исключения быстро выявляют временный долговременный технический или производственный долг, который стал постоянным.

ДЕЙСТВИЕ / ПРОВЕРКА

Практический чек‑лист

  1. 01

    Выберите критические пути

    Выберите три–пять путей с явным пользовательским результатом, шаблоном или URL и основным классом устройства.

    ПРОВЕРИТЬ: Общий список определяет момент ценности для каждого пути.
  2. 02

    Зафиксируйте базовый уровень

    Сохраните полевые результаты, когда они есть, и повторяемый лабораторный прогон перед установкой лимита.

    ПРОВЕРИТЬ: Каждая запись включает дату, URL, профиль, состояние кеша и источник.
  3. 03

    Назначьте метрики результата

    Используйте меры загрузки, отзывчивости и стабильности только там, где они соответствуют пути.

    ПРОВЕРИТЬ: Каждый критический путь имеет метрику, ориентированную на пользователя.
  4. 04

    Добавьте ограничения по входам

    Ограничьте начальный JavaScript, необходимые изображения, объём передачи и релевантные запросы третьих сторон.

    ПРОВЕРИТЬ: Нарушение указывает, какой класс ресурсов или зависимость нужно исследовать.
  5. 05

    Определите уровни предупреждения и ошибки

    Используйте предупреждения для ранних действий и воспроизводимые ошибки для блокировки релиза.

    ПРОВЕРИТЬ: Бюджет указывает, какой порог уведомляет, блокирует и кто отвечает.
  6. 06

    Автоматизируйте стабильные проверки

    Добавьте проверки бандлов и повторяемые лабораторные тесты в процесс доставки.

    ПРОВЕРИТЬ: Предлагаемое изменение возвращает видимый проход, предупреждение или отказ до релиза.
  7. 07

    Сделайте исключения явными

    Требуйте указания влияния, владельцев, срока и задачи по устранению при нарушении.

    ПРОВЕРИТЬ: Каждое активное исключение имеет владельца и дату пересмотра.
  8. 08

    Проверьте после релиза

    Проверяйте полевые или реальные пользовательские данные, когда накопится достаточный трафик.

    ПРОВЕРИТЬ: Запись релиза связывает предрелизный результат с пострелизной проверкой.
  9. 09

    Ребазируйте на основании доказательств

    Меняйте лимит после существенного изменения пути или платформы, а не из-за неудобства.

    ПРОВЕРИТЬ: Изменение бюджета фиксирует доказательства, владельца решения и дату вступления в силу.
ВОПРОСЫ ДЛЯ ОБСУЖДЕНИЯ

Сравнивайте компромиссы, а не приватные данные.

Используйте эти вопросы с вашей командой или сообществом владельцев сайтов. Делитесь методами и уроками, но никогда не вставляйте учётные данные, данные клиентов или непубличные детали инфраструктуры.

  1. 01

    Какой путь выявил компромисс в производительности, который скрывал средний показатель по сайту, и как вы сделали его видимым для принимающих решения?

  2. 02

    Что делает предупреждение о производительности полезным в вашем процессе выпуска, а не лёгким для игнорирования?

  3. 03

    Как владельцы продукта, дизайна и инженерии решают, заслуживает ли фича временного исключения с ограниченным сроком?

ПОПУЛЯРНЫЕ / АВТОРИТЕТНЫЕ РЕСУРСЫ

Откройте исходные материалы.

web.devPerformance budgets 101 ↗

Практическое руководство Google по количественным бюджетам и ориентированным на пользователя временным метрикам, страницным лимитам и проверкам доставки.

Проверено 2026-09-27
MDN Web DocsPerformance budgets ↗

Объясняет типы бюджетов, уровни предупреждений и ошибок, условия базового уровня и ограничения проверок по размеру файла.

Проверено 2026-09-27
web.devWeb Vitals ↗

Определяет текущие Core Web Vitals, рекомендованные пороги и оговаривает различия между полевыми и лабораторными измерениями.

Проверено 2026-09-27
Chrome for DevelopersHow to view Chrome UX Report data on PageSpeed Insights ↗

Показывает, как PageSpeed Insights сочетает полевые данные CrUX с диагностикой Lighthouse и как работает при отсутствии URL‑данных.

Проверено 2026-09-27
W3CResource Timing ↗

Техническая спецификация интерфейсов таймингов браузера (W3C Resource Timing), используемая для исследования байтов и фаз загрузки.

Проверено 2026-09-27
webpackPerformance configuration ↗

Документация по лимитам артефактов и точек входа во время сборки и подсказкам об уровне ошибки для проектов на webpack.

Проверено 2026-09-27

Политика источников. Количественные утверждения используют официальную техническую документацию и стандарты. Ресурсы приведены как ссылки для чтения; внутренние и SID‑ссылки служат навигацией, а не доказательством.

КРАТКИЕ УТОЧНЕНИЯ

Частые вопросы.

Что такое реалистичный бюджет производительности сайта?

Он привязан к конкретному пути, репрезентативному устройству и соединению, и измеренному базовому уровню. Начните с планируемого улучшения, а не с универсальной цели в килобайтах. Сопрягайте результат типа LCP или INP с управляемыми лимитами, такими как начальный JavaScript и передача требуемых изображений. Установите уровень предупреждения ниже порога, блокирующего выпуск.

Стоит ли использовать Core Web Vitals как весь наш бюджет производительности?

Нет. Core Web Vitals описывают полезные результаты, но не указывают, какой ресурс или зависимость выросли. Добавьте ограничения по весу страницы, по запросам и по третьим сторонам, которые команды могут контролировать до релиза. Применяйте каждую метрику там, где она уместна: для пути фильтрации важна отзывчивость, а для статьи — загрузка и стабильность.

Может ли Lighthouse доказать, что изменение безопасно для реальных пользователей?

Нет. Lighthouse — контролируемый лабораторный тест, который находит регрессии до релиза, но возможности устройств, сети и поведение пользователей в поле отличаются. Lighthouse не может измерить INP, потому что в нём нет пользовательского ввода. Используйте повторяемые лабораторные результаты для контроля релиза и валидации важных путей с помощью полевых или реальных пользовательских данных, когда они доступны.

Status Is UP Editorial Team · Редакторы по обеспечению времени безотказной работы (Uptime Enablement Editors)

Проверено Рецензент по веб‑производительности и релизной инженерии. Опубликовано 2026-09-27; обновлено 2026-09-30.