Chromium собирается выкатить выравнивание таймеров (в том числе DOM-таймеров) на 125 Гц.

Сейчас движок старается запустить таймер тогда, когда дедлайн запуска задачи по таймеру пришёл. Причём для разных задач есть разные механизмы расписаний вызовов задач, для синхронизации которых используется механизм сообщений (messaging). И в некоторых местах из-за этого возникают баги синхронизации, а в других видно пустое потребление ресурсов, когда движок выполнения задач просто вхолостую гоняется на проверку «Ну что, а теперь пора?».

Для WebRTC уже попробовали включить принудительную синхронизацию на 120 Гц (то есть задачи выполняются 120 раз в секунду), и в некоторых случаях это привело к 12% экономии энергопотребления. Теперь хотят включить такой же механизм для многих других задач. Подробнее можно посмотреть здесь.

Как это скажется на разработчиках?
С одной стороны, приложения просто из коробки начнут меньше разряжать батареи устройств. С другой — если у вас были какие-то вычисления или анимации, для которых критически важно выполняться как можно раньше, то стоит присмотреться к другим API, которые работают не на таймерах. Chrome уже предлагал такие решения после релиза Chrome 88. После включения механизма выравнивания таймеров ваши графики замеров пользовательских метрик, например, могут начать показывать другую картинку с дельтой ±8ms.

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