Compute Pressure API: приватность и адаптивная нагрузка

Compute Pressure API показывает грубое состояние нагрузки, влияющей на работу браузера. С его помощью можно выбрать более лёгкий рендеринг, отложить необязательную работу или вернуть качество после перехода. Это не счётчик CPU, не отпечаток устройства и не диагноз хоста. Управляемый контекст BotBrowser может выполнить разрешённый fixture, проверить наличие PressureObserver и записать видимый результат, когда runtime раскрывает API; BotBrowser не создаёт источник давления, не включает отсутствующую поддержку и не обещает одинаковые переходы на всех хостах. Для близких сигналов см. Device Memory и производительность, аппаратную параллельность и планирование worker и PerformanceObserver для здоровья приложения.

TL;DR

• Считайте PressureObserver необязательным грубым сигналом для обратимого решения о нагрузке.
• Владелец компонента отвечает за наблюдатель, очистку callback и состояние адаптации.
• Не превращайте nominal, fair, serious или critical в метку устройства, человека или аккаунта.
• Сохраняйте рабочий базовый путь, если API отсутствует, отклонён или недоступен в worker.
• Записывайте ограниченный итог вроде reduced, restored или unavailable, а не долгую историю.

Contents

• Читать давление как грубый сигнал
• Выбрать обратимую политику нагрузки
• Владение наблюдением и границы приватности
• Проверить переходы ограниченным fixture
• Практический итог

Читать давление как грубый сигнал

Спецификация Compute Pressure задаёт модель наблюдения браузера, а не обещание о физическом процессоре. Приложение создаёт PressureObserver, передаёт callback и наблюдает источник вроде cpu. Callback получает PressureRecord с состоянием и временем. Словарь намеренно грубый: nominal, fair, serious и critical обозначают диапазон, а не сравнимый между системами процент.

Справочник MDN Compute Pressure API описывает интерфейс и доступность. Проверяйте конструктор и используемые методы. Отсутствие PressureObserver означает, что данный runtime не даёт необязательный сигнал этим способом; это не доказывает, что хост свободен, перегружен, быстр или неисправен. Причиной могут быть политика разрешений, версия браузера, тип worker или решение платформы о приватности.

Материал Chrome о Compute Pressure показывает адаптацию как способ сохранить отзывчивость. Это модель видимого решения, а не обещание для каждой webview. Источник и выпуск браузера определяют раскрываемые состояния. Базовый путь должен работать до включения расширенного наблюдения.

Не путайте давление с navigator.hardwareConcurrency, navigator.deviceMemory или записью производительности. Браузер может группировать и задерживать изменения, а две страницы на одном хосте увидеть разные состояния. Состояние также не говорит, какая вкладка, процесс, расширение или температура его вызвали. Не помещайте эти вопросы в прикладную запись.

const pressureState = {
  source: 'cpu',
  state: 'unavailable',
  policy: 'baseline',
  sequence: 0,
};

Выбрать обратимую политику нагрузки

Адаптация меняет необязательную работу и сохраняет основную задачу. Серьёзное состояние может приостановить предпросмотр, уменьшить частицы или отложить индекс. Нельзя молча удалить правку, убрать доступный контроль или ослабить обязательную проверку. Решает политика, а наблюдатель даёт лишь подсказку.

Наблюдаемый итог	Действие	Видимый контракт	Восстановление
unavailable	Оставить базовый бюджет и пропустить наблюдение	Основная задача остаётся рабочей	Проверить снова после заявленного изменения runtime
nominal	Разрешить обычный необязательный бюджет	Качество и контроли доступны	Сохранить базовые ограничения
fair	Отложить второстепенную работу и ограничить параллельность	Сообщить о задержке предпросмотра	Вернуть после более новой записи
serious	Приостановить фоновую работу и выбрать лёгкий путь	Сохранить ввод, фокус и отмену	Продолжить только из новой записи
critical	Остановить необязательную работу и сохранить результат	Объяснить паузу	Нужны новое состояние и безопасный бюджет

Это результаты политики, а не загрузка CPU. Лимит, скопированный из другого runtime, может вызвать колебания. Требуйте новую запись перед восстановлением и оставляйте явное действие пользователя для повторного запуска предпросмотра.

Разделяйте бюджеты переднего плана, фона и хранения. Ограничивайте ожидающие задачи, отменяйте устаревшую работу и отмечайте, подтвердил ли worker результат, был заменён или отменён. Во время восстановления сохраняйте последний видимый результат: пустая область похожа на потерю данных.

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

Владение наблюдением и границы приватности

Компонент, создавший PressureObserver, владеет наблюдателем, callback, политикой и очисткой. Отключайте его при навигации, закрытии worker или выключении функции. Callback должен копировать только состояние и локальную последовательность; сетевые запросы и большая сериализация там не нужны.

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

Не соединяйте состояние давления с аккаунтом, URL, locale или устройством. Даже безобидные поля могут стать постоянным поведенческим сигналом. Для ограниченной сессии лучше сохранить агрегат policy=paused. Для статистики fleet удаляйте идентификаторы до агрегации и описывайте срок хранения.

Worker может наблюдать свой источник, но страница решает, относится ли результат к текущему маршруту. Передавайте workload-reduced и локальную последовательность, а не историю. На границе документов проверяйте origin и схему. Отсутствие API должно дать unavailable, а не метку слабой способности профиля.

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

Проверить переходы ограниченным fixture

Используйте синтетическую страницу с одной необязательной нагрузкой и подтверждённым результатом. Fixture проверяет способность, устанавливает наблюдатель, применяет ограниченный переход и отключается. Он не собирает данные аккаунта и не хранит историю. Запуск без API всё равно даёт строку unavailable.

const record = { source: 'cpu', state: 'unavailable', policy: 'baseline', sequence: 0 };
let observer;

if ('PressureObserver' in globalThis) {
  observer = new PressureObserver(records => {
    const latest = records.at(-1);
    record.sequence += 1;
    record.state = latest?.state ?? 'unavailable';
    record.policy = record.state === 'serious' || record.state === 'critical' ? 'reduced' : 'normal';
  });
  await observer.observe('cpu');
}

try {
  await runBoundedFixture({ limit: 8, signal });
} finally {
  observer?.disconnect();
}

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

Случай fixture	Ожидаемая запись	Что подтверждает	Что не подтверждает
Нет конструктора	unavailable, baseline	Проверку способности и безопасную альтернативу	Что хост свободен
Наблюдатель подключён	Видимое состояние и normal или reduced	Владение ограниченной записью	Физический процент CPU
Новое серьёзное или критическое состояние	reduced с новой sequence	Пауза без потери результата	Общее состояние всех вкладок
Маршрут или worker закрыт	Нет commit после disconnect()	Очистку старого callback	Отсутствие уже поставленного callback
Пользователь возвращает работу	Новая задача с текущими входами	Обратимое восстановление	Исчезновение давления во всём хосте

Записывайте только синтетические browserVersion, runtimePath, source, state, policy, sequence, fixtureId и outcome. Разделяйте unsupported-source и unavailable. Повторяйте после изменения браузера, worker, нагрузки или политики и сравнивайте первое изменившееся поле.

Public sources

• Compute Pressure specification
• MDN: Compute Pressure API
• Chrome for Developers: Compute Pressure API
• BotBrowser: Advanced features

Практический итог

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