Ближайшие изменения в браузере Chrome вряд ли порадуют разработчиков Slack, Discord и других программ, которые работают во вкладках браузера. В бета-версии Chrome 56 реализован новый механизм оптимизации таймеров для фоновых вкладок.
На первый взгляд, инициатива разработчиков выглядит хорошим делом. В сентябрьском плане внедрения (Intent to Implement) объясняются причины, которые сподвигли разработчиков на такое решение.
Главная причина — некоторые плохо спроектированные приложения (например, скрипты аналитики и javascript-реклама) потребляют много ресурсов CPU, хотя находятся в фоновом режиме. Это негативно отражается на производительности браузера и потребляет энергию аккумулятора на мобильных устройствах. Такая обработка активности в фоновых вкладках совершенно ни к чему. Идея состоит в том, чтобы установить максимальный лимит вычислительных ресурсов, которые можно дать фоновому приложению.
Реализация плана выглядит следующим образом:
- У каждого компонента WebView будет бюджет (в секундах) для работы таймеров в фоновом режиме.
- Таймер не может запуститься, если бюджет отрицательный.
- После выполнения таймера его время работы вычитается из бюджета.
- Бюджет автоматически пополняется со временем (на 0,01 с бюджета с каждой секундой реального времени).
Разработчики решили, что торможение фоновых вкладок никак не помешает пользователю. Вкладки с активным звуком в Chrome не считаются фоновыми, так что на них нововведение никак не скажется.
Наибольшее опасение вызывали фоновые страницы трёх типов:
- которые используют таймер для изменения фавикона, как это делает Gmail;
- которые используют таймеры для воспроизведения звука, например, для звука входящего сообщения в мессенджере (касается практически всех мессенджеров и групповых чатов);
- только что открытая страница, которая начала загружаться, а пользователь в это время открывает новую вкладку с расчётом, что эта страница загрузится до конца в фоновом режиме.
Предварительные тесты показали, что реализация торможения фоновых вкладок не поломала функциональность Gmail, хотя затормозила некоторые нотификации в тех мессенджерах и программах, которые активно используют ресурсы CPU. В целом, реализация работала хорошо и действительно снизила энергопотребление и увеличила быстродействие браузера в активных вкладках.
Проблему с загрузкой страниц решили так, что бюджет таймера вообще не распространяется на загрузку страниц, то есть они фактически не считаются фоновыми.
Казалось бы, разработчики всё продумали и всё отлично. Небольшое замедление с приходом нотификаций в мессенджере — не такая уж большая проблема.
Но в реальности оказалось, что нотификации в фоновых приложениях могут приходить с опозданием на несколько минут. Это уже конкретно ломает функциональность таких приложений. Создателям придётся искать способы, как обойти этот встроенный «режим энергосбережения» 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, чтобы приложение не делало в фоновом режиме работу, которая всё равно будет невидима пользователем.
var doVisualUpdates = true;
document.addEventListener('visibilitychange', function(){
doVisualUpdates = !document.hidden;
});
Такой приём позволяет снизить загрузку CPU на 75%
Другие нововведения в Chrome 56
Официальный релиз стабильной версии Chrome 56 (движок Blink версии 537.36) запланирован на январь 2017 года (ориентировочно 31 января).
В ближайшей официальной версии Chrome 56 разработчики не планируют включать подавление активности в фоновых вкладках. Этот эксперимент продолжится на бета-канале, а после сбора отзывов пользователей его планируют выкатить в Chrome 57 (14 марта 2017 года). Сейчас разработчики обсуждают, какие изменения внести в механизм подавления фоновых вкладок. На странице обсуждения рассматриваются разные варианты исключение: метатеги, закреплённые вкладки, явное разрешение пользователя на показ уведомлений.
Нововведением в Chrome 56 станет то, что он будет по умолчанию считать небезопасными HTTP-страницы, содержащие поле для ввода пароля. Такие страницы будут помечаться заметным красным индикатором.
Со временем подобный индикатор получат все сайты, которые не перешли на HTTPS.
Комментарии (78)
APLe
25.01.2017 12:38+91). Ура, у хрома появляется функциональность Оперы конца прошлого десятилетия! С поправкой на современные технологии, конечно.
Я, помнится, очень удивился, когда уходя с Оперы, выяснил, что другие браузеры не отключают проигрывание flash и гифок в фоновых вкладках.
2). А что мешает дать возможность пользователю отключать подавление на некоторых сайтах? Страниц, которым действительно нужно постоянно делать что-то в фоне, не так много.Murmurianez
25.01.2017 20:30+2Юзабилити. Как вы обычному человеку будете объяснять почему нотификации из VK не вовремя приходят? Туториал при заходе на сайт выводить? Делать больше нефиг. Оптимизации браузера не должны беспокоить пользователя.
vilky
26.01.2017 08:36Получать нотификации через браузер — это так же логично, как встроенный в браузер почтовый клиент. То есть нифига не логично. А уж если удобство получения нотификаций вступает в конфликт с удобством веб-сёрфинга (активного поиска новой информации)…
devpreview
26.01.2017 16:47Получать нотификации через браузер — это так же логично, как встроенный в браузер почтовый клиент.
Для пользователей интернета 2000-х — не логично. Для «только что подключившихся» — вполне логично.
APLe
26.01.2017 13:36+2По аналогии с заблокированными по умолчанию всплывающими окнами, можно показывать уведомление «Эта страница потребляла много ресурсов в фоновом режиме, поэтому мы её усыпили. Разрешить фоновую работу для этой страницы?»
amarao
25.01.2017 13:04+6Берём и пускаем рекламу с неслышным звуком (т.е. volume =0, сплошные нули в wav'е). Получаем приоритет для выполнения чего попало. Пользователя раздражает только лишняя иконка в табе, но в целом — никаких неудобств.
maniacscientist
25.01.2017 13:12+8>выполнения чего попало
Ага, скрытый канвас с вебгл и шейдером, добывающим криптовалюту
spmbt
25.01.2017 18:46Минимального циклического аудиоплеера с данными в Base64 даже достаточно.
В следующих рекомендациях по оптимизации сайтов это будет одним из пунктов: ).aamonster
25.01.2017 21:45+1Ну, кто как, а я обращу внимание на иконку звука в таб баре — и сайт отправится в чёрный список за компанию с прочими, кто без спроса включает звук.
artskep
25.01.2017 18:51Мне все это напоминает давний квест с фоновыми задачами на iOS.
Там тоже использовали звук тишины, мелкие загрузки, что-то еще (уже не помню).
В конце концов это все равно резалось рано или поздно.
Я уже не первый год вижу, что Гугл идет по пути Эппла в отношении песочниц. Т.е. ужесточение требований.
Так что я не удивлюсь, если скоро запретят вообще фоновые задачи, и скажут, что «хотите асинхронности — делайте push message с сервера». И да, 'push' только через авторизованный сервер и API с подпиской (чтобы бороться со спамерами и прочим).
ganzmavag
25.01.2017 13:18-1Vivaldi с их возможностью выгрузить фоновые вкладки вспомнился сразу. Хотя мне этот функционал безразличен: годы, проведенные на компе с малым объемом оперативки, приучили вкладки закрывать сразу же. Когда их много, начинаю путаться.
Ktulkhu_Triediniy
25.01.2017 15:01+1Сам Хром уже достаточно давно этим занимается на ПК с малым количеством ОЗУ.
evilrussian
25.01.2017 13:19-1Когда-нибудь разработчики хромиум-браузеров наконец-то сделают настройки прокси/проксей с white/black листами? Для чего надо было выпиливать данную настройку?
Barafu
25.01.2017 13:52+1Зачем? Каждому второму этот функционал не нужен. А для тех, кому нужен, есть сразу несколько отличных расширений, обеспечивающих его с головой.
medkit
26.01.2017 22:33Многие браузеры (в том числе и хром) поддерживают Proxy Auto Config файлы.
Нужно лишь написать код на javascript для выбора прокси с учётом белого/чёрного списка.
k12th
25.01.2017 13:30Я думал, что этот механизм уже работает, потому что заметил, например, что YouTube не переключается на следующий ролик в плейлисте, если вкладка в фоне. Хуже того, этим страдает и Spotify, правда, не постоянно.
Надеюсь, эту "оптимизацию" можно будет отключать.
voidMan
25.01.2017 13:55Я думаю, в случае Youtube, это фича самого сервиса, а не браузера.
gimntut
25.01.2017 16:21+7YouTube не включает видео на фоновой вкладке специально, чтобы такие как я могли прокликать десяток ссылок на видеоролики средней кнопкой мыши без риска, что все видео начнут проигрываться одновременно. Ролик запускается лишь после открытия его вкладки.
yefrem
25.01.2017 13:33+1По-моему проще и логичней было бы внедрить функционал по типу расширений-суспендеров, намного понятней для пользователя и достаточно эффективно. А так выглядит очень спорно, еще и разработчикам резко нужно переделывать приложения под него.
nikitastaf1996
25.01.2017 13:37+1Очевидным кажется приём с постоянным проигрыванием звуком на нулевой громкости
Ужас.И поломать значок звука.Супер.
mukizu
25.01.2017 13:42В качестве дополнения\пояснения от разработчиков:
https://news.ycombinator.com/item?id=13473644
Caelwyn
25.01.2017 13:44Firefox уже лет десять тормозит таймеры в фоновых вкладках. В первый раз столкнулся с этим, когда он ломал чат который подгружал новые сообщения в setInterval.
ffs
25.01.2017 13:55+1Не знаю, не знаю, и дискорд, и почта и такое другое работает отлично.
DarkByte
26.01.2017 18:18+1Наверное потому что они подгружают новую информацию с использованием long poll запросов. setInterval для загрузки новых сообщений — это почти как meta refresh и iframe, работает конечно, но как то не современно.
olafnew
25.01.2017 14:34Ура! Может хоть это сподвигнет развивать нормально Standalone приложения, а не браузерные приложения.
Вообще — идея полной работы только в браузере — в многих случаях откровенно неудобна. Хороший пример — Facebook@Work, и его чат, который работает только в браузере. Из-за этого невозможно полностью перейти только на него, т.к. браузерные приложения откровенно неудобны в некоторых сценариях работы за ПК.orcy
25.01.2017 15:41+4> Ура! Может хоть это сподвигнет развивать нормально Standalone приложения, а не браузерные приложения.
Это будет веб-приложение завернутое в электрон и предоставленное вам как standalone. Как можно легко угадать, это только ухудшит производительность системы.Vasia529
25.01.2017 17:31+1Более того, и у слака, и у дискорда приложения именно такие :)
inoyakaigor
26.01.2017 12:27Не знаю как у Дискорда, но у Слака есть jabber транспорт и поэтому я пользуюсь старым добрым QIP для слака и знаете, это, как минимум, решает проблему сохранения истории сообщений (естественно на бесплатном аккаунте)
ilyamodder
25.01.2017 14:37+3Например, популярные программы вроде Slack и Discord постоянно синхронизируют каналы, парсят новые сообщения от сотен пользователей в десятках каналов, чтобы определить, когда нужно побеспокоить пользователя нотификацией, а когда не нужно этого делать.
Может, это стоит сделать на сервере и присылать клиенту минимум информации для непосредственно уведомления?
Pinsky
25.01.2017 14:38Ждем, когда флэш начнет блочится активнее. 55я версия уже начала, но хочется дальнейшего прогресса.
sumanai
25.01.2017 16:01+1А может просто удалить? Я у себя давно флеш удалил, не жалею. Правда у меня FF, не знаю, как с этим в хроме.
dom1n1k
25.01.2017 17:09Именно удалил или отключил? Я вот отключил и некоторые видеохостинги (rutube кажется и еще какие-то новостные сайты) перестали работать — видеоплейер определяет, что флеш как будто бы есть и грузит флешевую версию, которая естественно не работает. У youtube таких проблем нет.
sumanai
25.01.2017 17:29+1Удалил. Везде определяется, что флеша нет, но в подавляющем большинстве случаев ничего полезного там быть не могло, так что только рад.
Только что проверил- rutube работает.
darthmaul
25.01.2017 15:19Надеюсь это можно будет отключить. Неужели так много людей с железом пятнадцатилетней давности пользуются Хромом? На 8-ми летней раочей станции ещё ни разу не сталкивался с падением производительности в браузере.
k12th
25.01.2017 15:41С производительностью вряд ли что-то заметное случится, все-таки не антивирусы запускаем, а вот батарею ноута жрать может.
Aingis
26.01.2017 17:05У меня пятилетнее железо, причём с топовым процессором. Так вот я заметил, что тормозит видео из-за такой казалось бы безобидной фоновой вкладки, жрущей 35% процессора. Кажется, это был Циан с баннером.
P.S. ТМ тоже «молодцы», страницы Хабра и ГТ периодически вылетают на iOS с сообщением «сбой на странице, она была перезагружена». Видимо, пора резать рекламу…
Delics
25.01.2017 15:22-1Почему атака идет просто на все таймеры без разбора?
Тормозят ведь не сами таймеры, а код, который в них выполняется. Лучше бы анализировали, кто постоянно выполняет «тяжелый» код и далее пользователь мог бы выбрать, дать такой странице ресурсы или нет.
А сейчас — какое-то «ленивое решение» получилось.k12th
25.01.2017 15:43+1Решение достойное 2017 года, домохозяйка-френдли. Неквалифицированный пользователь пугается любого выбора.
Iv38
25.01.2017 15:50+1Так примерно оно и сделано. У таймеров есть бюджет. Если приложение выполняет тяжелый код, оно израсходует бюджет быстрее и будет приторможено. Более легкие скрипты могут не успеть израсходовать бюджет (он ведь пополняется) и будут получать меньше задержек или не будут получать их вообще.
simple-simple
25.01.2017 17:04К сожалению, это наверное достаточно сложно — оптимально распределить приорететы выполняемых процессов. Посмотрим что из этого выйдет. Может в будущем придумают более изящное решение. Наука и техника не стоят на месте )
Jogger
25.01.2017 15:52+3Хорошее нововведение. Ещё бы что-то с потреблением памяти сделали… А то когда хром отожрал 100% памяти уже всё равно, понизил он приоритет вкладкам или нет — всё равно тормозить об своп-файл будет.
vdasus
25.01.2017 21:54-2Хреновое нововведение… Любое решение, которое доставляет неудобство людям в угоду железу (батарейкам) это в корне плохо. Пусть развивают алгоритмы, железо, а не «а теперь ты подождешь потому, что мы не умеем расходовать твою батарейку»…
Jogger
25.01.2017 22:09Не знаю, кому как, а мне это решение доставит удобство (конечно, при условии что я начну активно пользоваться хромом).
Free_ze
26.01.2017 14:11+1Вы считаете, что плохо серфить лучше, чем вообще не серфить? Подобное вынудит разработчиков оптимизировать свои алгоритмы, это ж идеально!
DexterHD
25.01.2017 18:10+8Ну вот, за исправление ошибок фронтендщиков взялись разработчики браузеров, рано или поздно это должно было случится. Нельзя же вечно говнокодить на JS и думать только о новых фреймворках, и о том как прикрутить вот эту модную фичу из stage-0 («ехал babel через babel видит babel babel babel...»)
Deosis
26.01.2017 08:34Как только пользователи завалят популярные сайты потоком… негатива, разработчики быстро научатся отключать тяжелые операции, если вкладка в фоне. Или добавят новые хаки.
quwy
26.01.2017 03:41+2Давно пора было что-то такое сделать. Уже не один раз замечал, что процесcор на компьютере рядового интернет-юзера перманентно загружен на ~100%. Скрипткодеры совсем связь с реальностью потеряли, пора их осадить. И чем жестче, тем лучше.
handicraftsman
26.01.2017 08:54А если это, скажем, какой-нибудь Cookie Clicker, у которого нет музыки, или что-то с отключенным/отсутствующим звуком? Нет, это определённо надо сделать отключаемым, причём для каждой вкладки, а не для всех сразу.
lamo4ok
26.01.2017 10:42Честно говоря, не совсем удачные примеры, на которые еще и упор делается, это я про Discord и Slack — и тот и другой имеют нативные клиенты, и как-то лично мне проще пользоваться именно ими, так что проблемы в конкретно их случае вообще не видно. А вот различные социальные сети — это да, держать их в закрепленных вкладках не вариант, приложений нативных они не выпускают. По крайней мере — пока что :)
isden
26.01.2017 11:10«Нативный» клиент того же Слака — это, грубо говоря, браузер (в котором работает все та же веб-версия), завернутый в отдельное приложение.
lamo4ok
26.01.2017 11:29+1Не вопрос, что это меняет в моем комментарии?
isden
26.01.2017 11:32Это не «нативные» клиенты же. Точно так же можно отцепить вкладку от браузера (или поставить другой браузер) и там запустить.
lamo4ok
26.01.2017 13:20Вы какую-то чушь пишете — то, что софт использует тот или иной движок, не делает его ненативным. Это отдельно взятое приложение, со всеми типичными признаками отдельного приложения, не зависящее от уже установленных и вообще браузеров на машине.
Free_ze
26.01.2017 14:15Это отдельно взятое приложение, со всеми типичными признаками отдельного приложения
..., что не делает его нативным.lamo4ok
26.01.2017 14:46Попробуйте тогда привести свое определение нативности приложения.
Free_ze
26.01.2017 15:14API-вызовы системы клиентским кодом, без прослоек в виде браузеров и других исполняющих сред, очевидно же. (фреймворки и библиотеки, с которыми клиентский код линкуется не считаются).
Java-софт для Windows не нативен.
Java-софт для Android — нативен.
Phonegap-софт для Android — не нативен.
JavaScript-софт для ChromeOS — нативен.lamo4ok
26.01.2017 15:21Вы понимаете, что в общем-то ведете речь с точки зрения разработчика, тогда как в посте речь изначально о пользователях?
Free_ze
26.01.2017 15:28+1Да, согласен, я погорячился. Но нативность здесь не играет роли, речь должна идти о standalone'овости. С точки зрения пользователя нативность — это внешний вид и поведение.
lamo4ok
27.01.2017 03:40Я главным образом вообще о том писал, что конкретно приведенные примеры в посте могут быть заменены отдельными приложениями, которые поставляют сами разработчики, и я не вижу причин этого не делать, если честно, зачем в браузере держать то, что можно использовать отдельно — это удобнее в 95% случаев.
vikarti
26.01.2017 17:35Java-софт для Sailfish? Java-софт для BBOS 10? (в обоих случаях там имитируется Android'ная JVM поверх ну совсем другого ядра)
Unity-софт под iOS и Android (если нативен то собственно почему? только из-за того есть компилятор IL в C++ и за собой таскается половина от Mono)? Да и GUI обычно канонам платформы… не следует.
Java-софт на Chrome OS? А если учесть https://sites.google.com/a/chromium.org/dev/chromium-os/chrome-os-systems-supporting-android-apps?
Linux-софт на Windows 10 с Subsystem for Linux?
Win32 софт на Windows 7(и Windows 10)?
А в чем отличие двух предыдущих пунктов кроме того что соответствующая подсистема включена по умолчанию и куча софта в составе самой ОС ее используют? (при этом API ядра все равно используется не напрямую (если не брать в расчет оптимизации) и есть и Native API
приложения под Win3.1 под OS/2 со встроенным модулем совместимости (который работал лучще и стабильнее чем сам Win3.1)
Kastrulya0001
26.01.2017 11:19Жаль только, что они слишком запрятали кнопку отключения этих «фичей». Я использую примерно 10-15 вкладок одновременно и предпочитаю, чтобы они всегда висели фоном и не уходили в сон, для этого я даже память компа увеличил.
Kehit
26.01.2017 12:38А как-нибудь можно отключить функционал «отключения» вкладок, который реализован сейчас у хрома? Крайне не приятная штука.
1514m
27.01.2017 02:35Эта функция не слишком отличается от того же doze/greenify на android. Для оповещений вроде есть отдельное api типа gms, их можно кинуть в исключения. Все прочее усыпить.
Color
Закрепленные вкладки тоже считаются фоновыми? Насколько я понимаю — нет. Если я прав, то это хорошее решение для подобных сервисов, если учесть, что люди, их использующие, и так все время держат их открытыми.
Костыль, но минимальный
Алсо, исключения бы все решили