Кратко

  • Первый публичный проект W3C в сентябре 2015 года описал requestIdleCallback: страница просит время, когда браузер ожидает простой, и получает IdleDeadline с оценкой оставшегося времени через timeRemaining().
  • Документы 2017 и 2025 годов сохраняют разделение обязанностей. Браузер выбирает окно, страница делит дело на части. Необязательный срок ожидания может вызвать отложенную работу даже без спокойного окна.

У каждой страницы найдётся папка с делами «на потом». Посчитать данные, подготовить возможный следующий экран, привести в порядок локальные записи. Один пункт выглядит пустяком. Десяток таких пунктов способен превратить нажатие кнопки в ожидание у закрытого окошка. У браузера между тем есть собственная очередь: принять ввод, показать следующий кадр, не заставлять человека гадать, сработал ли его жест. Свободное время существует лишь между этими обязанностями.

Раньше автор мог назначить возвращение через setTimeout. Таймер звонил в указанную минуту, даже если браузер как раз рисовал интерфейс. Первый публичный проект W3C от 17 сентября 2015 года предложил спросить расписание у того, кто его ведёт. Страница вызывает requestIdleCallback; браузер ждёт периода, который считает свободным, и передаёт функции объект IdleDeadline. Метод timeRemaining() сообщает, сколько времени, по текущей оценке, осталось до конца окна.

Оценка заставляет дробить работу. Выполнить небольшую часть, посмотреть на остаток, остановиться и попросить новое окно для продолжения. Проект 2015 года ограничивал один период простоя 50 миллисекундами; новый ввод может сократить его ещё сильнее. Длинная функция не становится короткой оттого, что её назвали фоновой. Если страница занесла в пустую комнату весь архив, читателю придётся ждать, пока она вынесет шкафы. Код должен уметь остановиться между коробками.

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

Текст Candidate Recommendation от 31 января 2017 года и Proposed Recommendation от 10 октября 2017 года учитывали другую беду. Браузер может оставаться занятым так долго, что фоновая задача не дождётся очереди. Для этого автор может задать timeout. После истечения срока функция получает возможность выполниться, а didTimeout сообщает причину вызова. Очередь сдвигается, но работа теперь претендует на время среди срочных событий. Если каждый скрипт ставит себе такой пропуск, запасной выход быстро становится главным входом.

История публикаций W3C ведёт от первого проекта 2015 года через этапы 2017-го к следующим редакциям. Рабочий проект от 21 мая 2025 года по-прежнему отдаёт браузеру определение периода простоя, а функции — оценку времени. Десятилетие правок оставило в центре практический вопрос: кто видит общую очередь и кто вправе решать, какое местное дело занести в неё.

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