Comments 32
в 2020 году планируют сделать так: даем вкладке загрузиться и если она фоновая, она ничего не будет делать.
Непонятно, зачем ждать 2020 и почему это не было сделано с самого начала?
Когда в 57 хроме начали троттлить таймеры, то частично сломали веб, потому что веб-разработчики не ожидали такого поворота, хотя чисто по стандарту нет гарантии того, что setTimeout вызовет функцию ровно через указанное время. Так что такие изменения должны осуществляться плавно, чтобы сайты успели к этому подготовиться.
Мне кажется, что так не было сделано сразу потому что раньше проблема стояла не так остро. Интернет был другой, не было 3d css, не было html5 video. Компьютеры были слабые, интернет медленный. Сайты разрабатывались с учетом всех этих ограничений. А сейчас ресурсов очень много и как-то уже перестали волноваться о проблемах эффективного их использования. Вот и пришла пора закручивать гайки.
Мне кажется, что так не было сделано сразу потому что раньше проблема стояла не так остро. Интернет был другой, не было 3d css, не было html5 video. Компьютеры были слабые, интернет медленный. Сайты разрабатывались с учетом всех этих ограничений. А сейчас ресурсов очень много и как-то уже перестали волноваться о проблемах эффективного их использования. Вот и пришла пора закручивать гайки.
UFO just landed and posted this here
Реклама грузит процессор и съедает заряд аккумулятора. Блокировщик рекламы — вот самое главное лекарство, от многих описанных тут проблем.
Firefox работает на одноядерном пне с одним потоком, в нём можно включить однопроцессный режим. Тогда потребление памяти будет очень маленьким даже на ПК с 1гб озу. В добавок, в настройках можно установить количество процессов для браузера.
В хроме, а возможно и в яндексе, есть определённые проблемы с аппаратным ускорением на видеокартах. Mozilla лишь в прошлом году убрало аппаратное ускорение для DX9 карт из Firefox, тогда как в хромах его и не было. На DX10 картах аппаратное декодирование видео в хромобраузерах заводится лишь через скрытые настройки, а в лисе автоматом. При этом даже с DX11 картами в хроме есть проблемы.
Если бы гугл хотел, он бы давно прикрутил выдачу видео на ютубе в нужном для браузера кодеке. В лисе и возможно в хромиуме есть настройка, которая просит ютуб и другие сайты отдавать видео в мпег 4 если видеокарта поддерживает ускорение, но… гуглу нужно продвигать свой кодек AV1 для экономии места на серверах и использования более узких каналов связи.
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 ситуация хуже. Если проблема еще актуальна, то стоит зарепортить баг
У нас в Яндекс.Браузере есть режим энергосбережения, в котором мы разрешаем сайтам играть видео только с помощью аппаратных декодеров, чтобы сэкономить батарейку.
В chromium-based браузерах можно использовать ключ --renderer-process-limit, чтобы ограничивать количество процессов рендереров. Вообще еще есть --single-process, но это скорее отладочный ключ и при этом браузер становится не очень работоспособным.
Тут, как это часто бывает, компромисс между экономией ресурсов и безопасностью. С учетом уязвимостей как в софте, так и в железе, очень хотелось, чтобы данные разных сайтов были изолированы друг от друга.
По поводу декодирования — это странно. В chromium уже давно есть GpuVideoDecoder, который с помощью DXVA декодирует видео. И это работает как на DX9, так и на DX11. Вопрос только в том, о каком кодеке идет речь: h.264 аппаратно поддерживается множеством разных карт, а вот с vp8/vp9 ситуация хуже. Если проблема еще актуальна, то стоит зарепортить баг
У нас в Яндекс.Браузере есть режим энергосбережения, в котором мы разрешаем сайтам играть видео только с помощью аппаратных декодеров, чтобы сэкономить батарейку.
Поставил Яндекс.Браузер (обычный) и декодирование на ютубе завелось с h264ify. На хроме по умолчанию не заводилось, вероятнее всего у них свой чёрный список видеокарт. Аппаратное ускорение для DX9 карт — имел ввиду Композитинг. DX9 карт умеющих аппаратно декодировать h264 в браузере, наверно и не существует.
В лисе однопроцессный режим пока ещё нормально работает. Может быть потом его совсем уберут, но сейчас, для совсем слабых ПК — это очень хорошая возможность ещё пользоваться интернетом.
P.S. Не нашёл где в основных настройках Яндекс.Браузера включить плавную прокрутку.
В лисе однопроцессный режим пока ещё нормально работает. Может быть потом его совсем уберут, но сейчас, для совсем слабых ПК — это очень хорошая возможность ещё пользоваться интернетом.
P.S. Не нашёл где в основных настройках Яндекс.Браузера включить плавную прокрутку.
Вот оно — то о чём я упоминал developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API
В лисе по умолчанию включено, и естественно на ютубе не работает и никогда работать не будет. Фактически, этот API заменяет ваш энергосберегающий режим в плане декодирования видео. Но так как в кодек AV1 вкинуто куча сил и времени, я даже не знаю, что может заставить гугл добавить этот функционал в ютуб.
В лисе по умолчанию включено, и естественно на ютубе не работает и никогда работать не будет. Фактически, этот API заменяет ваш энергосберегающий режим в плане декодирования видео. Но так как в кодек AV1 вкинуто куча сил и времени, я даже не знаю, что может заставить гугл добавить этот функционал в ютуб.
Планируется ли предоставить пользователю возможность указать, чтобы вкладка нормально работала в фоновом режиме, без замедления и возможности быть убитой?
Не думаю, что таких вкладок нужно много — можно, думаю, ограничить конечным числом.
Пример: Вкладка с музыкой или с онлайн-мессенджером.
Не думаю, что таких вкладок нужно много — можно, думаю, ограничить конечным числом.
Пример: Вкладка с музыкой или с онлайн-мессенджером.
Все понимают, что есть такие ситуации, когда фоновая вкладка на самом деле не фоновая. Если вкладка играет звук или использует real-time connections, например, WebRTC или WebSockets, то она будет нормально работать и в фоновом режиме. То есть речь идет не о том, чтобы сломать всем веб, улучшить метрики и уйти, а о том, чтобы сделать лучше конкретному пользователю, не ухудшив его пользовательский опыт.
Вот и хотелось бы узнать конкретные механизмы. И оставят ли пользователю возможность повлиять на решение браузера?
Планировалось, что в основе будут ServiceWorker-ы. Выдержка из Background tabs & offscreen frames: further plans:
Но нужно следить за апдейтами в блоге developers.google.com/web/updates. Про все серьезные закручивания гаек там точно пишут.
Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
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
Но нужно следить за апдейтами в блоге developers.google.com/web/updates. Про все серьезные закручивания гаек там точно пишут.
Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
>Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
Меня именно этот момент и беспокоит. И я надеялся, на то, что автор поста сможет прояснить этот момент. Как минимум о планах в отношении Яндекс.Браузера.
Меня именно этот момент и беспокоит. И я надеялся, на то, что автор поста сможет прояснить этот момент. Как минимум о планах в отношении Яндекс.Браузера.
Тут дело в том, что пока не совсем понятно будет ли это так сильно мешать пользователю. Если подумать и представить зачем фоновой вкладке что-то делать, то на ум приходит что-то в духе проигрывания звука, уведомлений, моргания тайтлом, обработки каких-то данных, etc. Планы же состоят не в том, чтобы просто все оторвать, а в том, чтобы дать какие-то понятные API, чтобы делать это более эффективно.
Например, когда-то давным давно сайты могли делать window.open в любой момент, чтобы обратить на себя внимание, потом это придушили, потому что таким подходом стали злоупотреблять. После этого с той же целью стали делать разные моргания тайтла. А сейчас можно отправлять пуши, которые даже более понятны юзеру, потому что требуют явного от него согласия и дают возможность отказаться от получения таких пушей. Вот и в остальных вещах должно быть также. Если вкладка хочет что-то сделать, то пользователь должен дать ей согласие и тогда у нее будет возможность продолжать это делать, может быть даже и в фоне.
Короче говоря такие изменения не должны никак затронуть пользовательский опыт, но будут менять то, как фронтендеры пишут сайты.
Что касается Яндекс.Браузера, то мы не катим бездумно все, что подмёрживаем себе от хромиума. Если наше продуктовое видение будет отличаться и будет потребность у пользователей в том, чтобы давать такую власть фоновым вкладкам, то мы будем думать как это сделать лучше.
Например, когда-то давным давно сайты могли делать window.open в любой момент, чтобы обратить на себя внимание, потом это придушили, потому что таким подходом стали злоупотреблять. После этого с той же целью стали делать разные моргания тайтла. А сейчас можно отправлять пуши, которые даже более понятны юзеру, потому что требуют явного от него согласия и дают возможность отказаться от получения таких пушей. Вот и в остальных вещах должно быть также. Если вкладка хочет что-то сделать, то пользователь должен дать ей согласие и тогда у нее будет возможность продолжать это делать, может быть даже и в фоне.
Короче говоря такие изменения не должны никак затронуть пользовательский опыт, но будут менять то, как фронтендеры пишут сайты.
Что касается Яндекс.Браузера, то мы не катим бездумно все, что подмёрживаем себе от хромиума. Если наше продуктовое видение будет отличаться и будет потребность у пользователей в том, чтобы давать такую власть фоновым вкладкам, то мы будем думать как это сделать лучше.
Идея, описанная вами, вполне понятна. То, что нужно как-то ограничивать фоновые вкладки, которые могут просто проигрывать анимацию, тратя ресурсы впустую, — вполне разумно. Вопрос в том, нужно ли при этом ломать текущий Вёб полностью или лучше, что бы он хоть как-то работал, пусть в режиме совместимости, по запросу пользователя?
Идея с API — это хорошо, особенно для новых сайтов, но если через API можно будет отказаться от «заморозки» без участия пользователя, то некоторые могут просто добавить вызов такого API на сайт, что бы он работал как раньше. При этом, API не решит проблему старых сайтов, которые эта схема может сломать. А вот список пользователя с доменами-исключениями — решит.
Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей.
Просто вот это:
>…будут менять то, как фронтендеры пишут сайты.
без пользовательской системы исключений — как раз и может поломать Вёб, по моему мнению. Хотя и не думаю, что таких сайтов будет очень много.
>…мы не катим бездумно все, что подмёрживаем себе от хромиума.
И это — замечательно.
Идея с API — это хорошо, особенно для новых сайтов, но если через API можно будет отказаться от «заморозки» без участия пользователя, то некоторые могут просто добавить вызов такого API на сайт, что бы он работал как раньше. При этом, API не решит проблему старых сайтов, которые эта схема может сломать. А вот список пользователя с доменами-исключениями — решит.
Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей.
Просто вот это:
>…будут менять то, как фронтендеры пишут сайты.
без пользовательской системы исключений — как раз и может поломать Вёб, по моему мнению. Хотя и не думаю, что таких сайтов будет очень много.
>…мы не катим бездумно все, что подмёрживаем себе от хромиума.
И это — замечательно.
Вопрос в том, нужно ли при этом ломать текущий Вёб полностью или лучше, что бы он хоть как-то работал, пусть в режиме совместимости, по запросу пользователя?
Такие фичи всегда катятся так, что пользователь может их выключить при желании, как минимум до тех пор пока проходит эксперимент.
Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей
Вполне может быть, что тут тоже будет такая возможность. В качестве примера можно привести флеш. Хром целенаправленно отказывается от него, но делает это относительно небольшими шажками:
- Весь флеш играет всегда как хочет
- Можно сделать так, чтобы играл по-умолчанию только важный флеш
- Флеш блокируется, но есть вайтлист сайтов, где продолжает играть. Разблокировать можно через контекстное меню
- Вайтлист сайтов сбрасывается после перезапуска
(Мы где-то тут, ниже вероятное развитие событий)
- Вайтлиста нет, можно просто разблокировать
- Разблокировать можно только с приседаниями
- Флеш не поддерживается. Смерть флеша
видимо разработчики хрома этого не понимают, я наблюдаю такую ситуацию, что моему приложению в фоне хватает цпу на то чтобы отправить простой запрос по вебсокетам на сервер, но не хватает, чтобы прочитать ответ. Ответ висит в коннекте необработанным, пока вкладка не станет активной. Из-за чего приложение не может работать в фоновом режиме
Нет ли в Яндексе возможности выпустить свой аналог Electron для разработки под десктоп?
>Как сэкономить ресурсы
Выбросить blink, вернуть webkit. Даже на такой конфигурации: 4ГГЦ, 32ГБ ОЗУ, SSD разница в скорости видна невооруженным взглядом. А не вымученный профит в 5% от такого же монстра Хромиума.
Выбросить blink, вернуть webkit. Даже на такой конфигурации: 4ГГЦ, 32ГБ ОЗУ, SSD разница в скорости видна невооруженным взглядом. А не вымученный профит в 5% от такого же монстра Хромиума.
В чём проблема открывать такие вкладки (плеер, игори) просто в отдельном окне?
Меня наоборот жутко бесит, что вкладки которые я не использую с какого-то фига съедают ресурсы моей системы. Так быть не должно. Это контринтуитивно.
Меня наоборот жутко бесит, что вкладки которые я не использую с какого-то фига съедают ресурсы моей системы. Так быть не должно. Это контринтуитивно.
геймплей многих игр основан на том, что ты ничего не делаешь, а в игре что-то меняется
— стратегии
— фермы
— idle clicker (которые по сути кликеры только до первых апгрейдов, которые начинают генерировать «клики» сами)
По хорошему, это проблема разработчиков самих игр — они должны проектировать (я имею в виду, что сейчас, ввиду озвученных в статье трендов, совершенно точно должны) игру так, чтобы она воспроизводила такие стратегии без расчета на то, что скрипт будет исполняться постоянно.
Но многие игры так не делают, как можно понять из жалоб на Cookie Clicker.
— стратегии
— фермы
— idle clicker (которые по сути кликеры только до первых апгрейдов, которые начинают генерировать «клики» сами)
По хорошему, это проблема разработчиков самих игр — они должны проектировать (я имею в виду, что сейчас, ввиду озвученных в статье трендов, совершенно точно должны) игру так, чтобы она воспроизводила такие стратегии без расчета на то, что скрипт будет исполняться постоянно.
Но многие игры так не делают, как можно понять из жалоб на Cookie Clicker.
А есть какие-нибудь секретные настройки у хрома или файрфокса чтоб кушали память минимально, никаких кешей и прочих излишеств?
Кэши — это не излишества. Кэши не создаются просто так без причины, они нужны для уменьшения времени получения ответа и для экономии других ресурсов, то есть это компромисс между памятью и cpu/батарейкой/сетью.
2-3 года назад в хромиуме был эксперимент, суть которого была в том, чтобы научиться собирать то, сколько памяти тратится на всякие разные кэши и при острой необходимости приходить и очищать их. Так вот это не только ничего не дало, но еще и сделало хуже. Да, это приводит к падению потребления памяти на краткий миг, но уже через ~1 секунду все кэши наполняются обратно, но вдобавок к этому всю эту секунду браузер работает очень неэффективно.
Если очень сильно хочется, то можно поэкспериментировать с флагами на chrome://flags или с ключами запуска (автоматически обновляемый список ключей хромиума есть тут peter.sh/experiments/chromium-command-line-switches). Беглый поиск строки «cache» подсказывает, что можно поиграться с размерами разных кэшей, но я не берусь давать тут советы, все зависит от большого количества факторов
2-3 года назад в хромиуме был эксперимент, суть которого была в том, чтобы научиться собирать то, сколько памяти тратится на всякие разные кэши и при острой необходимости приходить и очищать их. Так вот это не только ничего не дало, но еще и сделало хуже. Да, это приводит к падению потребления памяти на краткий миг, но уже через ~1 секунду все кэши наполняются обратно, но вдобавок к этому всю эту секунду браузер работает очень неэффективно.
Если очень сильно хочется, то можно поэкспериментировать с флагами на chrome://flags или с ключами запуска (автоматически обновляемый список ключей хромиума есть тут peter.sh/experiments/chromium-command-line-switches). Беглый поиск строки «cache» подсказывает, что можно поиграться с размерами разных кэшей, но я не берусь давать тут советы, все зависит от большого количества факторов
Было бы неплохо, если бы вкладка могла запрашивать разрешение на активную работу в фоновом режиме. По типу, как сейчас работает разрешение на использование микрофона, к примеру. И если пользователь дал вкладке такое разрешение или добавил в белый список — то браузер конкретно эту вкладку урезать в ресурсах не должен (кроме отрисовки, которую можно безопасно приостановить, если вкладка неактивна).
А где посмотреть актуальную версию chromium для конкретной версии Яндекс.Браузера?
Обнаружили, что в текущих сборках сломалась webRTC-RTSP для шаринга экрана (поддержка молчит). И getDisplayMedia не работает, что наводит на мысли о текущей базе уровня chrome70.
Обнаружили, что в текущих сборках сломалась webRTC-RTSP для шаринга экрана (поддержка молчит). И getDisplayMedia не работает, что наводит на мысли о текущей базе уровня chrome70.
Можно посмотреть на browser://version. Текущая стабильная версия (19.3.0) базируется на 72 хромиуме. В поддержку писали через «сообщить о проблеме» в бутерброде?
Писали [Ticket#19021112171038066], уже почти месяц тишина в ответ.
Максимально простой работающий пример для воспроизведения тоже дали.
Раз getDisplayMedia недоступно, то видимо решили по какой-то причине его не включать пока. Очень жаль, с ним было бы проще. И было бы круто где-то вовремя читать о том что нового в новой версии в более детальном виде.
Максимально простой работающий пример для воспроизведения тоже дали.
Раз getDisplayMedia недоступно, то видимо решили по какой-то причине его не включать пока. Очень жаль, с ним было бы проще. И было бы круто где-то вовремя читать о том что нового в новой версии в более детальном виде.
Добрый день, Контантин!
У меня странное ощущение от Chromium по отношению к производительности.
У меня 8Гб памяти, HDD, и я люблю открывать много вкладок (около 150-ти). И хром «умирает». Переключаешься между вкладками, и ждешь 30 секунд пока вкладка загрузится. Когда закрываешь вкладку, то тоже ждешь долго.
Вызывает у меня это удивление вот почему: почему бы просто не очистить «почти всю память» у неактивных вкладок, а потом при переключении на вкладку просто перерисовать её полностью, с нуля. Это же не так долго. Или нет?
Потом я на одном из компов поставил SSD вместо HDD и произошло чудо — все стало летать. Честно говоря, у меня сложилось впечатление, что, возможно, проблема вообще не с памятью, а что во время тормозов он что-то делает с профилем Chrome (всмысле не с профилем ПОЛЬЗОВАТЕЛЯ, а вообще что-то в папке C:\Users\UserName\AppData\Local\Google\Chrome\User Data делает) (я смотрел в Мониторе ресурсов). Что же он там так долго делает?..
Может я ошибаюсь, и это все из-за swap… Но впечатление другое
У меня странное ощущение от Chromium по отношению к производительности.
У меня 8Гб памяти, HDD, и я люблю открывать много вкладок (около 150-ти). И хром «умирает». Переключаешься между вкладками, и ждешь 30 секунд пока вкладка загрузится. Когда закрываешь вкладку, то тоже ждешь долго.
Вызывает у меня это удивление вот почему: почему бы просто не очистить «почти всю память» у неактивных вкладок, а потом при переключении на вкладку просто перерисовать её полностью, с нуля. Это же не так долго. Или нет?
Потом я на одном из компов поставил SSD вместо HDD и произошло чудо — все стало летать. Честно говоря, у меня сложилось впечатление, что, возможно, проблема вообще не с памятью, а что во время тормозов он что-то делает с профилем Chrome (всмысле не с профилем ПОЛЬЗОВАТЕЛЯ, а вообще что-то в папке C:\Users\UserName\AppData\Local\Google\Chrome\User Data делает) (я смотрел в Мониторе ресурсов). Что же он там так долго делает?..
Может я ошибаюсь, и это все из-за swap… Но впечатление другое
Добрый день!
Вызывает у меня это удивление вот почему: почему бы просто не очистить «почти всю память» у неактивных вкладок, а потом при переключении на вкладку просто перерисовать её полностью, с нуля. Это же не так долго. Или нет?
Тут сложно. Непонятно где проходит граница «почти всю». Вот если всю, то это будет в сущности discard, о котором я говорил в выступлении, но там появляются сложности — непонятно какую вкладку выгружать, а какую лучше не трогать. Тем не менее часть кэшей действительно протухают, если они какое-то время не использовались, например, видео на паузе уничтожают декодеры и очередь закешированных кадров. Но такие механизмы довольно сложно делать и в некоторых случаях невозможно сделать гарантированно работающее восстановление, например, что если мы очистили исходное содержимое страницы, а сервер работает так, что контент отдается ровно один раз (пример немного натянутый, но все же).
Что же он там так долго делает?..
Есть подозрение, что обновляет кеши, например сетевой. Но надо профилировать каждый конкретный случай, потому что может происходить примерно что угодно :)
Вызывает у меня это удивление вот почему: почему бы просто не очистить «почти всю память» у неактивных вкладок, а потом при переключении на вкладку просто перерисовать её полностью, с нуля. Это же не так долго. Или нет?
Тут сложно. Непонятно где проходит граница «почти всю». Вот если всю, то это будет в сущности discard, о котором я говорил в выступлении, но там появляются сложности — непонятно какую вкладку выгружать, а какую лучше не трогать. Тем не менее часть кэшей действительно протухают, если они какое-то время не использовались, например, видео на паузе уничтожают декодеры и очередь закешированных кадров. Но такие механизмы довольно сложно делать и в некоторых случаях невозможно сделать гарантированно работающее восстановление, например, что если мы очистили исходное содержимое страницы, а сервер работает так, что контент отдается ровно один раз (пример немного натянутый, но все же).
Что же он там так долго делает?..
Есть подозрение, что обновляет кеши, например сетевой. Но надо профилировать каждый конкретный случай, потому что может происходить примерно что угодно :)
del
Sign up to leave a comment.
Как сэкономить ресурсы в браузере и не сломать веб. Доклад Яндекса