Приоритеты scheduler.postTask для веб-задач

API Prioritized Task Scheduling позволяет помечать работу собственной страницы как user-blocking, user-visible или background. BotBrowser поддерживает воспроизведение разрешённого fixture и запись видимых состояний завершения, порядка и запасного пути; он не может управлять планировщиком операционной системы и не гарантирует, что сторонний сайт увидит один и тот же порядок очереди. Используйте это руководство вместе с измерением производительности и оптимизацией производительности, когда результат задачи должен поддерживать видимое решение приложения.

TL;DR

• Применяйте user-blocking только для работы, сохраняющей текущий интерфейс отзывчивым, а не как универсальный переключатель скорости.
• Применяйте user-visible для работы следующего отображаемого состояния и background для откладываемого обслуживания.
• Для каждой опубликованной задачи сохраняйте AbortSignal, ограниченный запасной путь и явный результат.
• Сравнивайте состояние задачи и видимый результат: приоритет является подсказкой планировщику, а не гарантией задержки.

Содержание

• Выбрать приоритет
• Поставить и отменить работу
• Создать запасной путь
• Проверить порядок без преувеличений
• Заключение

Выбрать приоритет

Предложение WICG Scheduling APIs определяет scheduler.postTask() как постановку callback в очередь с необязательными приоритетом и сигналом. user-blocking является самой сильной подсказкой и подходит для короткого действия, которое сохраняет отзывчивость ввода или обратной связи. user-visible используется по умолчанию для работы, необходимой следующему видимому состоянию. background предназначен для обслуживания, которое может подождать, например очистки кэша или подготовки устаревшего предпросмотра.

Приоритет не обещает время выполнения, справедливость или порядок отрисовки. Браузер может уступить управление, приостановить документ, объединить работу или отклонить задачу до запуска. Связывайте выбор с видимым результатом: результат фильтра может быть user-visible, а пакет аналитики относится к background. Не помечайте весь конвейер рендеринга как user-blocking только потому, что его начал один клик.

Справочник MDN для Scheduler.postTask() описывает допустимые значения и интеграцию с TaskController. Проверяйте API во время выполнения и записывайте версию браузера, если важна совместимость. Наличие метода не делает длинный callback безопасным: разбивайте тяжёлую работу и уступайте между фрагментами.

Поставить и отменить работу

Перед постановкой каждой задачи создайте небольшой журнал владельца. В нём должны быть taskId, priority, fixtureId, startedAt, finishedAt, outcome и cancelReason; не добавляйте текст страницы, идентификаторы аккаунта или полный URL. Идентификатор связывает видимый результат с решением очереди, но не превращается в постоянный профиль.

const controller = new TaskController({ priority: 'user-visible' });
const record = { taskId: 'results-17', priority: 'user-visible', outcome: 'queued' };

const task = scheduler.postTask(
  () => {
    record.outcome = 'rendered';
    renderResults();
  },
  { signal: controller.signal }
);

cancelButton.addEventListener('click', () => {
  controller.abort('superseded');
  record.outcome = 'cancelled';
  record.cancelReason = 'superseded';
});

task.catch(error => {
  record.outcome = error.name === 'AbortError' ? 'cancelled' : 'failed';
});

{
  "fixtureId": "queue-01",
  "taskId": "results-17",
  "priority": "user-visible",
  "implementation": "native-postTask",
  "outcome": "rendered",
  "cancelReason": null,
  "visibleState": "results-ready",
  "browserVersion": "155.0",
  "viewport": "1280x800"
}

TaskController владеет отменой только этой задачи. Отмена до запуска должна дать cancelled, а не считаться медленным успехом. Callback с исключением становится failed после сохранения пригодного состояния ошибки. Оставляйте обработчик catch, потому что необработанная отклонённая promise может скрыть исходное действие пользователя.

Контроллер не прерывает уже выполняющийся JavaScript. Длинный callback всё ещё блокирует главный поток до возврата или уступки. Для рендера многих элементов обрабатывайте ограниченный фрагмент, планируйте следующий и снова проверяйте актуальность запуска. Статья Chrome о приоритетном планировании задач описывает кооперативную модель; postTask не превращается в вытесняющий поток.

Создать запасной путь

