Pull to refresh

Comments 58

По-моему, это круто! По крайней мере имеет практическое применение.
Google Chrome 31.0.1650.57, OS X. Разницы в производительности нет.
Google Chrome Windows 7. Весьма ощутимая разница.
Тем не менее, тоже Win7+Chrome — прирост очень ощутимый. В разы плавнее скролится.
Google Chrome 31.0.1650.57, OS X. Разница ощутимая.
Что прямо в отладчике видно разницу?
Надо было так:
Mac Pro, 2х 6-core Xeon, 64 gb RAM, Google Chrome 31.0.1650.57, OS X. Разницы в производительности нет.
UFO just landed and posted this here
Я думаю тут дело в мощности процессора или видеокарты. Я тоже разницы не заметил.
Все аналогично и разницы тоже нет. 60 fps.
Может я что-то не так делаю, но FF25 Linux тоже никакой разницы не вижу.
Аналогично. Что так тормозит, что так тормозит.
FF25 + Win7 — аналогично, совершенно никакой разницы в FPS. Судя по наблюдениям, в FF25 уже есть встроенный механизм отключения :hover во время скролинга.
А вот на «хромовых» браузерах разница, хоть и небольшая, но есть. К тому же они даже с включенным pointer-events скролят в разы плавнее, чем FF25
Win8, новая Opera. Производительность выросла более чем в 2 раза.
UFO just landed and posted this here
fps подрос, но субъективно особо разницы то и нету… проверю потом на всякий айфонах андроидах, глядишь там толк есть.
UFO just landed and posted this here
Android точно может быть с мышой… однако это достаточно экзотическая конфигурация…
На андроиде тоже происходит hover при касании, например на огромных списках с кнопками, если у вас есть для кнопки :active :hover — такие стили могут существенно понижать производительность, потому что рендер затыкается на элементе по которому случайно тапнули, чем заставили перерисовать стиль.
Мыши там может и нету, но события мыши эмулируются. И hover там так же есть, как есть и active. С другой стороны их редко для тач девайсов используют. Хотя и то что в примере так же редко встречается.
В итоге, я так понял, все ховеры на странице тормозят браузер.
В реализации на jquery ещё и сам код становится простым и коротким. Красота.
Если вы гонитесь за производительностью, зачем вам jQuery?
Иногда jQuery уже есть в проекте. Чем плохо использовать его и для подвешивания на scroll()?
jQuery сам по себе медленный. Перед тем, как оптимизировать мелочи типа прокрутки, желательно заниматься крупными оптимизациями более очевидных вещей.
UFO just landed and posted this here
в реализации на underscore/lodash скорее, ибо вам нужен debounce. Добавлять обработчики событий нативной, классы и т.д. много кода вам не сократят. Да и то это так же лишнее…
Уже осознал на собственной шкуре карме — хабражители не любят jQuery. Был не прав.
Opera 18.
При отключении hover, и промотке страницы скролом, перестают подсвечиваться элементы пока не пошевелишь мышь, при включении — подсвечиваются.
А ведь можно добавить это в пользовательский скрипт и получить высокую производительность на всех сайтах!
Похоже, я сказал какую-то несусветную глупость, потому что совершенно не знаю JS. Кто-нибудь пояснит мне, в чем она состоит?
в том что эта штука помогает только в очень специфичных кейсах.
Но при этом она вроде бы ничего не ломает. Невелика беда, что во время прокрутки hover не работает.
В этом специально подготовленном примере fps выросло в полтора раза (у меня), а вот на всех моих текущих проектах толку вообще нету.
В Firefox тормозит как с хаком, так и без. Да ещё и включаются события заторможенно.
Возникает мрачное подозрение, что перед нами ещё один такой рецепт, который превосходно работает в Chrome, но дурно (или никак) в Файерфоксе. Тем более, что Paul Irish явно сослался на какой-то чисто хромовский нюанс.
В FF тормозит в обоих случаях.
В chrome чуть быстрее, чем без
В IE11 работает очень шустро, разницу не заметил
/Win8.1 64 bit, intel core i5
Если навешивать на hover эффекты, вызывающие repaint, то будет разница. Если такого нет, то и разницы особой не заметите. Даже на графиках в Dev Tools.

Таких эффектов, которые не вызывают repaint очень мало. И сложно представить ради каких из них может вообще использоваться :hover. Ну cursor, да, не редкий в таких случаях. А другие — большая редкость.

Спасибо! Грядёт ускорение барона, и эта фишка туда тоже попадёт.
«которое», конечно же. Уже нельзя исправить.
А разве pointer-events вообще применим к HTML? Когда я последний раз смотрел w3c, он был разрешён только для SVG, а из HTML убран из-за каких-то проблем с совместимостью.

Некоторые браузеры применяют и к HTML вопреки спецификациям, но далеко не факт, что это будет работать везде и всегда.
один косяк: когда скролл остановился, то элемент остался не подсвеченным
UFO just landed and posted this here
linux amd64, chromium
разница есть, процентов 5 =)

Однако у меня выключен плавный скролл (терпеть его не могу, возможно даже как раз изза того что тормозит). С ним разница больше, примерно как на видео в шапке. Однако без плавного скролла все быстрее всё равно. Кто придумал плавный скролл и как его отключить глобально у всего человечества знает кто? =))
По-моему при каждом скролле обращаться к элементу проверяя есть ли у него класс это жестоко. Вот так получше будет.

var body = document.body,
    timer,
    hover_disabled = false;

window.addEventListener('scroll', function() {
  clearTimeout(timer);
  if( ! hover_disabled && ! body.classList.contains('disable-hover')) {
    body.classList.add('disable-hover');
    hover_disabled = true;
  }
  
  timer = setTimeout(function(){
    body.classList.remove('disable-hover');
    hover_disabled = false;
  }, 500);
}, false);

Согласен. Хорошее замечание. У меня есть ещё предложения:


  • Проверка classList.contains()бесполезна в тех случаях, когда нужно сделать classList.add(). Built-in метод add уже внутри нативно содержит такую проверку, поэтому избыточно делать дважды эту проверку.
  • Можно не добавлять дополнительную переменную hover_disabled, а объединить её вместе с timer. Их логика для данных целей синхронна, поэтому можно удачно их объединить.
  • Можно не вызывать clearTimeout() лишний раз, когда timer уже отработан.

Вот мой вариант:


var body = document.body,
    timer = false;

window.addEventListener('scroll', function() {
  if (timer === false) {
    body.classList.add('disable-hover');
  } else {
    clearTimeout(timer);
  }

  timer = setTimeout(function(){
    body.classList.remove('disable-hover');
    timer = false;
  },500);
}, false);

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

Какая-то оптимизация уже явно появилась в Chrome (v75.0 x64). Но при этом поведение не такое, как с предложенным здесь способом с отключением hover, а заметно лучше. Подсветка (hover) срабатывает значительно реже во время скроллинга. В микро-паузах, пока палец меняет свою позицию над скроллом, успевает сработать подсветка. А самое главное, по окончанию скроллинга элемент, над которым остановился курсор становится подсвеченным — это самое большое отличие не в пользу способа с отключением hover.


В Chrome способ с отключением hover показывает себя лучше по FPS примерно на 10% и возможно в отдельных сценариях он даже сейчас будет уместен.


В FF (v60.8 x32) такой оптимизации не ощущается, либо она там чуть меньше сделана. Способ с отключением hover показывает себя лучше по FPS примерно на 15-20%.


В MS Edge (v44 x64, EdgeHTML v18) такая оптимизация явно есть, при том что она визуально работает почти так же как с отключением hover. Даже при остановке после скролинга hover не срабатывает у элемента находящегося под курсором. Вообще очень похоже. Во время скроллинга hover срабатывает только, если перемещать курсор. Разница по FPS почти незаметна.


В MS IE (v11 x64) примерно так же как в MS Edge.




ЦП: Intel® Core(TM) i5-4200H CPU @ 2.80GHz
ОЗУ: 8,0 ГБ DDR3, 1600 МГц, SODIMM
GPU: Intel® HD Graphics 4600, 2,0 ГБ

Актуально ли это в 2020? Chrome 80 и Safari 13 не генерируют JS- и CSS-события курсора при скролле.

Sign up to leave a comment.

Articles