Оптимизация
Ну, перво-наперво, вам следует запомнить, что
результаты поиска не кэшируются — каждый раз, запрашивая элементы по селектору, вы инициируете поиск элементов снова и снова
При ознакомлении с алгоритмом работы Sizzle, сходу напрашиваются несколько советов об оптимизации по работе с выборками:
Сохранять результаты поиска (исходя из постулата выше):
Правильная IDE о подобных вещах знает, и будет вам время от времени подсказывать ;)
Использовать цепочки вызовов (что по сути аналогично первому правилу):
Использовать
context
(это такой второй параметр при выборе по селектору):
Разбивать запрос на более простые составные части, используя
context
, и сохранять промежуточные данные:
Использовать более «съедобные» селекторы, дабы помочь методу
.querySelectorAll()
, т.е. если у вас нет уверенности в правильности написания селектора, или вы сомневаетесь в том, что все браузеры поддерживают необходимый CSS-селектор, то лучше разделить «сложный» селектор на несколько более простых:
Не использовать jQuery, а работать с «native» функциями JavaScript
Есть ещё один пункт – выбирать самый быстрый селектор из возможных, но тут без хорошего багажа знаний не обойтись, так что дерзайте, пробуйте и присылайте ваши примеры.
Для наглядности лучше всего взглянуть на сравнительный тест benchmark.html:
Данный тест выполняет поиск элементов несколькими способами и был изначально разработан Ильёй Кантором для мастер-класса по JavaScript и jQuery
Маленькая хитрость от создателей jQuery – запросы по id элемента не доходят до Sizzle, а скармливаются document.getElementById()
в качестве параметра:
Примеры оптимизаций
Выбор по идентификатору элемента — самый быстрый из возможных, старайтесь использовать оный если есть такая возможность:
Селектор div#content
работает на порядок медленнее, нежели поиск лишь по идентификатору #content
, но и он имеет право на существование в случае, если ваш скрипт используется на нескольких страницах, а логика требует лишь обрабатывать поведение для элемента <div>
. Данный селектор можно представить в двух вариантах:
Но и тут есть разница в производительности, в результате тестирования получаем, что пример с использованием .filter()
работает быстрее на 20-30%:
Но всё же, подобная тонкая оптимизация нужна далеко не всегда. Выводы делаем сами.
Last updated