Как замерять производительность DOM в Chrome DevTools?
Здравствуйте, на дворе конец 2016 года, по JS пилят вовсю новые стандарты и фичи, а многие люди так до сих и не научились писать нормальный фронтенд. Многие по факту до сих пор используют jQuery, и это не есть плохо, все зависит от того, где мы потратим больше времени: на разворачивание фронтенд-среды или на коленке напишем на фриланс-бирже заказчику простой слайдер на чистом JS или jQuery без всяких Gulp/Webpack/MV* приблуд пришедших на пользу (начиная с 2009). Однако, в сложных проектах, даже если мы теперь пишем на ElectronJS свое приложение нам не обойтись без виртуального DOM или другой технологии под капотом какой либо библиотеки или фреймворка, которая самостоятельно манипулирует DOM в соответствии с моделью данных. Однако, я не понимаю одного, разные тесты показывают разные результаты, какой-то фреймворк хорошо работает с тем то, какой-то просто умеет быстро обновлять DOM, но неправильно делает другое. И тут как бы встает вопрос, проблема во фреймворке или просто я неправильно написал код, из-за которого неправильно работает фреймворк? Мы ведь все равно понимаем, что дополнительные либы и фреймворки такеже работают с DOM, просто это все автоматизированно на таймерах, слушателях и прочих сигналов-слотах.
Поэтому мне интересно, как замерять в своем проекте DOM и понимать где лажает просто браузер, где фреймворк, а где конкретно я. Подскажите что-нибудь на эту тему?
Почему я сказал, про браузер, потому как это легко заметить, когда начинаешь читать историю своих сообщений в ВК, когда открываешь все больше и больше старых сообщений, они также загружаются в DOM и все начинает подлагивать, и не понимаешь, что у браузера переполняется стек и перерасчеты становятся долгими. Но блин, когда мы открываем нативное десктопное приложение Excel, мы там спокойно 64000 строк может проскроллить и ничего тормозить не будет, вина в браузере и DOM или в том, что JS просто такой однопоточный и вечно интерпретируемый!?
Excel реализует так называемый "виртуальный скролл" суть которого сводится к тому, что он рендерит не все 64000 строк, а только те, что видны в данный момент. При изменении позиции скролла скрытые строки удаляются, а освободившиеся от них ресурсы могут быть переиспользованы для создания новых строк. В вебе такую технику тоже можно применять, получая независимость отзывчивости от позиции скролла. Например: eigenmethod.github.io/mol/#demo=mol_grider_demo
К сожалению у данной техники есть ограничения из-за которых её нельзя встроить во фреймворк - высоты строк должны быть фиксированными, чтобы можно было понимать какие строки видны в определённой позиции скроллинга. Так что если число элементов в DOM у вас всё время растёт, то нужно что-то меня в алгоритме вашего приложения.
Тем не менее, есть и из ряда вон плохо написанные фреймворки, которые в принципе тормозят и единственный способ написать на них быстрое приложение - обращаться к функциям фреймворка как можно реже. Разница может составлять несколько десятков крат: eigenmethod.github.io/mol/app/bench/#sample=sapui5~mol
То бишь, excel побеждает рендерингом потому, что он скомпилирован и тем, что количество строк известно, так? Кстати, в первом примере, который вы мне скинули все также безбожно лагает при скроллинге (все равно проблема DOM видна), во втором примере, в середине себя очень странно ведет скролл, он резко отъезжает от курсора, хотя я его тянул на одном уровне.
Максим Иванов: Нет, потому что не рендерит все строки, а только те, что видны.
Дёргание за скролл - не типичный сценарий использования. Но да, там можно ускорить отказавшись от динамических ширин колонок.
Во втором примере, в реализации на $mol, снизу за пределами видимой области блоки не рендерятся. А пока они не отрендерены - высота их не известна. Поэтому общая высота известна лишь приблизительно и по мере скролла она растёт, из-за чего ползунок слегка отскакивает назад.
Максим Иванов: с DOM всё так. Проблема в том, как мы пишем приложения. Нельзя просто так брать и вываливать 100500 блоков пользователю. Рендеринг нужно производить лениво по мере необходимости. Помочь в этом может, например, IntersectionObserver: https://dmitryskripkin.github.io/vue-virtual-scrol...
И да, когда я держал курсом и тянул за скролл он также отскакивал при загрузке нового контента, как это было и в вашем примере. Уже лучше, но когда я проскроллил до 200 поста начинал мерцать экран и подрыгивания контента происходить, проблема Vue или Browser?
Вопрос в том, что у меня есть компоненты форм, написанные на Angular 1.5, пользователь может генерировать их сам, но когда их становится много (11 тыс элементов html) все начинает лагать. И мне ведь не понятно, когда скрывать какой компонент, ведь дело в том, что размеры блоков не фиксированные у этих форм-элементов.
Максим Иванов: input элементы сами по себе довольно тяжёлые. А если их ещё и десятки тысяч - ту любой фреймворк захлебнётся. Остаётся искать компромисы исходя их сценариев использования.
ну это же субъективная оценка, в разных браузерах может быть по-разному в зависимости от движка JS, может вы знаете более объективную оценку рендеринга элементов?
А EigenMethod - это какая-то организация у вас или как?
И кстати, помимо расчетов времени, можно бы было статистику вести, ведь в разных браузерных движках по разному рендеряться теги с разной скоростью
Простой