Проверяйте globalThis.scheduler?.postTask до выбора предпочтительного пути. Запасной путь должен сохранить тот же видимый результат и правило отмены через отложенный callback, setTimeout или существующий планировщик приложения. Он не должен незаметно превращать фоновую работу в блокирующее действие.

Условие	Предпочтительный путь	Запасной путь и ожидаемый результат
API доступен	postTask(callback, { priority: 'user-visible' })	Записать queued и получить тот же видимый результат
API отсутствует	Объекта scheduler нет	Поставить ограниченный callback и сохранить действие доступным
Сигнал отменён	AbortError до callback	Пометить cancelled; не выводить устаревшие данные
Callback завершился ошибкой	Отклонённая promise задачи	Пометить failed и показать обычное повторение
Работа устарела	Текущий taskId больше не совпадает	Отбросить результат и оставить новое состояние

Запасной путь является контрактом приложения, а не доказательством одинакового времени event loop в двух браузерах. Сохраняйте приоритет как метаданные, даже если реализация не может его выполнить. Тогда сравнение честно показывает priority: background и implementation: timeout, не выдавая это за нативное планирование.

Не создавайте запасной путь, который запускает все callback в одном неограниченном цикле. Большие пакеты возвращают проблему длинной задачи, которую API пытается уменьшить. Руководство web.dev о длинных задачах советует делить работу и измерять видимый эффект. Ограниченный фрагмент с условием остановки проще отменить и объяснить поддержке.

Проверить порядок без преувеличений

Возьмите синтетический fixture с тремя задачами и одной контролируемой отменой. Поставьте input-feedback с user-blocking, results-render с user-visible, а cache-refresh с background; затем запишите первое видимое состояние и итог каждой задачи. Полезное утверждение состоит в том, что текущая интеракция остаётся доступной, а устаревшая работа её не перезаписывает. Не утверждайте универсальный порядок, если браузер может уступить управление или скрыть документ.

Повторите fixture с доступным API, без API и с отменой AbortController до запуска. Храните рядом с результатом browserVersion, viewport, fixtureId и implementation. Сравнивайте первое изменившееся поле, а не собирайте неограниченную трассу. При изменении implementation проверяйте feature detection; при изменении outcome проверяйте отмену и владельца; при изменении видимого кадра проверяйте размер callback.

Если callback создаёт работу worker, планирование worker по hardware concurrency показывает, что navigator.hardwareConcurrency является подсказкой ёмкости, а не гарантией очереди; отделяйте решение хоста от priority.

Используйте измерение производительности браузера через User Timing для собственного интервала fixture и отделяйте его длительность от результата приоритета планировщика.

BotBrowser может открыть этот объявленный fixture в разрешённом контексте и записать видимые метки состояния. Он не может заставить чужой event loop работать в заданном порядке, доказать запуск до отрисовки или гарантировать реализацию предложения конкретной сборкой. Контролируемое воспроизведение описывает fixture и окружение, а не все устройства и сайты.

Сведите телеметрию очереди к необходимому минимуму. Полезная запись содержит fixtureId, taskId, priority, implementation, outcome и ограниченный диапазон длительности. Удаляйте временные идентификаторы после окна проверки и не экспортируйте аргументы callback или содержимое страницы. Эксперимент с приоритетом должен улучшать собственную интеракцию, а не оправдывать сбор несвязанных данных браузера.

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

Ближайшие операционные руководства описывают другие границы: измерение производительности браузера объясняет собственный интервал, а масштабирование контекстов браузера рассматривает lease и ёмкость вне event loop страницы. Здесь рассматриваются очередь задач браузера и пределы трактовки приоритета как доказательства.

Public sources

• WICG Scheduling APIs
• MDN: Scheduler.postTask()
• Chrome for Developers: Prioritized Task Scheduling
• web.dev: Optimize long tasks
• BotBrowser: Automation consistency

Заключение

Выбирайте минимальный приоритет, сохраняющий текущий видимый контракт, присоединяйте собственный AbortSignal и оставляйте ограниченный запасной путь для браузеров без scheduler.postTask. Записывайте queued, rendered, cancelled, failed и superseded, не превращая приоритет в обещание задержки. Повторяйте тот же fixture после обновления браузера и относите результат только к этому fixture и окружению.