Производительность frontend-приложений¶

Требования этого документа применяются к browser-результату frontend-приложений профилей CSR, SSR, SSG и edge по frontend/rendering-profiles.md. Документ фиксирует рекомендуемое измерение и базовую политику. Численные цели Service Level Indicator (SLI) и пороги оповещений определяются владельцем продукта по OPS-SLO-002. Уровни обязательности определены в корневом README.md.

FE-PERF-001. Измерение Core Web Vitals¶

Уровень: SHOULD

Применяется к: production-приложению

Приложению следует измерять Core Web Vitals (LCP, INP, CLS) и базовые метрики загрузки у реальных пользователей через RUM по FE-OBS-001. Измерение следует вести непрерывно в production, а не только в синтетических тестах. Эти показатели используются как пользовательские SLI для применимых критичных сценариев по OPS-SLO-001.

Численная цель и окно измерения устанавливаются по OPS-SLO-002. Production- выпуску следует иметь численную цель для Core Web Vital, выбранного как SLI критичного пользовательского сценария. Для начальной калибровки допускается временная цель по OPS-SLO-002.

Обоснование¶

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

Проверка¶

проверка наличия метрик LCP, INP и CLS в OpenObserve;
сопоставление измерения с реальной аудиторией;
review представления метрик по выпускам.

Исключения¶

Проект MAY не собирать RUM без ADR. В изолированном окружении или при выборе другого канала производительность MAY измеряться синтетически с явно зафиксированной периодичностью.

FE-PERF-002. Бюджет размера bundle¶

Уровень: SHOULD

Применяется к: production-сборке

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

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

Обоснование¶

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

Проверка¶

автоматическая проверка бюджета в CI;
проверка состава bundle по маршрутам;
review обоснования изменения бюджета.

Исключения¶

Бюджет MAY отсутствовать, если до release выполняется другая воспроизводимая автоматизированная проверка, обнаруживающая регрессию объёма или времени загрузки критичного сценария. Причина выбора и связь проверки с SLI по FE-PERF-001 должны быть зафиксированы по правилам корневого README.md.

FE-PERF-003. Стратегия загрузки ресурсов¶

Уровень: SHOULD

Применяется к: ресурсам production-приложения

Приложению следует загружать в начальном сценарии только необходимые для него ресурсы. При использовании бюджета FE-PERF-002 начальная загрузка должна оставаться в его пределах. Крупный ресурс, не используемый начальным сценарием, следует загружать после него или по требованию.

Code splitting, lazy loading, приоритизация и адаптивная загрузка MAY использоваться как способы достижения этого результата, но ни один из них не обязателен сам по себе.

Обоснование¶

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

Проверка¶

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

Исключения¶

Ресурс, необходимый основному сценарию, MAY загружаться без отсрочки.

FE-PERF-004. Регрессия производительности в CI¶

Уровень: SHOULD

Применяется к: CI pipeline проекта

Проекту следует выполнять воспроизводимую синтетическую проверку LCP, INP и CLS для изменения критического пути, стратегии рендеринга или загрузки ресурсов. Запуск для каждого merge request не требуется. При использовании бюджета FE-PERF-002 CI должен продолжать проверять его детерминированно; при выборе эквивалентного контроля он должен выполняться перед release. Статистически нестабильный синтетический результат не должен быть единственной причиной блокировки.

Обоснование¶

Автоматическая проверка обнаруживает регрессию до поставки, пока SLI ещё не зафиксированы.

Проверка¶

review зафиксированных условий синтетического запуска;
сравнение результата до и после существенного изменения;
проверка применимого контроля до release по FE-PERF-002.

Исключения¶

Отклонение допустимо, если изменение не затрагивает критический путь и проходит применимый контроль по FE-PERF-002.