Начните с путей, а не со средних по сайту
Составьте список из трёх–пяти путей, где задержка имеет явную клиентскую или операционную цену: переход на кампейновую страницу, поиск товара, отправка формы лида, вход в систему или завершение запроса в службу поддержки. Для каждого опишите начало, полезный результат, основной класс устройства и страницу или взаимодействие, которые должны работать хорошо.
Дайте каждому пути отдельную строку бюджета. Дашборд может содержать больше кода, чем публичная статья, но его действие по фильтрам требует цели по отзывчивости. Медиа-обогащенная страница товара может допускать большие изображения, но необходим лимит для основного видимого изображения. Это предотвращает исчезновение слабого критического пути в усреднении по источнику.
Назовите, что посетитель видит или может сделать: прочитать предложение, увидеть результат или получить подтверждение отправки формы.
Кеширование существенно меняет стоимость ресурсов, поэтому указывайте, покрывает ли бюджет первый визит, повторный визит или оба варианта.
Выбирайте результаты и управляемые входы
Используйте и метрики результата, и ограничения по входам. 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 для поиска, фильтрации, меню и оформления заказа; до появления полевых данных применяйте лабораторный прокси.
Ограничьте начальный маршрут и крупнейших вкладчиков, чтобы владельцы знали, что нужно менять после нарушения.
Задавайте числа от вашего базового уровня
Снимите базовый уровень для каждого пути. В PageSpeed Insights различайте поле Chrome User Experience Report (CrUX), которое агрегирует реальные Chrome‑опыты пользователей, и лабораторные данные Lighthouse, которые являются контролируемым тестом. Поле показывает опыт, достижимый пользователям; лабораторные тесты делают изменение повторяемым перед выпуском.
Сегментируйте как минимум по мобильным и десктопным устройствам и, по возможности, по критическим шаблонам или URL. PageSpeed Insights может по умолчанию использовать данные по источнику (origin), если URL‑данные отсутствуют; некоторые страницы не имеют данных CrUX. В таком случае пометьте запись как лабораторный базовый уровень и добавьте измерение реальных пользователей для важных путей. Сохраняйте тестовый URL, профиль устройства и сети, состояние кеша, дату и версию инструмента с каждым базовым снимком.
Выберите цель, которая планомерно улучшает базовый уровень, затем протестируйте её в репрезентативных условиях. Бюджет, который блокирует обычные релизы, будет обходиться; бюджет выше текущего опыта никого не защищает.
75-й перцентиль — это значение, на или ниже которого находятся 75% наблюдаемых опытов; это не среднее.
Сделайте бюджет правилом выпуска
Храните бюджет в версионируемом, проверяемом месте рядом с кодом или чеклистом выпуска. Каждая строка должна содержать путь, метрику, профиль теста или популяцию, порог предупреждения, порог ошибки, владельца, метод измерения и путь для исключений. MDN рекомендует уровни предупреждения и ошибки: предупреждение поддерживает проактивное планирование, а ошибка — верхнюю границу с заметным негативным эффектом.
Автоматизируйте надёжные проверки. Сборщик пакетов может отклонять слишком тяжёлый артефакт или начальную точку входа; webpack поддерживает максимальные ограничения на артефакты и точки входа и подсказки об уровнях ошибок в продакшене. Выполняйте повторяемые лабораторные тесты для затронутого пути в pull request‑ах или релизных кандидатах. Сохраняйте полевые метрики для пострелизной верификации и приоритизации, а не как ненадёжный gate в сборке.
Когда лимит не проходит, уменьшите ресурс, отложите несущественный код, измените опыт, разделите выпуск или согласуйте исключение. Не повышайте порог тихо, чтобы пройти сборку.
Зафиксируйте владельца продукта и технического владельца, влияние на клиентов, дату истечения и задачу по устранению перед выпуском.
Блокируйте воспроизводимый порог ошибки для защищённого пути; уведомляйте и расследуйте пороги предупреждений.
Проверяйте и исправляйте после запуска
Вес страницы не предсказывает весь опыт полностью. Порядок запросов, работа, блокирующая рендер, возможности устройства, условия сети, кеширование и третьи стороны тоже влияют. Держите ограничения по входам, чтобы ловить рост, и метрики результата, чтобы проверять, пригоден ли путь. Интерфейс W3C Resource Timing предоставляет тайминги ресурсов и размеры передачи, сжатые и распакованные, для глубокой диагностики. Детали таймингов к кросс‑орижин ресурсам могут ограничиваться разрешениями тайминга, поэтому неполная «водопадная» диаграмма не доказывает отсутствие затрат со стороны третьих лиц.
Проверяйте полевые результаты после значительных изменений шаблона, платформы, маркетинговых тегов или трафика. Если LCP ухудшился, проверьте ответ сервера, ресурс, являющийся LCP, и работу, блокирующую рендер. Если INP ухудшился, проанализируйте реальные взаимодействия; Lighthouse не может измерить INP, потому что в нём нет пользовательского ввода, хотя Total Blocking Time служит лабораторным прокси. Используйте проактивный рабочий процесс SIU для триажа нарушения, стабилизации критического пути и верификации исправления в том же контексте измерения.
Просроченные исключения быстро выявляют временный долговременный технический или производственный долг, который стал постоянным.
