Комментарии 33
Выложи свой код в репозиторий и на сафари, тогда посмотрю. Да я немного ленив :)
Всегда знал что фиксированный фон с прозрачными элементами убивает производительность. Спасибо за решение!
Вообще говоря, это косяк браузера, который должен уметь поступать аналогично (не перерисовывая все) сам. Но, к сожалению, пока что приходится ему помогать принять правильное решение.
Спасибо за информацию!
Спасибо за информацию!
Спорное утверждение, браузер никому ничего не должен, все оптимизации которые были сделаны, не были каким-то требованием от стандартов. Никто никогда не будет оптимизировать всё «на всякий случай». Если есть желание получить максимум производительности, следует изучить как оптимизации уже сделаны, как браузер на композитные слои разбивает страницу и как рендерит.
jsfiddle.net/q8oL13xz/4 — Safari 7.0 работает отлично.
Спасибо за проверку! Добавил в пост.
У меня этот пример не тормозит и с
background: url(«http://www.andicbakim.com/wp-content/uploads/2015/12/website-bg.jpg») no-repeat center center / cover fixed;
background: url(«http://www.andicbakim.com/wp-content/uploads/2015/12/website-bg.jpg») no-repeat center center / cover fixed;
Я работаю дома на ноутбуке HP Pavilion 15, не самой мощной конфигурации. И именно на нем я смог отловить подобное поведение. На работе у меня машинка помощнее, и явно заметных проблем с фиксированным фоном я не испытываю (хотя на серьезных сайтах, все-таки, слегка заметное подвисание не радует глаз). Тут дело, скорее, в GPU. Чем лучше, тем менее заметно.
Попробуйте открыть какой-нибудь сайт по фильмам или сериалам, где обычно в шапке висит реклама фиксированным фоном (например, хдрезка.ме). Покрутите с ним. Потом снимите в DevTools галку с fixed и посмотрите разницу =) Если разницы не видно, то я вам искренне завидую =)
Попробуйте открыть какой-нибудь сайт по фильмам или сериалам, где обычно в шапке висит реклама фиксированным фоном (например, хдрезка.ме). Покрутите с ним. Потом снимите в DevTools галку с fixed и посмотрите разницу =) Если разницы не видно, то я вам искренне завидую =)
Года три назад сталкивался с такой проблемой.
Интересное решение.
Интересное решение.
Свойство will-change предписывает браузеру отображать элемент, независимо от окружающих его других элементов.
Не совсем так. Оно ничего не предписывает, а только подсказывает браузеру, как может в дальнейшем меняться этот элемент, а браузер, исходя из окружения и собственных оптимизаций может принять решение вынести его на отдельный композитный слой. А может и не вынести, оставив его частью другого композитного слоя. А может вообще ничего не делать.
В целом у этого решения (принудительный вынос всего подряд на отдельный композитный слой) есть очень много побочных эффектов: как минимум увеличенное потребление памяти, как максимум — repaint всего слоя на, казалось бы, банальных вещах вроде изменения цвета ссылки внутри слоя по ховеру. Так что следует пользоваться этим аккуратно и следить в DevTools/Web Inspector за аномальным перерисовками.
В общем-то любой неподвижный элемент на странице снижает FPS. Просто на современных машинах это в основном незаметно.
Например, на старой машине хабр будет тормозить из-за левой панели с position: absolute;.
Например, на старой машине хабр будет тормозить из-за левой панели с position: absolute;.
Про will-change свойство, написано не совсем правильно, насколько я понимаю, will-change: transform; подсказывает браузеру, что элемент будет двигаться, и ему стоит подготовить для его отрисовки отдельный слой. И мне не совсем понятно, почему в параметрах указан именно transform, ведь по идее как раз transfrom не происходит? Хоть могу ошибаться, и тогда получается, что браузер для скрола использует transform?
Что если в качестве параметра для will-change указать opacity к примеру?
Что если в качестве параметра для will-change указать opacity к примеру?
Я схватился за голову и рву себе волосы…
Лет десять назад, я делал сайты под IE6. Дизайн и верстка были ужасны, но, практически везде на них я юзал fixed background, который я слизал с руководства по CS:Source. Я делал пачку сайтов именно с тем кодом что предложил автор в начале статьи и ни разу не испытывал проблем. Машины были слабые в то время, 256 мегабайт оперативки и процессор на 1.8 гигагерц.
Вопрос: Почему?! Почему ранее это работало идеально и не вызывало проседание FPS?
Лет десять назад, я делал сайты под IE6. Дизайн и верстка были ужасны, но, практически везде на них я юзал fixed background, который я слизал с руководства по CS:Source. Я делал пачку сайтов именно с тем кодом что предложил автор в начале статьи и ни разу не испытывал проблем. Машины были слабые в то время, 256 мегабайт оперативки и процессор на 1.8 гигагерц.
Вопрос: Почему?! Почему ранее это работало идеально и не вызывало проседание FPS?
Было меньше HTML элементов, картинки были в несколько раз меньше.
Динамика сайтов сейчас колоссальная! UX-дизайнеры порой воротят таких монстров, что хоть стой, хоть падай. Плюс накручено большое количество скриптов, которые в реальном времени постоянно отслеживают и меняют то или иное поведение элементов на странице. Раньше сайты были проще, и трава зеленее =)
Во всех браузерах поменялась модель рендеринга, они оптимизирована под работу с видеокартой. Посчитали лэйаут, отрендерили по тайлам, залили текстуры в видеокарту. Постоянно перегенерировать тайл просто дорого, тогда как раньше перерендеривалось всё постоянно, но без возможности масштабироваться на большие разрешения, в том числе и для картинок с бэкграунда.
Я даже напрягся и вспомнил более детально!
Помните в win98 была такая штука — отображение папки как web-страницы? У меня оттуда перекочевала папка с сформированным html документом для отображения. С папки windows была скопирована функция «изменение содержимого данной папки бла-бла-бла», а с руководства по Counter Strike: Source я скопировал background-attachment свойство. Данная папка отображалась у меня через дефолтный windows explorer, а следовательно через IE6?
Далее я вспоминаю о первом сайте для школы, где это свойство использовалось для фотоальбома. Основной браузер в ТЗ (бумажка была даже) был IE6.
За замечание спасибо. Я даже в замешательстве теперь о своей памяти…
Помните в win98 была такая штука — отображение папки как web-страницы? У меня оттуда перекочевала папка с сформированным html документом для отображения. С папки windows была скопирована функция «изменение содержимого данной папки бла-бла-бла», а с руководства по Counter Strike: Source я скопировал background-attachment свойство. Данная папка отображалась у меня через дефолтный windows explorer, а следовательно через IE6?
Далее я вспоминаю о первом сайте для школы, где это свойство использовалось для фотоальбома. Основной браузер в ТЗ (бумажка была даже) был IE6.
За замечание спасибо. Я даже в замешательстве теперь о своей памяти…
Я бы дополнительно порекомендовал применять фон к HTML, как корневому элементу, что дополнительно «разгрузит» body.
В свое время столкнулся с этой проблемой при написании своего параллакса.
Несмотря на то, что Вы упомянули, что в самом начале пробовали избавиться от «background-size: cover» и не получили выигрыша в производительности, в моей ситуации отказ от этого свойства решил проблему.
Несмотря на то, что Вы упомянули, что в самом начале пробовали избавиться от «background-size: cover» и не получили выигрыша в производительности, в моей ситуации отказ от этого свойства решил проблему.
К слову, position: relative у body не обязательно указывать, так как position:fixed позиционируется относительно окна браузера (или относительно родителя с transform: translateZ, но это совсем другой разговор)
или относительно родителя с transform: translateZ
а расскажи подробнее, что ты имел ввиду?
3d трансформации (такие как transform: translateZ(0) или же transform: translate3D(0, 0, 0)) вызывают некоторые побочные эффекты:
Для рендера подключается hardware accelleration, и это чинит некоторые баги с транзишенами или просто когда в сафари часть сайта не отрисовывается.
Создается новый «position scope» (сам придумал, буду признателен, если кто-то подскажет, как это назвать по-человечески) и для дочерних элементов с position: absolute/fixed позиционирование происходит относительно родителя с 3d трансформацией.
Для рендера подключается hardware accelleration, и это чинит некоторые баги с транзишенами или просто когда в сафари часть сайта не отрисовывается.
Создается новый «position scope» (сам придумал, буду признателен, если кто-то подскажет, как это назвать по-человечески) и для дочерних элементов с position: absolute/fixed позиционирование происходит относительно родителя с 3d трансформацией.
Про position:fixed относительно родителя не верю :)
Докажешь codepen'ом?
Я вот только после твоего комментария сегодня узнал что браузеры не позволяют одновременно использовать position:fixed, когда у родителя стоит transform: translateZ(0). position: fixed элемент при этом ведёт себя как relative. А ты тут говоришь такое)
Вот смотри, у меня в хроме на вин7, например, не работает.
Баг в хромиуме тянется с 2009 года, который до сих пор не починили. Вон тут некий Эрик разжевывал это ещё в 2011 году.
Докажешь codepen'ом?
Я вот только после твоего комментария сегодня узнал что браузеры не позволяют одновременно использовать position:fixed, когда у родителя стоит transform: translateZ(0). position: fixed элемент при этом ведёт себя как relative. А ты тут говоришь такое)
Вот смотри, у меня в хроме на вин7, например, не работает.
Баг в хромиуме тянется с 2009 года, который до сих пор не починили. Вон тут некий Эрик разжевывал это ещё в 2011 году.
Отличное решение, но есть одна неточность.
Позиционирование родительского элемента, когда мы используем position: fixed абсолютно бесполезно. Так как fixed не привязывается к родительским элементам.
Это нас приводит к следующей проблеме — при необходимости сверстать более одного блока с разным фиксированным фоном для каждого из блоков, то последний добавленный фон будет перекрывать все добавленные ранее.
В общем, проблемой это становится только в случае, если имеется более одного изображения.
Позиционирование родительского элемента, когда мы используем position: fixed абсолютно бесполезно. Так как fixed не привязывается к родительским элементам.
Это нас приводит к следующей проблеме — при необходимости сверстать более одного блока с разным фиксированным фоном для каждого из блоков, то последний добавленный фон будет перекрывать все добавленные ранее.
В общем, проблемой это становится только в случае, если имеется более одного изображения.
Указали бы что это перевод скринкаста Пола Льюиса :)
https://www.youtube.com/watch?v=QU1JAW5LRKU
https://www.youtube.com/watch?v=QU1JAW5LRKU
Целая статья посвященная промоутингу элементов в отдельный слой для композитинга? Это ведь по сути web-performance 101, все это можно узнать из любой толковой статьи или курса, в котором объясняют про особенности рендеринга в браузерах и учат как юзать dev tools для профилирования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Низкий FPS при прокрутке страницы. Решение проблемы background-attachment: fixed