Что такое фоновая вкладка в браузере
Когда вы просматриваете Интернет, когда вы нажимаете на ссылку. Откроется новая ссылка или вкладка. Если вы не хотите, чтобы ваш браузер переключался на ссылку, которая открывается в новой вкладке, вам придется настроить браузер так, чтобы ссылки открывались в фоновом режиме. Таким образом, вы продолжаете оставаться на той же странице, открывая внешние ссылки на новых вкладках.
Открывать новые вкладки в фоновом режиме
Вот как вы можете открывать новые вкладки в фоновом режиме в браузерах Microsoft Edge, Mozilla Firefox, Google Chrome, Internet Explorer и Opera.
Принудительно открывать ссылки в фоновом режиме в Firefox
Принудительно открывать ссылки в фоновом режиме в Chrome
Хром не предлагает никаких простых методов принудительного открытия ссылок в фоновом режиме. Тем не менее, есть несколько разных подходов, которым вы можете следовать и заставить Chrome открывать ссылки в фоновом режиме.
Переместить ссылки на панель вкладок Новая вкладка
Щелкните, чтобы переместить ссылку на веб-страницу и отпустить ее в любом месте панели вкладок. Вы заметите, что ссылка автоматически открывается в новой вкладке. Вы можете переместить вкладку в любое место адресной строки.
Использование расширений Chrome
Принудительно открывать ссылки в фоновом режиме в Microsoft Edge
Вы также можете использовать упомянутые выше расширения Chrome в Microsoft Edge Chromium.
Открытие новых вкладок в фоновом режиме в Internet Explorer
В Internet Explorer, вы можете легко изменить этот параметр, выбрав «Свойства обозревателя»> вкладка «Общие»> кнопка «Вкладки»> снимите флажок «Всегда переключаться на новые вкладки при их создании».
Принудительно открывать ссылки в фоновом режиме в Opera
Откройте Opera> Инструменты> Быстрые настройки> Убедитесь, что установлен флажок Блокировать нежелательные всплывающие окна.
Следующий тип about: config в адресной строке и нажмите Enter. Прокрутите вниз до Целевое назначение.
Реклама грузит процессор и съедает заряд аккумулятора. Блокировщик рекламы — вот самое главное лекарство, от многих описанных тут проблем.
Firefox работает на одноядерном пне с одним потоком, в нём можно включить однопроцессный режим. Тогда потребление памяти будет очень маленьким даже на ПК с 1гб озу. В добавок, в настройках можно установить количество процессов для браузера.
В хроме, а возможно и в яндексе, есть определённые проблемы с аппаратным ускорением на видеокартах. Mozilla лишь в прошлом году убрало аппаратное ускорение для DX9 карт из Firefox, тогда как в хромах его и не было. На DX10 картах аппаратное декодирование видео в хромобраузерах заводится лишь через скрытые настройки, а в лисе автоматом. При этом даже с DX11 картами в хроме есть проблемы.
Если бы гугл хотел, он бы давно прикрутил выдачу видео на ютубе в нужном для браузера кодеке. В лисе и возможно в хромиуме есть настройка, которая просит ютуб и другие сайты отдавать видео в мпег 4 если видеокарта поддерживает ускорение, но… гуглу нужно продвигать свой кодек AV1 для экономии места на серверах и использования более узких каналов связи.
Проблема не только в рекламе. Некоторые сайты и без рекламы не очень эффективно сделаны.
В chromium-based браузерах можно использовать ключ --renderer-process-limit, чтобы ограничивать количество процессов рендереров. Вообще еще есть --single-process, но это скорее отладочный ключ и при этом браузер становится не очень работоспособным.
Тут, как это часто бывает, компромисс между экономией ресурсов и безопасностью. С учетом уязвимостей как в софте, так и в железе, очень хотелось, чтобы данные разных сайтов были изолированы друг от друга.
По поводу декодирования — это странно. В chromium уже давно есть GpuVideoDecoder, который с помощью DXVA декодирует видео. И это работает как на DX9, так и на DX11. Вопрос только в том, о каком кодеке идет речь: h.264 аппаратно поддерживается множеством разных карт, а вот с vp8/vp9 ситуация хуже. Если проблема еще актуальна, то стоит зарепортить баг
У нас в Яндекс.Браузере есть режим энергосбережения, в котором мы разрешаем сайтам играть видео только с помощью аппаратных декодеров, чтобы сэкономить батарейку.
Поставил Яндекс.Браузер (обычный) и декодирование на ютубе завелось с h264ify. На хроме по умолчанию не заводилось, вероятнее всего у них свой чёрный список видеокарт. Аппаратное ускорение для DX9 карт — имел ввиду Композитинг. DX9 карт умеющих аппаратно декодировать h264 в браузере, наверно и не существует.
В лисе однопроцессный режим пока ещё нормально работает. Может быть потом его совсем уберут, но сейчас, для совсем слабых ПК — это очень хорошая возможность ещё пользоваться интернетом.
P.S. Не нашёл где в основных настройках Яндекс.Браузера включить плавную прокрутку.
Планируется ли предоставить пользователю возможность указать, чтобы вкладка нормально работала в фоновом режиме, без замедления и возможности быть убитой?Не думаю, что таких вкладок нужно много — можно, думаю, ограничить конечным числом.
Пример: Вкладка с музыкой или с онлайн-мессенджером. Все понимают, что есть такие ситуации, когда фоновая вкладка на самом деле не фоновая. Если вкладка играет звук или использует real-time connections, например, WebRTC или WebSockets, то она будет нормально работать и в фоновом режиме. То есть речь идет не о том, чтобы сломать всем веб, улучшить метрики и уйти, а о том, чтобы сделать лучше конкретному пользователю, не ухудшив его пользовательский опыт. Вот и хотелось бы узнать конкретные механизмы. И оставят ли пользователю возможность повлиять на решение браузера? Планировалось, что в основе будут ServiceWorker-ы. Выдержка из Background tabs & offscreen frames: further plans:
The work is underway on a set of APIs that developers will be able to use to specify which work needs to be done in the background, similar to what’s possible on Android and iOS. Service Workers will take the central place in this, with their capabilities enhanced by new features like being able to play audio, update page title & favicon, silent push notifications, and more
Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
>Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
Меня именно этот момент и беспокоит. И я надеялся, на то, что автор поста сможет прояснить этот момент. Как минимум о планах в отношении Яндекс.Браузера.
Тут дело в том, что пока не совсем понятно будет ли это так сильно мешать пользователю. Если подумать и представить зачем фоновой вкладке что-то делать, то на ум приходит что-то в духе проигрывания звука, уведомлений, моргания тайтлом, обработки каких-то данных, etc. Планы же состоят не в том, чтобы просто все оторвать, а в том, чтобы дать какие-то понятные API, чтобы делать это более эффективно.
Например, когда-то давным давно сайты могли делать window.open в любой момент, чтобы обратить на себя внимание, потом это придушили, потому что таким подходом стали злоупотреблять. После этого с той же целью стали делать разные моргания тайтла. А сейчас можно отправлять пуши, которые даже более понятны юзеру, потому что требуют явного от него согласия и дают возможность отказаться от получения таких пушей. Вот и в остальных вещах должно быть также. Если вкладка хочет что-то сделать, то пользователь должен дать ей согласие и тогда у нее будет возможность продолжать это делать, может быть даже и в фоне.
Короче говоря такие изменения не должны никак затронуть пользовательский опыт, но будут менять то, как фронтендеры пишут сайты.
Что касается Яндекс.Браузера, то мы не катим бездумно все, что подмёрживаем себе от хромиума. Если наше продуктовое видение будет отличаться и будет потребность у пользователей в том, чтобы давать такую власть фоновым вкладкам, то мы будем думать как это сделать лучше.
Идея, описанная вами, вполне понятна. То, что нужно как-то ограничивать фоновые вкладки, которые могут просто проигрывать анимацию, тратя ресурсы впустую, — вполне разумно. Вопрос в том, нужно ли при этом ломать текущий Вёб полностью или лучше, что бы он хоть как-то работал, пусть в режиме совместимости, по запросу пользователя?
Идея с API — это хорошо, особенно для новых сайтов, но если через API можно будет отказаться от «заморозки» без участия пользователя, то некоторые могут просто добавить вызов такого API на сайт, что бы он работал как раньше. При этом, API не решит проблему старых сайтов, которые эта схема может сломать. А вот список пользователя с доменами-исключениями — решит.
Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей.
Просто вот это:
>…будут менять то, как фронтендеры пишут сайты.
без пользовательской системы исключений — как раз и может поломать Вёб, по моему мнению. Хотя и не думаю, что таких сайтов будет очень много.
>…мы не катим бездумно все, что подмёрживаем себе от хромиума.
И это — замечательно.
Вопрос в том, нужно ли при этом ломать текущий Вёб полностью или лучше, что бы он хоть как-то работал, пусть в режиме совместимости, по запросу пользователя?
Такие фичи всегда катятся так, что пользователь может их выключить при желании, как минимум до тех пор пока проходит эксперимент.
Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей
Вполне может быть, что тут тоже будет такая возможность. В качестве примера можно привести флеш. Хром целенаправленно отказывается от него, но делает это относительно небольшими шажками:
Ближайшие изменения в браузере Chrome вряд ли порадуют разработчиков Slack, Discord и других программ, которые работают во вкладках браузера. В бета-версии Chrome 56 реализован новый механизм оптимизации таймеров для фоновых вкладок.
На первый взгляд, инициатива разработчиков выглядит хорошим делом. В сентябрьском плане внедрения (Intent to Implement) объясняются причины, которые сподвигли разработчиков на такое решение.
Главная причина — некоторые плохо спроектированные приложения (например, скрипты аналитики и javascript-реклама) потребляют много ресурсов CPU, хотя находятся в фоновом режиме. Это негативно отражается на производительности браузера и потребляет энергию аккумулятора на мобильных устройствах. Такая обработка активности в фоновых вкладках совершенно ни к чему. Идея состоит в том, чтобы установить максимальный лимит вычислительных ресурсов, которые можно дать фоновому приложению.
Реализация плана выглядит следующим образом:
- У каждого компонента WebView будет бюджет (в секундах) для работы таймеров в фоновом режиме.
- Таймер не может запуститься, если бюджет отрицательный.
- После выполнения таймера его время работы вычитается из бюджета.
- Бюджет автоматически пополняется со временем (на 0,01 с бюджета с каждой секундой реального времени).
Наибольшее опасение вызывали фоновые страницы трёх типов:
Проблему с загрузкой страниц решили так, что бюджет таймера вообще не распространяется на загрузку страниц, то есть они фактически не считаются фоновыми.
Казалось бы, разработчики всё продумали и всё отлично. Небольшое замедление с приходом нотификаций в мессенджере — не такая уж большая проблема.
Но в реальности оказалось, что нотификации в фоновых приложениях могут приходить с опозданием на несколько минут. Это уже конкретно ломает функциональность таких приложений. Создателям придётся искать способы, как обойти этот встроенный «режим энергосбережения» Chrome. Очевидным кажется приём с постоянным проигрыванием звуком на нулевой громкости. Возможно, они придумают что-нибудь ещё.
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 (движок Blink версии 537.36) запланирован на январь 2017 года (ориентировочно 31 января).
В ближайшей официальной версии Chrome 56 разработчики не планируют включать подавление активности в фоновых вкладках. Этот эксперимент продолжится на бета-канале, а после сбора отзывов пользователей его планируют выкатить в Chrome 57 (14 марта 2017 года). Сейчас разработчики обсуждают, какие изменения внести в механизм подавления фоновых вкладок. На странице обсуждения рассматриваются разные варианты исключение: метатеги, закреплённые вкладки, явное разрешение пользователя на показ уведомлений.
Сегодня мы готовы объявить, что версия Яндекс.Браузера, над которой мы работаем в рамках проекта «Кусто», вливается в его основную бету. Знаем, что здесь многие ею пользуются, и теперь у вас появится возможность переключаться между новым режимом и традиционным интерфейсом.
Мы хотим, чтобы участникам бета-тестирования Яндекс.Браузера было удобно отслеживать изменения в проекте «Кусто» и не приходилось пользоваться для этого двумя разными сборками. А сейчас я расскажу о результатах нашей работы над новым браузером за последний месяц.
Отключение группировки вкладок
Одной из самых популярных тем, на которую высказались наши пользователи, оказалось расположение вкладок. В бета-версии они еще останутся внизу, но мы прорабатываем разные варианты и продолжаем эксперименты. Рассказать о них мы хотим отдельно. А сегодня хотелось бы затронуть вопрос группировки вкладок. Тем более что многие обращения в поддержку были посвящены именно ей и позволили нам сформировать список приоритетных исправлений.
Об идеологическом обосновании группировки вкладок мы подробно рассказывали в прошлый раз. Сейчас же поделимся с вами статистикой, которая подтолкнула нашу команду к работе над этой возможностью.
Вопреки расхожему мнению большинству пользователей недостаточно двух-трех вкладок для повседневной жизни в сети. Мало того, около 10% из нас открывают под свои задачи более десяти вкладок. А почти 3% используют свыше 20. Например, для меня это обычное рабочее состояние. Вы ведь представляете, что такое два или три десятка открытых вкладок в браузере? Я знаю коллег, у которых бывают открыты сотни вкладок.
Было бы неправильно просто посчитать количество открытых вкладок и на основании этих данных вводить принудительную группировку. Исходя из базовой идеи, что сайты – это приложения, мы изначально ориентировались на группировку по домену, но без проверки принимать решение было нельзя. В частности, могло случайно оказаться, что у пользователей с 20 вкладками открыто 20 разных сайтов, и ни о какой пользе в этом случае речи уже не идет. И вот что мы насчитали:
Результаты показали, что более десяти сайтов открыто у 4% пользователей против 10% для вкладок. О чем это говорит? О том, что группировка действительно имеет смысл для многих пользователей, но далеко не для всех. Мы с самого начала понимали, что есть риск усложнить жизнь тем, у кого открыто лишь несколько вкладок. И ваши обращения после запуска альфы подтвердили опасения.
Самым простым решением была бы опция в настройках, позволяющая включать/выключать группировку. Но остается вопрос: должна ли группировка работать по умолчанию? Стоит ли нам ориентироваться на тех, кто одновременно работает с двумя-тремя сайтами? И где проходит та грань, за пределами которой группировка точно нужна? Подобные вопросы подстегивают нашу дальнейшую работу. Среди нескольких вариантов мы, например, рассматриваем алгоритм, при котором группировка предлагалась бы пользователям, преодолевшим порог в N одновременно открытых доменов.
Фоновые вкладки
Другая проблема, получившая подтверждение благодаря обращениям в поддержку, касается открытия вкладок в фоне – когда вы через контекстное меню ссылки выбираете «Открыть в новой вкладке» (или кликаете средней кнопкой мыши). В нашей альфе такие страницы порой открывались внутри неактивных групп, и было совершенно не очевидно, где ее теперь искать.
Казалось бы, фоновые вкладки успешно выделены, найти их нетрудно. Решили собрать сборку и протестировать наше решение на добровольцах. С кружком проблем не возникло. Фоновые вкладки стали визуально заметнее. Проблема затаилась с другой стороны, причем до поры до времени она успешно маскировалась неудобством поиска вкладок. Заключается она вот в чем. Если фоновая вкладка открывается в неактивной группе, то нужно совершить два клика, чтобы добраться до контента. Это на целый клик больше, чем мы привыкли.
Единственный разумный, не добавляющий кликов вариант, который мы придумали, заключается во временном отключении группировки для подобных вкладок. Вы открываете фоновую вкладку, но она не попадает в группу, а располагается рядом с ней до тех пор, пока не будет просмотрена или не будет раскрыта группа.
Порядок активации вкладок
Еще одним направлением для нас стала работа над порядком открытия вкладок. Напомним, что на данный момент после закрытия активной вкладки фокус переходит на вкладку справа (стандартная логика в Chromium). Не самая идеальная механика, мы согласны. Но особых проблем она не вызывала ровно до того момента, пока не появилась группировка. Теперь же пользователи столкнулись с ситуацией, когда после закрытия самой правой вкладки активной в группе становилась вкладка из совершенно другой группы. Воспринимается это не так легко.
Поэтому в бета-версии мы реализовали новую, экспериментальную логику, хорошо знакомую многим пользователям старой Оперы. Активной становится не вкладка справа, а та, что использовалась ранее. Это еще не окончательный вариант, но было бы интересно узнать мнение сообщества уже сейчас
На всякий случай мы добавили в настройки возможность выбрать логику.
Оптимизация для слабых компьютеров
Графические эффекты, применяемые в новом Яндекс.Браузере, достаточно хорошо (сделаем скидку на то, что еще вчера это была альфа) работают на компьютерах с современными видеоускорителями (условно маркируемыми как HD). Однако существует оборудование, которое в отличие от нас совершенно не радо плавным размытиям и прочим графическим изыскам в браузере. Закрывать на это глаза мы не хотим, поэтому постоянно занимаемся поисками способов оптимизации.
На первом этапе (то есть уже в текущей бете) Яндекс.Браузер будет отключать блюр и заменять его белой заливкой с opacity 0.9 для устройств со слабыми видеокартами (GMA). Компромиссный вариант. Не слишком эффектно, но уже можно работать.
Есть еще третья категория. Это самые проблемные видеокарты, которые могут быть даже забанены на уровне Chromium, либо у браузера нет доступа для работы с такими устройствами. Подобное оборудование не справится даже с простейшим opacity, так что в этом случае мы будем использовать простую белую подложку.
Это то, что мы уже успели сделать для первой беты. В будущих релизах постараемся рассказать о других наших планах, направленных на увеличение производительности.
Мы с самого начала не скрывали, что не планируем вырезать закладки из браузера. Однако и просто копировать их из текущего традиционного интерфейса в новый не стали. Обычная панель закладок, размещенная под адресной строкой, совершенно не вписывается в новый интерфейс. И дело не в оформлении. Нет большой проблемы в том, чтобы сделать ее полупрозрачной (хотя подобное решение и привело бы к сложностям в работе с прозрачностью в некоторых ситуациях). И даже не в том, что у нас нет классической адресной строки в этом месте. Еще одна строка в шапке – это опять-таки путь к нагромождению панелей и «полосатости» браузера.
В текущих версиях Яндекс.Браузера есть достаточно популярная среди пользователей опция, которая позволяет отображать закладки только по клику в адресной строке. Таким образом, закладки находятся на расстоянии одного клика и при этом не занимают место, когда в них нет потребности. Именно этот опыт мы и применили в новом интерфейсе, переместив закладки на Изнанку и новую вкладку.
Переключения между Кусто и традиционным интерфейсом
Как было сказано в самом начале, новая бета-версия Яндекс.Браузера позволяет каждому выбрать тот интерфейс, в котором ему комфортно работать. Соответствующий пункт можно найти в главном меню.
Мы не устаем повторять, что отправленные нам багрепорты (или просто комментарии на Хабре) имеют значение. Мы слушаем и реагируем. Порой не так молниеносно, как нам всем бы хотелось, но это действительно работает.
Кое-что еще. Появление Кусто в бета-канале не значит, что через шесть недель все пользователи Яндекс.Браузера вдруг обновятся и получат новый интерфейс. Не стоит этого опасаться. Работа над новым браузером будет продолжаться в рамках беты. Мы будем экспериментировать с идеями и прислушиваться к реакции сообщества. Стабильная версия Яндекс.Браузера будет эволюционировать постепенно, без неожиданных потрясений. Какие-то идеи из Кусто могут проявиться там раньше, чем другие. А с вашей помощью этот процесс станет еще более плавным.
Читайте также: