Chrome 57 будет активно подавлять работу фоновых вкладок

Chrome 57 будет активно подавлять работу фоновых вкладок

Ближайшие изменения в браузере Chrome вряд ли порадуют разработчиков Slack, Discord и других программ, которые работают во вкладках браузера. В бета-версии Chrome 56 реализован новый механизм оптимизации таймеров для фоновых вкладок.

На первый взгляд, инициатива разработчиков выглядит хорошим делом. В сентябрьском плане внедрения (Intent to Implement) объясняются причины, которые сподвигли разработчиков на такое решение.

Главная причина — некоторые плохо спроектированные приложения (например, скрипты аналитики и javascript-реклама) потребляют много ресурсов CPU, хотя находятся в фоновом режиме. Это негативно отражается на производительности браузера и потребляет энергию аккумулятора на мобильных устройствах. Такая обработка активности в фоновых вкладках совершенно ни к чему. Идея состоит в том, чтобы установить максимальный лимит вычислительных ресурсов, которые можно дать фоновому приложению. Реализация плана выглядит следующим образом:

  • У каждого компонента WebView будет бюджет (в секундах) для работы таймеров в фоновом режиме.
  • Таймер не может запуститься, если бюджет отрицательный.
  • После выполнения таймера его время работы вычитается из бюджета.
  • Бюджет автоматически пополняется со временем (на 0,01 с бюджета с каждой секундой реального времени).

Наибольшее опасение вызывали фоновые страницы трёх типов:

  • которые используют таймер для изменения фавикона, как это делает Gmail;
  • которые используют таймеры для воспроизведения звука, например, для звука входящего сообщения в мессенджере (касается практически всех мессенджеров и групповых чатов);
  • только что открытая страница, которая начала загружаться, а пользователь в это время открывает новую вкладку с расчётом, что эта страница загрузится до конца в фоновом режиме.

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

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

Но в реальности оказалось, что нотификации в фоновых приложениях могут приходить с опозданием на несколько минут. Это уже конкретно ломает функциональность таких приложений. Создателям придётся искать способы, как обойти этот встроенный «режим энергосбережения» Chrome. Очевидным кажется приём с постоянным проигрыванием звуком на нулевой громкости. Возможно, они придумают что-нибудь ещё.

Казалось бы, фоновым приложениям нужно всего лишь уменьшить потребление CPU, чтобы уложиться в вычислительный бюджет, который выделяет для них браузер. Но это не выход. В реальности многим приложениям действительно нужно выполнять большой объём работы в фоновом режиме. Например, популярные программы вроде Slack и Discord постоянно синхронизируют каналы, парсят новые сообщения от сотен пользователей в десятках каналов, чтобы определить, когда нужно побеспокоить пользователя нотификацией, а когда не нужно этого делать.

Slack и Discord — не единственные такие программ, есть очень много других веб-приложений, которые активно работают в фоновом режиме. Например, биржи для биткоин-трейдинга в реальном времени. Чтобы проверить новый режим Chrome разработчик одного из таких ресурсоёмких приложений запустил в фоновой вкладке Chrome 56 процесс setInterval с выполнением каждую секунду и фиксацией реального времени выполнения. Вот какое реальное время он зафиксировал в логе:

1002 1003 1000 1012 1001 1965 1962 1089 2078 1832 1071 6917 34402 136717 76192 38682 6030

Как видим, через пять секунд фоновая вкладка начала выбиваться из бюджета, который ей выделил браузер. А через 22 реальных секунды бюджет полностью закончился (задержка ивента на 136 секунд).

То есть теперь на таймеры в веб-разработке вообще нельзя полагаться. Негативные последствия ожидают сайты, которые держат открытые соединения WebSocket.

Разработчики Chrome рекомендуют перенести соответствующие процессы в Service Workers. придётся потрудиться, конечно, переписывая код и решая проблемы совместимости. Но там всё должно работать нормально. Разумеется, до того момента, пока разработчики Chrome не примут решение затормозить и фоновые Service Workers тоже.

Разработчикам таких приложений, которые работают в фоновом режиме, рекомендуется использовать Page Visibility API, чтобы приложение не делало в фоновом режиме работу, которая всё равно будет невидима пользователем.

Другие нововведения в Chrome 56

Официальный релиз стабильной версии Chrome 56 (движок Blink версии 537.36) запланирован на январь 2017 года (ориентировочно 31 января).

В ближайшей официальной версии Chrome 56 разработчики не планируют включать подавление активности в фоновых вкладках. Этот эксперимент продолжится на бета-канале, а после сбора отзывов пользователей его планируют выкатить в Chrome 57 (14 марта 2017 года). Сейчас разработчики обсуждают, какие изменения внести в механизм подавления фоновых вкладок. На странице обсуждения рассматриваются разные варианты исключение: метатеги, закреплённые вкладки, явное разрешение пользователя на показ уведомлений.

Нововведением в Chrome 56 станет то, что он будет по умолчанию считать небезопасными HTTP-страницы, содержащие поле для ввода пароля. Такие страницы будут помечаться заметным красным индикатором.

Со временем подобный индикатор получат все сайты, которые не перешли на HTTPS.

📎📎📎📎📎📎📎📎📎📎