Тормоза браузера из-за стилей, решение?

Question

[szQocks]

div{
    width: 200px;
    height: 200px;
    background: gray;
    backdrop-filter: blur(10px);
    filter: drop-shadow(2px 7px 16px rgba(255, 200, 0, .39))
    drop-shadow(9px 27px 29px rgba(255, 33, 0, 0.34)) 
    drop-shadow(20px 62px 39px rgba(255, 33, 0, 0.2))
    drop-shadow(35px 110px 46px rgba(255, 33, 0, 0.06))
    drop-shadow(54px 172px 50px rgba(255, 33, 0, 0.01));
}

эти пару строк стилей, просто уничтожают браузер, и подобных примеров ещё знаю парочку когда в пару строк стилей просто весь браузер нагибают

у меня вопросы, что с этим делать если требуется например именно эти стили а не какие-либо другие в дизайне ? верстать через разные блоки ? и кто в этом виноват ? я или разрабы этой шляпы ?

Comments

[Aetae]

Любые фильтры требовательны к железу юзера. Особенно blur.
Собсно исследуешь авудиторю свою. Если у аудитории мощное железо - геймеры какие-нить - то пофиг. Если нет - идёшь к дизайнеру и говоришь: так делать незя, пользовательские кальткуляторы не вытянут, делай без рюшечек.

Если задобаться, то drop-shadow в принципе можно картинкой зафигачить, а вот backdrop-blur без вариантов(разве что если всё фиксировано и гвоздями прибито).

[szQocks]

Aetae, так и сделал, спасибо ( изменили дизайн )

[DIVSIDE]

фильтры не используют по дефолтку видеокарту. Используй старый трюк для принудительного включения обработки видокартой transform3D 0

[szQocks]

DIVSIDE, не помогло

[DIVSIDE]

szQocks, transform: translate3d

[szQocks]

DIVSIDE, я понял, не помогло

[DIVSIDE]

szQocks, ну на этом наши полномочия всё

Answer 1

[Ivan Bogachev]

Для начала для нас важно осознать, что у разных фильтров разная вычислительная сложность. Они не все "плохие". Алгоритмы для brightness, grayscale, hue-rotate и других манипуляций с цветом выполняются за O(1) для каждого пикселя. Т.е. нагрузка на железо растет линейно в зависимости от площади элемента на экране. Это не так страшно. А вот фильтры размытия, blur или drop-shadow, имеют сложность где-то в районе O(R^2). Там есть разные варианты оптимизаций, но в среднем мы говорим именно о квадратичной зависимости от радиуса размытия. И это для каждого пикселя. Именно отсюда мы имеем сильные тормоза при попытке что-то большое размыть на пол экрана. Дохлые видеокарты телефонов и ноутбуков не вывозят. Браузеры не умеют такие вещи переиспользовать, так что это переразмытие происходит снова и снова, и мы имеем что имеем.

При этом фильтры в CSS, в SVG - это все грубо говоря высокоуровневые обертки над одними и теми же универсальными алгоритмами рендеринга. Мы можем в рамках WebGL написать свои шейдеры, которые будут делать то же самое. Обертки разные, но алгоритмы одинаковые. Поэтому замена одной технологии на другую ничего особо не даст в плане производительности. В вопросах оптимизаций нам нужно не по-тупому менять инструменты-обертки, а смотреть в конечные алгоритмы, которые будут задействованы на странице в реальном времени, и по возможности рассчитывать все заранее и переиспользовать.

В контексте верстки тут есть полтора варианта, что можно сделать. Можно рассчитывать такие вычислительно-сложные штуки еще при разработке и загружать в страницу сразу в виде картинок или видео. Это не идеальный вариант, пропорции получаются фиксированные, но иногда подходит. Есть вариант рассчитывать такие штуки в фоне на WebGL. Т.е. мы грузим интерфейс, смотрим какого там все размера получается, и один раз в фоновом режиме генерируем картинки нужного размера и потом плавно показываем. Такой вариант частенько встречается в рекламно-конкурсных проектах, когда за прелоадером в начале скрывается в том числе и такая генеративная история. Тут мы получаем гибкость в плане размеров и хорошую производительность сайта в целом, потому что все операции проходят только один раз, а дальше у нас все переиспользуется в виде обычных картинок. Каких-то принципиально других вариантов у нас пока нет. Только дизайн менять.

Comments

[szQocks]

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

так и в дурку могут забрать)

- Здравствуйте, вы к нам верстальщиком ?
- ДА
- В алгоритмы смотрите при работе с версткой?
...

а так в целом всё что вы написали я это знал +- , ну и скорее всего ответ про то что менять дизайн или вставка картинками, это ответ

про конкурс не понял, слои ?

[Ivan Bogachev]

szQocks,

так и в дурку могут забрать)

Шутки шутками, но чем сложнее верстка, тем больше нужно понимать, что там внутри находится. Это делает процесс разработки более предсказуемым. Не нужно ничего угадывать и надеяться на алхимию старых хаков, которые верстальщики передают из поколения в поколение, а проблемы можно предсказывать задолго до их появления, а не пытаться разруливать постфактум, когда гора ресурсов и времени уже потрачена. Есть такие проекты, где требования к верстальщикам выше среднего по больнице и ценится понимание внутренностей в том числе. И да, даже в вакансиях порой пишут "нам нужен математик со знанием js". Фронтенд в целом - понятие растяжимое. Где-то хватит месячных курсов, а где-то нужно образование по части computer science.

про конкурс не понял

Имеются в виду сайты, которые делаются с оглядкой на конкурсные каталоги вроде Awswards, CSS Design Awards, FWA и.т.д.. В таких проектах часто можно встретить использование WebGL для рисования чего-то, что на CSS работает не очень. Взяв все в свои руки мы можем какие-то ресурсы переиспользовать более умным образом по сравнению со стандартной браузерной логикой и на этом выиграть что-то по части производительности.

[szQocks]

Ivan Bogachev, понял