Comments 6
transform: translateZ(0);
will-change: transform;CSS-свойство will-change: transform; позволяет нам дать рекомендацию браузеру, что “тут будет часто меняться позиционирование, имеет смысл вынести все в отдельный слой”.
Первое свойство и так форсирует вынос в отдельный слой, так что второе лишено смысла.
Также имеет смысл вынести весь конейнер в отдельный слой, чтобы компоновка и перерасчет стилей был отделен от основного потока.
Если речь про скроллящийся контейнер, то это очень вредный совет, так как приведёт к отключению браузерной оптимизации скроллинга. У вас получается слой, который стоит на месте, но содержимое которого полностью меняется каждый фрейм. Выносить на отдельный слой имеет смысл как раз всё содержимое скроллящегося контейнера, чтобы браузер мог просто сдвинуть слой без его ререндера. Ререндер же пойдёт асинхронно, не влияя на плавность скроллинга. А вот для предотвращения постоянного пересчёта лейаута всей страницы, нужно уже прописать contain: content.
Не фронт, но нельзя ли решить проблему нечестного скроллбара, не просто удаляя элементы из списка сверху, а создать пустой div и увеличивать его высоту на высоту удалённого элемента?
Да, пустой элемент высотой в несколько сотен экранов похож на какое-то граничное условие для браузера, но это всё же лучше, чем тысячи дивов с текстом и навешеенной логикой, кмк.
Добавление таких распорок может помочь сохранить честный скролбар, однако в ограниченном числе случаев. При первой работе со списком, кешировние размеров уже загруженных элементов может вам помочь в калькуляции размеров распорки. Но такой подход позволит вам вернуться с помощью ползунка только в те места списка, которые уже когда-то были загружены. Не совсем честный скролбар получается. Также если перезагрузить страницу, необходимо будет выполнить вычисления заново.
К тому же, непонятно что делать, если заресайзилось окно. Размеры элемента списка могли ведь поменяться. Поэтому высота распорки становится неактуальной, ее бы надо пересчитать. Ещё одним минусом является то, что нельзя сразу при первой загрузке сделать такие распорки, ведь мы не знаем наперед размеры элементов. Можно в принципе их прогнозировать через медианное значение уже загруженных элементов и каждый раз это значение рекалькулировать. Однако непонятно какие именно элементы и с каким офсетом грузить, если потянуть ползунок скроллбара в свободное место.
Если коротко, сделать честный скролбар — это отдельная задача, не такая уж и простая. Есть несколько граничных проблем, которые, по моему мнению, заставят вас отказаться от этой затеи. Но если все же вас не отговорить — то тогда это отличное поле для идей и экспериментов!
А можно приложить демо хотя бы последнего варианта? Так сказать, чтобы оценить, как оно вживую ощущается.
Как не проиграть с производительностью в длительном скроллинге